Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming The Internet Books Media Book Reviews IT Technology

Web Designer's Reference 416

Posted by timothy from the crazy-code-everywhere dept.
jsuda (John Suda) writes "It seems as if everyone and his brother is writing books supporting standards-compliant Web design with XHTML and CSS. I have read and reviewed a half dozen this year alone. People are obviously trying to tell us something - plain HTML has to go! Web Designers' Reference: An Integrated Approach to Web Design with XHTML and CSS, by Craig Grannell, is the latest of these pronouncements." Read on for the rest of Suda's review.
Web Designers' Reference: An Integrated Approach to Web Design with XHTML and CSS
author Graig Grannell
pages 389
publisher Friends of ED
rating 8
reviewer jsuda
ISBN 1590594304
summary Comprehensive guide to standards-compliant web design

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.
This discussion has been archived. No new comments can be posted.

Web Designer's Reference More

Web Designer's Reference

Comments Filter:

  • Wow. (Score:2, Funny)

    by Monkeman ( 827301 )
    That's a long title. It's upwards of five words. We need to stop this trend before we get crap that's fourteen words and requires a pamplet hanging off the spine of the book to print in full. New Books:Old Books Diet Cherry Vanilla Lime Dr. Pepper:Dr. Pepper

  • Standards, Schmandards.. (Score:5, Funny)

    by jimmyCarter ( 56088 ) on Tuesday May 17, 2005 @05:02PM (#12559924) Journal
    Bring back the BLINK tag!

  • Oblig (Score:5, Funny)

    by Anonymous Coward on Tuesday May 17, 2005 @05:03PM (#12559936)
    Haha, a web design book being reviewed on Slashdot. Oh, the ironing is delicious.

  • Web standards!!?? (Score:4, Insightful)

    by bogaboga ( 793279 ) on Tuesday May 17, 2005 @05:05PM (#12559955)
    I was supprised when my post http://slashdot.org/comments.pl?sid=149370&cid=125 24267 [slashdot.org] was replied by one slashdotter to the effect that no browser today has 100% W3C compatible implementations. Why is this the case? In authoring the post, I was of the impression that Firefox is 100% compliant.

    This begs the question: "Whose implementation does this book emphasize/teach?"

    • whoa daddy (Score:2, Informative)

      by rebug ( 520669 )
      Whoever told you that Firefox was "100% compliant" was selling something.

      Firefox whiffs some CSS2.1 rules [chipx86.com] among other things.

    • Re:Web standards!!?? (Score:4, Insightful)

      by nine-times ( 778537 ) <nine.times@gmail.com> on Tuesday May 17, 2005 @05:25PM (#12560176) Homepage
      Well, I think for the most part it's not intentional. You know, there are occasional rendering bugs-- not the sort of thing you see on most pages. Usually it's in aspects of the standards that aren't used that often, and so they just tend to go unnoticed by users, and they aren't a big priority for the developers.

      Sometimes the standards are just vague enough that cases pop up where it's not clear what the rendering engine is supposed to do, or the standards don't cover every possible case, so each browser might handle those cases a little differently.

      So, I guess the thing to remember is that the W3C sets down what each tag should do and how, but then the people making the browsers have to actually come up with a system that takes those tags and does those thing with them. It's just not as easy as plugging in the W3C standards and you have a web browser.

    • Re:Web standards!!?? (Score:5, Interesting)

      by telbij ( 465356 ) on Tuesday May 17, 2005 @05:30PM (#12560228)
      Why is this the case? In authoring the post, I was of the impression that Firefox is 100% compliant.

      The reason is because the spec is incredibly difficult to implement. Mozilla is damn close to full compliance, but the fact is that the CSS spec suffers from varying levels of vagueness when it comes time to actually sit down and implement a rendering engine.

      The real problem is that it's impossible to anticipate all the ways that people might attempt to use CSS, and the gray areas can really only be standardized by browser makers after years of web development by the public at large. CSS 2 is really just starting to hit its stride now that Netscape 4 is effectively dead, but it won't be able to take another quantum leap until IE6 is dead (assuming IE7 makes good on their standards-compliancy promises).

      Sadly, web design is one of the most difficult technical disciplines because browsers grew like cancer in the 90s and now the browser makers are all obligated to support all that cruft. IE has some truly mind boggling bugs that will probably have to remain because people depend on that buggy behaviour.

      Ah, well, that's job security for me.

      • Re:Web standards!!?? (Score:3, Insightful)

        by Carewolf ( 581105 )
        No it is not. Firefix has about 90% of CSS 2.1 and XHTML implemented and they have saved the hard parts for last. It seems Gecko is not very easy to extend with new basic functionality. Just look at how much trouble implementing "display: inline-block" have caused.

        Both Opera and Konqueror have implemented a lot more.
      • Why not just throw out everything and have everyone use COBOL?

        Hey! It uses sentences, you set up what the screen should look like in advance, and it can now even handle graphics. What more could you want?

        ;-)
        [For the joke impaired - this is a joke!]

      • Re:Web standards!!?? (Score:2, Interesting)

        by bjdevil66 ( 583941 )

        These are all great points, and I can't wait for CSS2 to be more fully implemented and for IE6 to be replaced to allow more robust CSS2/XHTML development.

        However, as broadband usage propogates, web dev products that can deliver entire web applications to the desktop/browser before the content is even seen (such as Macromedia's Flex or MS's XAML) will eventually become the tool of choice for web development because 1) they ensure "standardized" layout, and 2) the end product is much sleeker and user-friend

  • Yeah, I'm getting ready... (Score:4, Funny)

    by ilikeitraw ( 706793 ) <dca_102@hotmail.com> on Tuesday May 17, 2005 @05:06PM (#12559966)
    ... to launch my CSS3 compliant site.
    I setup my cron to push the site live in 2007.

  • Elaboration? (Score:5, Insightful)

    by Capt'n Hector ( 650760 ) on Tuesday May 17, 2005 @05:06PM (#12559969)
    Strategies overcoming browser quirks are discussed throughout the book.

    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.

    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Tuesday May 17, 2005 @05:14PM (#12560053)
      Comment removed based on user account deletion

    • Re:Elaboration? (Score:5, Informative)

      by telbij ( 465356 ) on Tuesday May 17, 2005 @05:17PM (#12560087)
      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.

      Absolutely. There are a million tutorials that will teach you all about CSS in theory, and once you have a reasonable base knowledge you can actually go into the W3C spec [w3.org] itself and dig into the details, but when it comes time to make your pretty new XHTML/CSS2 page work in IE you better have a boatload of knowledge.

      After 5 years, and the thankful death of NS4 and IE5 (for the most part), I can debug my XHTML/CSS pages extremely efficient, but good references are still necessary. My two favorites:

      CSS-discuss mailing list wiki [incutio.com]
      &
      Position is Everything [positioniseverything.net]
    • I agree that compatibility is the longest, most time consuming and boring part of developing a website.

      The problem is that any book that has a comprehensive list of browser bugs will be outdated by the time it hits the shelves. Firefox and Mozilla change quickly, Opera and Sefari, nearly as quickly. IE is the only thing that hasn't changed much recently, but with IE7 coming out soon, the only thing the book could cover are old and unsupported browsers anymore.
    • Do you know what I want to see? I want to see that killer app that everyone wants to use require Firefox or another decently CSS-standard following browser.

      Imagine if GMail, even just in it's beta phase, had said 'Sorry, Internet Explorer does not support the features necessary to use this website. Download Firefox for free here [getfirefox.com].' Imagine what that could have done to pressure microsoft to start supporting the standards.

      I really think all it's gonna take is somebody with the right application that everyb

  • Baby + Bathwater (Score:5, Insightful)

    by 99BottlesOfBeerInMyF ( 813746 ) on Tuesday May 17, 2005 @05:08PM (#12559987)

    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.

  • XHTML brings some nice and obvious changes to HTML (such as single tags for new paragraphs), but at the same time, I don't understand why "strong" is better than "b" for bold, or "em" is better than "i" for italics. IMHO, less typing is better, even if most people now use some sort of graphical editor like Dreamweaver.

    • Re:Gilding the lilly (Score:5, Informative)

      by tehshen ( 794722 ) <tehshen@gmail.com> on Tuesday May 17, 2005 @05:18PM (#12560102)
      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. [think-ink.net]
    • The term's "semantic markup". Basically the notion is that using more descriptive tags can potentially tell user agents (be they browser or spider) a little bit more about the content.

      However, it's not solely in XHTML. The tags exist in HTML 4.

      I'm personally amazed that people talk so much about the strong and em tags so much when there's a ton of nicer introductions such as label [w3schools.com] and optgroup [w3schools.com] that get little to no press.
    • "strong" is a semantic definition while "bold" is a typographical one. What does "bold" mean to a text-to-speech device? The same holds for "em" or "emphasis".

      The purpose of XHTML is to decouple the presentation from the information. "strong" just tells whatever is interpreting it to do whatever it thinks is best to make it stand out.
    • I don't understand why "strong" is better than "b" for bold, or "em" is better than "i" for italics. IMHO, less typing is better, even if most people now use some sort of graphical editor like Dreamweaver.

      Part of the idea in those renamings is to increase the separation between content and presentation. In the two examples you give, changing the semantic behind the markup allows them to imply content information instead of presentation information. "b[old]" and "i[talics]" specify the appearance of a b
  • It seems as if everyone and his brother is writing books supporting standards-compliant Web design with XHTML and CSS.

    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.

  • Web standards are stupid. (Score:4, Insightful)

    by Anonymous Coward on Tuesday May 17, 2005 @05:12PM (#12560037)
    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 <font> nor CSS). None of that was in the standard (HTML 2.0) at the time.

  • XHTML is a bad solution (Score:5, Interesting)

    by Enrico Pulatzo ( 536675 ) on Tuesday May 17, 2005 @05:12PM (#12560039)
    I don't understand why designers and technologians keep preaching XHTML. It's at best a kludge. Until you start serving XHTML documents with the correct mimetype (application/xhtml+xml I believe) XHTML provides no benefits over plain old HTML (provided you stick to the spec). Until then, User Agents will continue to accept whatever crap you throw at them, and since you're not using real XML you won't see any errors (except for the rendering).

    I coordially invite someone to give me one reason why XHTML (in its current form, served as text/html or text/xml) is better than HTML 4.0 strict? Is closing my link and meta tags really that life-changing?

    • Re:XHTML is a bad solution (Score:5, Informative)

      by imputor ( 841598 ) on Tuesday May 17, 2005 @05:21PM (#12560130) Homepage
      A couple reasons...

      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.

      • I write my HTML by hand, using Emacs, so the way my html looks is important to me.

        Which is more readable?

        --

        This is a paragraph.<p>

        <img src = "foo.jpg" height = 20 width = 30>

        This is another paragraph.<p>

        --- or ---

        <p>This is a paragraph.</p>

        <img src = "foo.jpg" height = "20" width = "30" />

        <p>This is another paragraph.</p>

        ---end---

        This kind of issue is why I have resisted changing to the likes of XHTML. I want my code to be easy to read instead of m

        • Re:XHTML is a bad solution (Score:4, Insightful)

          by renderhead ( 206057 ) on Tuesday May 17, 2005 @06:15PM (#12560775)
          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.

      • Re:XHTML is a bad solution (Score:5, Insightful)

        by Enrico Pulatzo ( 536675 ) on Tuesday May 17, 2005 @05:34PM (#12560263)
        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.

      • Re:XHTML is a bad solution (Score:4, Informative)

        by poot_rootbeer ( 188613 ) on Tuesday May 17, 2005 @06:03PM (#12560622)
        You seem to assume that CSS can only be used with XHTML, and that "HTML" means "font tags aplenty". This is not so. CSS can be used in conjunction with any version of the HTML or XHTML markup languages.

        The only real differences between XHTML and the non-X versions of HTML that came before it are:

        1. DTD declarations are mandatory. Or if not mandatory, strongly encouraged. Sort of.

        2. Case is no longer insensitive, except usually implementations of it still are.

        3. Non-pairing tags have to close themselves with a trailing slash.

        4. Attributes have to take the form of name/value pairs.

        5. There's a bunch of tags that are deprecated, but you can still use them because no browser authors will ever remove support for them or even refuse to render a page if it doesn't validate against the DTD.

      • Re:XHTML is a bad solution (Score:2, Informative)

        by Anonymous Coward

        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.

        This is not true. XHTML includes things like the <font> element type. Mod parent -1, Clueless.

        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.

        You could have got the exact same saving if you had moved from HTML t

    • 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.
      • Namespaces do indeed rock. They make some tasks possible which were before impossible, and they provide a means to combine languages together in a way which wasn't possible before.

        However, XHTML (in it's current form) totally breaks namespaces, since the mimetype of the document is text/html and the user agent only expects (or rather, should only expect) to be receiving text/html content (instead of a mish-mash of XML dialects).

        I think namespaces are most useful (and powerful) in more controlled environm
    • 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 main
    • I coordially invite someone to give me one reason why XHTML (in its current form, served as text/html or text/xml) is better than HTML 4.0 strict?

      Purists always like to trot out this argument, because of course it's true that IE pretty much guarantees you won't be able to send the proper mime type for a long long time to come.

      But come on, foregoing XHTML syntax because of this minor issue (which will be easily fixable for all your legacy documents 10 or 15 years from now) is pretty much cutting off your
      • XHTML does indeed mean easier parsing, if served with the correct mimetype. If you serve text/html, the parser has to be ready for all the crap of HTML, not the ease of parsing an XML document (unless you run all the incoming text/html into something like tidy, but that's cheating).

        I'm not quite sure I understand your point about better code support in the future though, would you expound on that? Do you mean that this is the area where people are actively developing, so there will be better tools in the
    • XHTML is better, because there is a greater chance that the page will look like how you intended. This has nothing to do with how the page looks in the browser (that's standards), but how the browser parses your page.

      Suppose your page had this here mystery tag in it:

      <foo>

      What should the browser do? Should it do something and leave it at that (like <br>) or do something and enclose all the rest of the page in a <foo> block then try to sort out the rest of the page when it thinks the tags
    • I coordially invite someone to give me one reason why XHTML (in its current form, served as text/html or text/xml) is better than HTML 4.0 strict? Is closing my link and meta tags really that life-changing?

      Using /> instead of >, no. That won't make a great deal of difference. However, getting into the habit now will make it easier when you DO start sending the correct mimetype (read: when IE evolves out of the 20th century).

      The main advantage I see is not the /> stuff, but the fact that closin
    • ...Unless you, like me, serve application/xhtml+xml. In which case your entire arguement is invalid. True, I serve as text/html to MSIE, owing to Microsoft's browser's inability to comprehend anything else. However, Gecko and KHTML browsers get application/xhtml+xml and XHTML 1.1-valid documents. That's what server-side scripting (php in my case) is for! So stop posting about how XHTML is useless because of wrong mimetypes. Not -everybody- uses the wrong mimetype. :)
      • Yours is a good point, though I'm not too big of a fan of forcing every page I write to be parsed with an engine first. (and no, I don't have access to the apache server httpd.conf/.htaccess file :( )

        However, I did come across this little beauty [annevankesteren.nl] that gives me a little hope. It seems you can indeed serve xhtml as application/xml in IE and make it work (of course, with a small workaround).

        Soon of course, lynx will have to be updated in order to keep up with the times :)
  • Macromedia, Adobe and gang have to push things forward to keep getting us to buy product right. Is HTML now "designed obsolescence"?

    No

    Jakob Nielson and the gang have pushed us to really boring text based browsing that is a chore to read, and not worth a casual flipping. Why should *I* care if my website is Modem/text based browsing compliant? Sure if I had a research website I can see the point, but my website is a video hosting portal http://videos.streetfire.net/ [streetfire.net] [streetfire.net] so I doubt the 40

    • Pre-excuse: I'm not entirely sober right now...

      HTML 3? [w3.org] - 330 errors. Nearly as bad as /. ;)

      Personally I will be glad when dinosaurs like yourself finally become extinct - sure i'm just some young 'whippersnapper' compared to you, i've only been doing website development since 1998 but I have adopted my practices as the nature of the web has changed, both for the benefit of low-bandwidth users, disabled users and such as well as for myself. Doing all styling with a CSS file makes my life an order of mangi

      • Replying to myself because I forgot to mention one very important benefit: Being able to target stylesheets to specific devices is wonderful - all of my sites look as good (although differnet) in handheld browsers, when people print out my pages they get a clean copy with few or no colours, no superlous navigation etc etc.

  • That's great if your site is only visited by geeks (Score:3, Insightful)

    by sharkb8 ( 723587 ) on Tuesday May 17, 2005 @05:18PM (#12560104)
    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?

  • plain HTML has to go ! (Score:5, Insightful)

    by cablepokerface ( 718716 ) on Tuesday May 17, 2005 @05:20PM (#12560115)
    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.
    • think of your customers, think of your bandwith

      1. CSS based designs use less bandwidth, because stylesheets are cashed.

      2. Think of yuo customer's customers. Specifically, those using browsers other than ie, those on cell phones, those who are using screen readers etc.

    • Yeah, have a look at any commercial web sites (ie. MacroMedia). They're all using HTML 4.01 transitional (or lower) and tables for layout.
      And the reason is, is because it's the only way that they can make their web sites look good on all browsers.
      • The parent doesn't have a clue what they're talking about. Saying that using tables for layout and HTML 4.01 is the only way to make web sites look good on all browsers is complete bull. Anyone who actually knows how to use CSS properly will see how simply it is to create a nice layout, and it's not all that hard to make it work on all browsers.

  • Another recommendation for beginner's.. (Score:4, Interesting)

    by x.Draino.x ( 693782 ) on Tuesday May 17, 2005 @05:20PM (#12560116)
    Although I haven't read the book this review is about. I recently purchased another book titled Web Standards Solutions: The Markup and Style Handbook [amazon.com] by Dan Cederholm and found it very good for beginner's to XHTML and CSS. Even my wife, who's never dabbled in web design before is enjoying it. Also, quite a few of the chapter's in Dan Cederholm's book appear on his website [simplebits.com] if you want to get a feel for his writing style.

  • Old? (Score:4, Insightful)

    by HRbnjR ( 12398 ) <chris@hubick.com> on Tuesday May 17, 2005 @05:28PM (#12560201) Homepage
    it provides a nice framework guiding "old dogs" like me into standards-compliant code.


    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.

    • Absurd. (Score:3, Insightful)

      by Roadkills-R-Us ( 122219 )
      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.
  • did someone forget the tag?

  • Posting on eBay (Score:3, Insightful)

    by Newt-dog ( 528340 ) <`moc.wocmotnahp' `ta' `god-twen'> on Tuesday May 17, 2005 @05:45PM (#12560394) Homepage
    Try posting a custom layout on eBay with a few whistles and buzzers -- your layout will suck.

    I did a page layout on eBay [ebay.com] 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

  • They'll get my bold tag... (Score:5, Insightful)

    by Cr0w T. Trollbot ( 848674 ) on Tuesday May 17, 2005 @05:46PM (#12560417)
    ...when they pry it out of my cold, dead mouse!

    That said:

    "Newer, more compliant browsers, will in time not support the older tags and code
    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

  • OK, so that's a good book, but how about good websites for XHTML + CSS authoring? Preferrably with DOM 1+2 documentation too, more accessible than the raw specs at W3C?

    I've looked around a bit for this, for a browser neutral site and not something riddled with stuff related to IE extensions.

    Is W3Schools among the most thorough? It's at least one spanning several web technologies, but not so sure about the depth of it...

    I find it hard to just search for these things on Google as then you're greeted with d

  • is anyone moving to xhtml? (Score:3, Funny)

    by yagu ( 721525 ) <yayagu@[ ]il.com ['gma' in gap]> on Tuesday May 17, 2005 @07:37PM (#12561496) Journal

    Just curious, after reading the fine article, then doing a little research and reading a couple chapters of the w3c documents I wonder that anyone would change to xhtml for the sake of canonical righteousness.

    Seems to me there are reasons to do xhtml... I DO like the idea of well formed objects, especially things like web pages... at least if it's well formed you've eliminated one source of nasty little bugs creeping into sites, especially sites creating pages dynamically.

    But, for sites already rolled out and wrung out in public forums this seems prissy. And problematic. Consider:

    • what would we do with sites where users can contribute their own html (hmmmm, a particular site comes to mind...)

    I've done an informal look-around, and found some popular and quite famous (hmmmm, a particular site [slashdot.org] comes to mind...

    So, academically maybe a good direction to consider, but the predictions of html going away to be supplanted by xhtml is premature, and I predict something that in our internet lifetimes will never happen.

  • HTML or XHTML? (Score:4, Insightful)

    by Phantasmo ( 586700 ) on Tuesday May 17, 2005 @08:32PM (#12561949)
    XHTML is a good idea but have you noticed how verbose and complicated it's gotten?

    <?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.dtd ">
    <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>

  • HTML4 + CSS (Score:3, Interesting)

    by zpok ( 604055 ) on Wednesday May 18, 2005 @05:11AM (#12564461) Homepage
    I don't see what XHTML offers me that HTML4+CSS doesn't. I've been "separating code from content" from the day I could dismiss the font tag, I don't see what XHTML offers to a non-programmer (I don't think using markup==programming and I know I'm not good at anything that requires more thinking than that...).

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close