Slashdot Mirror
Web Designer's Reference
The reasons are clear and compelling: The World Wide Web Consortium, which promulgates Web design standards, has decreed HTML as obsolete. Newer, more compliant browsers, will in time not support the older tags and code; the new standards facilitate much better use by the disabled of screen readers and non-graphic browsers. Not least, the newer code makes writing and revising code easier and more efficient, as well as more capable.
These are certainly good reasons for Web designers to move to the new code. Nevertheless, surveys show that most Web pages are not compliant and that thousands of designers continue to use deprecated code. I confess that I am one of them -- after a number of years learning and getting used to HTML, the need to learn new and more code is onerous. The inertia of habit is a factor, I'm sure.
For those Web designers like me, Mr. Grannell's book is a welcome addition to the literature because it systematically deals with the topics under discussion. In its coverage of XHTML, CSS, Javascript, and complementary coding (like PHP), it provides a nice framework guiding "old dogs" like me into standards-compliant code. Not only does it provide some historical perspectives on these codes, it compares the old with the new in regard to all of the important elements of Web design.
The author is an experienced Web designer and operates a design and writing agency. He also writes articles for a number of computer magazines.
Grannell's goals are to teach cutting-edge, efficient coding, and how to master standards-compliant XHTML 1.0 and CSS 2.1. There are a dozen chapters. He breaks down the elements of Web design into modular components so that one can focus on each element separately, like page structure, content structure, layout, navigation, text control, user feedback, and multimedia. Relevant technologies are explained in context of producing a typical Website.
If one finally decides to move forward, as many suggest, this is a very good volume by which to get your start. For new designers, this is a nice primer to learn what is expected, in an overall sense, of good, advanced Web design.
This is a well-produced book with clear writing, comprehensive approach, dozens of practical examples, and downloadable files with the code examples used in the book. The author writes in a logical sequence much like an engineer would. It is a heavy textbook-like read, only lightly sprinkled with style and personality. It should appeal primarily to novice designers, but has enough advanced information to satisfy an experienced designer who is looking for that fresh start.
And in fact, the structure of the book facilitates the "fresh-start" idea. It starts with a Web design overview, giving an experienced user's tips on what software to use to write code, what browsers to design for, how to build pages from the very top to the bottom. (XHTML, unlike HTML, requires a preliminary document-type definition (DTD) to validate. Only after the introductory section does the first HTML tag appear.)
Like others writing in this area, Grannell firmly advocates designing for standards compliance, usability, accessibility, and last and least, visual design. Marketing Department people may choke on that priority list, but there is no inherent conflict between function and aesthetics; Grannell simply does not spend a lot of time on the aesthetics.
The middle chapters concentrate on modular construction of pages -- the XHTML introduction, the structural elements like text blocks and images, the logical structure of the links and navigation flow, and finally, the stylizing with CSS. Comparisons between pages styled with HTML vs. CSS compellingly demonstrate the benefits and advantages of CSS. There will be no going back once you've decided to upgrade your technical approach.
Basic CSS concepts are explained and illustrated with code samples and screenshots. Grannell describes how to use CSS for text control, navigation, and layouts. There is a broad section on frames and another on forms and interactive components.
The last chapter covers testing and tweaking including how to create a 7-item browser test suite. Strategies overcoming browser quirks are discussed throughout the book. There is detailed technical information, especially in regard to the XHTML introductory section of the page, which I have not seen elsewhere.
There are three welcome reference appendices at the end covering XHTML tags and attributes, Web color coding, and a very comprehensive entities chart noting currencies, European characters, math symbols and more.
Much of this material is covered elsewhere in the growing set of publications about standards-compliant code. This book has the virtue of having a useful overall perspective on Web design and acts as a framework for new designers and converting designers to renew and upgrade their technical approaches.
You can purchase Web Designers' Reference: An Integrated Approach to Web Design with XHTML and CSS from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Look around the web, and see all the complicated PHP scripts and ASP pages serving as frontends to database of choice, to serve up what's essentially static information.
Plain HTML is quite often the most efficient solution, to produce, host and maintain.
All aboard the hype train! We'll fill the dotcom bubble back up, one asshat at a time!
I don't need no instructions to know how to rock!!!!
This begs the question: "Whose implementation does this book emphasize/teach?"
For ANY web designer who has at least some experience with html/css, this is the single most difficult aspect of web design. That is, getting the page to work in all the popular browsers takes the most time and really has no logic to it. What I would like to see is a book that skips all the fluff that we've seen before and goes straight to browser bugs. If they can be avoided in the first pass at making a web site it makes perfecting the final presentation all that much easier.
Quid festinatio swallonis est aetherfuga inonusti?
Africus aut Europaeus?
Newer, more compliant browsers, will in time not support the older tags and code;
Yeah that's a great idea. Lets just stop supporting a simple markup and make it impossible to view all the legacy HTML in existence. While we're at it let's force everyone to change to a newer, more complicated standard, even if they have no need for it.
Now I'm all for using CSS and XHTML, but that is because it makes things easier to maintain for me. Calling for browsers to stop supporting HTML, however, is taking it about three steps too far.
So if that is the case, then why the heck doesn't more people do it? I mean, if we assume that people learn to code webpages from books, why do they buy the old shitty books and code their pages with godawful font-tags and something that closely resembles MS-Word-HTML?
With that said, XHTML and CSS is love.
If the developers of Netscape Navigator had this fanatical devotion to the W3C that seems to be popular lately, we wouldn't have tables, scripts, or any kind of styles (neither nor CSS). None of that was in the standard (HTML 2.0) at the time.
Grannell firmly advocates designing for standards compliance, usability, accessibility, and last and least, visual design.
If people keep using HTML, browers will continue to support it. Designing for standards compliance is great, but a crappy website that loads on any standards compiant browser is a lot less useful than a beautiful, usable website that loads on the major brosers like Firefox, IE, Opera and Safari.
Ever heard someone complain about an ugly website that's hard to navigate? we've all done it.
Ever heard anyone complain that standard HTML didn't look the same on all broswers? Not too often I bet.
And standards compliance is great, but with 1) IE having a 90% market share, and 2) IE not being standards compliant, doesn't that mean that most internet users aren't using a standards compliant browser?
And why is that? So people can screen scrap easier because you're content is xml parsable?
I lived by those rules not long ago; tableless design, css driven, no client side javascript events in the html (but put there by an initialization function), classnames never revealing structure information, separating structure classes with lay-out classes in different css, xhtml 1.1, etc.
Where did it get me? Not sure but sticking to all those rules sure costed me much more time then needed. And what for, because browers require that a page validates in a few years? Forget it, not in a decade, not in two.
Advice, stick to clean html that makes sense, think of your customers, think of your bandwith and don't let that w3c run your web development.
XHTML 1.0 became a W3C Recommendation on 26 January 2000, meaning it has been around almost as long now as HTML was when it came out! (Well, at least, almost as long as HTML had been in popular use when XHTML came out).
The only excuse for not using XHTML today is laziness and ineducation on the part of designers and those educating them. The same reasons most web sites don't validate as proper HTML. Sadly, "just good enough" is the rule of the day.
Having said that, using PHP and other dynamic mechanisms to "code around" browser bugs, by implanting "patched" tags or using alternative mechanisms where something is seriously broken, is definitely the most practical solution.
You can use Apache SSI's to detect the browser and then #include the appropriate page, but that is extremely expensive on maintenance. It is much more practical to embed markers wherever you might need to deviate from the "correct" HTML and simply use a script to search & replace.
For those pages that genuinely do have dynamic content, you can have a background engine generate static pages every so often, which you then serve, avoiding a continuous rebuild. However, you run the risk of race conditions, where you try to serve a page that is part-way through a rebuild. The result will be the display of a broken page, which is definitely a Bad Idea.
Really, the "correct" design is to use a mix of approaches. Use static methods for static content, use dynamic methods for dynamic content, use pre-built pages where downloads are more frequent than updates. Hammers are great for nails, but you wouldn't use them in place of a saw or a screwdriver.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Namespaces!
The proliferation of XML allows everyone to create tag sets to meet their needs - from Scalable Vector Graphics to Chemistry Markup Language.
With this evolution, the browser becomes more of a host for a set of plugins glued together through XHTML.
XHTML, being a dialect of XML, allows you to create compound documents combining elements from multiple XML namespaces into a single document.
XHTML doesn't force you to do anything. I can make a page that passes a validator that's 8 nested tables deep that happily passed the w3c validator. There's absolutely no forcing there.
The only thing that XHTML forces you to do is stop using the font tag. That's pretty much it. Everything XHTML can do HTML 4 does and does it better (cuz existing UAs grok its mimetype).
The real promise of XHTML is the same as XML: being able to mix and match namespaces into a super-document. However, no user agents (except for some special builds of Mozilla) really accept embedded XML dialects (for an example, see SVG+XHTML on Mozilla's SVG site). This is changing in Firefox 1.1, but it won't have any real effect on the marketplace until the majority of user agents support it.
Short version: XHTML disables the use of the FONT tag and some attributes that should be done in CSS anyway.
I think it's a little bigger than that. XHTML was never intended to be the answer, but rather an intermediate step.
Since you asked, here's a reason off the top of my head: As an XML application, XHTML requires you to have a well-formed document. That's good for me because later on, i can work with it.
If I need a PDF of a 4 year old document that is written in half-assed, abused, non well-formed HTML It's going to be very difficult for me to parse it into something useful.
Here's another reason: try maintaining bad html over the long haul. Overlapping tags can be a real pain.
That's ok, Jesus likes me anyway.
I did a page layout on eBay for an older retired friend who makes wooden toys. I used the normal .css file and div tags -- it looked like crap and was unusable. I had to go back to the drawing board and use tables! (Tables, nested in tables to get the same layout)
Most of the internet might be ready for bleeding edge stuff, but don't toss away your plain 'ole vanilla flavored HTML just yet.
Newt-dog
My Doctor prescribed daily nasal saline irrigation, hehe
That said:
Garbage. The amount of code necessary to support basic HTML is so tiny amidst the vast beasts major broswers have become that there's no reason to dispense with it. And why use anything else when straight, primative HTML is still the most effective tool for conveying simple information?Crow T. Trollbot
I learnt html4 and basic CSS as was current back then.
Moving several client sites to xhtml strict in 2000 was totally painless. Let's face it. the majority of so-called web designers haven't got a clue about markup.
More books like this please, the majority still need whacking around the head with them a few more times.
There are plenty of other reasons.
Like 90% of the pages out there don't need it.
99.99% of mine don't. All I need is my trusty hammer and screwdriver, and you're trying to insist I use a fully automatic, 50 calibre nailgun and a 3HP power drill with screwdriver attachment.
It all depends on what you mean by "readable". If all you want to do is read the text in your page, I suppose your HTML is more readable. However, as someone writing code, I would definitely prefer the XHTML because it clearly shows me where the beginning and end of each paragraph are. That's essential when you start applying style sheets, and it encourages cleaner code as well.
The thing is, your example is really moot anyway when it comes to HTML vs. XHTML. Your second example is perfectly valid HTML (except for the closing slash on the image tag), and I was closing my paragraph tags for years before I'd even heard of XHTML because of the reasons I've already mentioned.
I wish that my inferiority complex were as good as yours.
-RenderHead
You're still thinking in terms of merged design and content.
Maybe you don't have a need for flexible control over your design post-publication. But a lot of other people do, particularly media sites. Actually, keeping design and content separated is a good idea in general. The ultimate ideal would be to be able to have the content standardised sufficiently that you could syndicate content from one site to another in the original markup without having to worry about compatibility with stylesheets etc.
Obviously that's not here now, XML+XSLT aside. But for people who generate a lot of text content having a "design engine" built into the end users browser saves a lot of time.
How do you add your content and render the pages around it? Have you written custom code that automatically adds all your design markup into each served page? The idea behind CSS/XHTML is that the browser does that for you, you just define your rules in a single flexible document.
As for the BR tag, that's just silly. The P tag is "lame"? What's lame about it? It defines a semantic meaning (begin and end a paragraph) that the BR tag ("start a new line now") doesn't have, while allowing basically the same things to be done.
You just strike me as somebody who learned HTML a long time ago and hasn't been keeping up.
You're talking about CSS, not XHTML. Both good old HTML and XHTML support it, and it is indeed a great way to separate design and content, but it has nothing to do with XHTML.
:-p), as browsers are very unlikely to drop support for HTML anyway...
Actually, the only advantage to XHTML is that you can apply XML transformations or use special features like MathML or embedded SVG. But if you don't plan on using them, you're just wasting your (valuable) time (and even slightly increasing the file size
or opera or elinks or konquerer or Netscape 4.x...
XHTML is a good idea but have you noticed how verbose and complicated it's gotten?
d ">
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dt
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head profile="http://www.w3.org/2000/08/w3c-synd/#">
versus:
<html lang="en-US">
<head>
The US Army: promoting democracy through unquestioned obedience