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.
Haha, a web design book being reviewed on Slashdot. Oh, the ironing is delicious.
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.
Done and done. .blinktag
{
text-decoration:blink;
}
Super quick whizzbang explanation:
<b> and <i> are visual tags: they make text look bold or italicised without altering the meaning of the sentence they are in. <strong> and <em> are logical tags: <strong> provides emphasis in web page readers, as well as looking bold, for example. <em> does the same, but renders differently in text browsers. There are other italic tags such as <cite> that are used for citing references, for example.
This page says it better than I do.
Guy asked me for a quarter for a cup of coffee. So I bit him.
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.
The main is that XHTML really FORCES you (if you want your page to pass W3C validation) to seperate design from content in a way that facilitates the ease of updating pages.
A side effect of this is smaller filesizes. A recent conversion from HTML to XHTML+CSS for a client of mine brought their homepage size down from 25k to 9k. This to me is reason enough to use XHTML+CSS.
A side effect of this is better code/content ratio.... a side effect of this is better search engine placement.... a side effect of this is...
So using XHTML over HTML actually has a cascading (mind the pun) list of benefits, completely independant of the technical mumbo-jumbo of the whole "XHTML is supposed to be XML" stuff.
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)
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
What I like to do:
.htaccess mod_rewrite rules to make the pages look static (blah.php?pageID=24&whatever=1 becomes blah-24-1.html)
On local development server:
- Create database to store data
- Create scripts to make the pages
- Create
Then I use wget to save a static version of the website, then upload the static version to my webserver. Some advantages:
- Less resources needed on server
- HTML template easily changed if required
- Extremely fast script development time, since there are no security checks required
- More secure than PHP scripts on a server could ever be
Obviously this method won't work for websites that require user input (like polls), but I think not having to worry about the security of live scripts is awesome.