Slashdot Mirror
Designing With Web Standards
Trent Lucier writes "If you've browsed the web design section of any bookstore lately, you've seen him staring at you. The blue hat. The mustache. The blinding neon background. He's Jeffrey Zeldman, publisher of the influential web development magazine, 'A List Apart' and author of the book Designing With Web Standards (DWWS). The first edition of the DWWS was published in 2003, and now 2006 brings us an updated 2nd edition. In a market flooded with XHTML, CSS, and web standards books, is DWWS 2nd Ed. still relevant?" Read the rest of Trent's review for the answer.
Designing With Web Standards, 2nd Ed.
author
Jeffrey Zeldman
pages
410
publisher
New Riders
rating
8.5
reviewer
Trent Lucier
ISBN
0321385551
summary
Foundations for creating standards-based websites using XHTML and CSS.
DWWS is more of a survey course than a deep dive into a particular topic. In fact, a large part of the book is dedicated to the philosophy of web standards, as opposed to their specific implementation. The reader is given background information on the turbulent early years of the web, when Netscape and Microsoft battled each other with proprietary features, driving coders crazy and sending development costs through the roof. Inconsistent support for HTML, JavaScript and CSS often meant that a single page had to have multiple versions written to support different browsers. Predictably, many companies decided to "standardize" their websites on one browser (usually Internet Explorer), causing much pain for users who wanted or needed to use other programs.
Out of this mess came the web standards movement, whose goal was to encourage browser-agnostic design practices. However, the web standards proponents faced several problems at the outset. "Standards compliant design" was synonymous with "ugly." CSS was a 4-letter word, due to buggy and inconsistent browser support. Additionally, few people understood that standards compliance was a continuum and not an all-or-nothing affair.
Which brings us to Zeldman's book. Part 1 of DWWS explains the concepts above in terms that non-technical people can understand. The book states that it is for "designers, developers, owners, and managers..." Of course, the idea that a non-technical person would choose to read a book on web standards doesn't comply with what I like to call "reality." But tech leads may find some ammunition in these chapters for their arguments with management about the benefits of browser-neutral web design.
XHTML and CSS are the main focus of the second part of the book. Readers without any HTML experience will likely have difficulty following these chapters. Those with some experience will learn to master the DOCTYPE, tame font sizes, and conquer annoying Internet Explorer bugs.
Zeldman is a pragmatist, never forgetting that his readers live in the real world with real limitations. Some developers still have to support older browsers, or integrate with proprietary technologies (ex: Flash and Quicktime). He recommends solutions for these circumstances, letting his audience know the pros and cons of each approach. Early in the book, Zeldman states his motto of "No Rules. No Dogma." The book adheres to that statement, explaining that some standards can be maddeningly vague, or that the XHTML Strict DOCTYPE isn't for everyone.
As always, Internet Explorer 6 requires special attention. The (in)famous CSS box model hack is explained, in which jujitsu-like techniques are used to fix one IE bug (the way width is measured) by exploiting another (broken support for the CSS voice-family rule):
.content
{
width:400px; /* All browsers read this line */
voice-family: "\"}\""; /* IE chokes here and bails out of this block */
voice-family:inherit;
width:300px; /* Other browsers make it to the end and use the correct width */
}
Every time someone codes this, a kitten dies. But it is valid markup, and it is used by many standards supporters. A few references to IE7's improvements are sprinkled here and there, but this book was published before the browser was formally released so don't expect too much info.
One of the hottest topics in CSS is the pure CSS-based layout. Pure CSS layouts usually involve the concept of floating elements and calculating widths. In DWWS, we get a chapter dedicated to the hybrid layout. Hybrid layouts make use of CSS and HTML tables to layout a page, although the table usage is minimized. Zeldman is correct to take this approach, which gives readers practical advice and then lets them decide if they want to move on to more complicated CSS layouts.
The chapter on accessibility is one of the most illuminating. Zeldman has well-reasoned retorts to all the common graphic designer excuses for ignoring accessibility. Accessibility does not mean that a site has to be ugly. Rather, accessibility is something that happens under the hood, in the markup itself. The business case for accessibility is also strongly made. Think you can ignore blind users because your flashy site targets a small, hip audience? Be prepared to get punished by Google, since the GoogleBot is the most powerful blind user on the web ("The Blind Billionaire", as it is called in the book).
A brief chapter is dedicated to DOM-based scripting (aka JavaScript), and the discussion is mostly limited to what scripting can do, and not how to do it. The DOM (Document Object Model) is the model for describing the hierarchy of content on a webpage. Modern techniques like AJAX make extensive use of the intimate relationship between XHTML, CSS, and JavaScript DOM support. However, accessibility, usability, and maintainability are still challenges in the hyper-scripted world of Web 2.0. Zeldman doesn't offer much advice on these topics, but provides a book list for further reading.
I have not read the first edition of DWWS, but the second edition makes it clear where Zeldman has changed tactics and techniques. For example, the image replacement technique described in the first edition wasn't accessible in certain screen readers, so improvements are suggested in the second edition.
Overall, DWWS is a good book for web developers that already know the basics of HTML and CSS, but want to update their 1997 coding techniques. Those new to web design, however, may want to start with a book that is a little more comprehensive. Zeldman does a good job of explaining how to create leaner, lower-cost, and more maintainable web sites. On more than one occasion, I put down this book mid-sentence, loaded up my text editor, and was able to make a quick change to solve a problem that was bugging me. In a book dedicate to making the web designer's life easier, what more can you ask for?
Trent Lucier is a software engineer. His latest experiment is localhost80.com
You can purchase Designing With Web Standards, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
DWWS is more of a survey course than a deep dive into a particular topic. In fact, a large part of the book is dedicated to the philosophy of web standards, as opposed to their specific implementation. The reader is given background information on the turbulent early years of the web, when Netscape and Microsoft battled each other with proprietary features, driving coders crazy and sending development costs through the roof. Inconsistent support for HTML, JavaScript and CSS often meant that a single page had to have multiple versions written to support different browsers. Predictably, many companies decided to "standardize" their websites on one browser (usually Internet Explorer), causing much pain for users who wanted or needed to use other programs.
Out of this mess came the web standards movement, whose goal was to encourage browser-agnostic design practices. However, the web standards proponents faced several problems at the outset. "Standards compliant design" was synonymous with "ugly." CSS was a 4-letter word, due to buggy and inconsistent browser support. Additionally, few people understood that standards compliance was a continuum and not an all-or-nothing affair.
Which brings us to Zeldman's book. Part 1 of DWWS explains the concepts above in terms that non-technical people can understand. The book states that it is for "designers, developers, owners, and managers..." Of course, the idea that a non-technical person would choose to read a book on web standards doesn't comply with what I like to call "reality." But tech leads may find some ammunition in these chapters for their arguments with management about the benefits of browser-neutral web design.
XHTML and CSS are the main focus of the second part of the book. Readers without any HTML experience will likely have difficulty following these chapters. Those with some experience will learn to master the DOCTYPE, tame font sizes, and conquer annoying Internet Explorer bugs.
Zeldman is a pragmatist, never forgetting that his readers live in the real world with real limitations. Some developers still have to support older browsers, or integrate with proprietary technologies (ex: Flash and Quicktime). He recommends solutions for these circumstances, letting his audience know the pros and cons of each approach. Early in the book, Zeldman states his motto of "No Rules. No Dogma." The book adheres to that statement, explaining that some standards can be maddeningly vague, or that the XHTML Strict DOCTYPE isn't for everyone.
As always, Internet Explorer 6 requires special attention. The (in)famous CSS box model hack is explained, in which jujitsu-like techniques are used to fix one IE bug (the way width is measured) by exploiting another (broken support for the CSS voice-family rule):
.content
{
width:400px; /* All browsers read this line */
voice-family: "\"}\""; /* IE chokes here and bails out of this block */
voice-family:inherit;
width:300px; /* Other browsers make it to the end and use the correct width */
}
Every time someone codes this, a kitten dies. But it is valid markup, and it is used by many standards supporters. A few references to IE7's improvements are sprinkled here and there, but this book was published before the browser was formally released so don't expect too much info.
One of the hottest topics in CSS is the pure CSS-based layout. Pure CSS layouts usually involve the concept of floating elements and calculating widths. In DWWS, we get a chapter dedicated to the hybrid layout. Hybrid layouts make use of CSS and HTML tables to layout a page, although the table usage is minimized. Zeldman is correct to take this approach, which gives readers practical advice and then lets them decide if they want to move on to more complicated CSS layouts.
The chapter on accessibility is one of the most illuminating. Zeldman has well-reasoned retorts to all the common graphic designer excuses for ignoring accessibility. Accessibility does not mean that a site has to be ugly. Rather, accessibility is something that happens under the hood, in the markup itself. The business case for accessibility is also strongly made. Think you can ignore blind users because your flashy site targets a small, hip audience? Be prepared to get punished by Google, since the GoogleBot is the most powerful blind user on the web ("The Blind Billionaire", as it is called in the book).
A brief chapter is dedicated to DOM-based scripting (aka JavaScript), and the discussion is mostly limited to what scripting can do, and not how to do it. The DOM (Document Object Model) is the model for describing the hierarchy of content on a webpage. Modern techniques like AJAX make extensive use of the intimate relationship between XHTML, CSS, and JavaScript DOM support. However, accessibility, usability, and maintainability are still challenges in the hyper-scripted world of Web 2.0. Zeldman doesn't offer much advice on these topics, but provides a book list for further reading.
I have not read the first edition of DWWS, but the second edition makes it clear where Zeldman has changed tactics and techniques. For example, the image replacement technique described in the first edition wasn't accessible in certain screen readers, so improvements are suggested in the second edition.
Overall, DWWS is a good book for web developers that already know the basics of HTML and CSS, but want to update their 1997 coding techniques. Those new to web design, however, may want to start with a book that is a little more comprehensive. Zeldman does a good job of explaining how to create leaner, lower-cost, and more maintainable web sites. On more than one occasion, I put down this book mid-sentence, loaded up my text editor, and was able to make a quick change to solve a problem that was bugging me. In a book dedicate to making the web designer's life easier, what more can you ask for?
Trent Lucier is a software engineer. His latest experiment is localhost80.com
You can purchase Designing With Web Standards, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
In my experience, you can do it with standards, or you can make it look like the client wants it to look like, which requires at least two sets of scripts for the diferent browsers. Then you run into things like ActiveX maps and OWC objects and give up on it working in anything other then IE. Then you go have a stiff drink.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
How do we priorize? is standards how a browser and a web page should work or how the mostly used browser works? How much can standards be enforced to something that is the most popular?
+1 Agree -1 Disagree
I would love to see a listing of all the CSS and HTML that is fully-supported by both IE7 and Gecko. That would allow me to Write-It-Once and still stick to what the W3C says. I have no interest in CSS that only works in one of the Big Two browsers.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
As an owner of the first edition, it is a must own title for anyone into webdesign and programming. If only Microsoft started to adhere to the W3C specification, the world would be a better place.
A book on standards that decries rules and dogma. Only on Slashdot could this garner an 8.5.
It sounds like this should have been two books -- one about the history of web standards, and one about how to design for the web, optionally complying with standards.
Picking and choosing which ones you'll follow is about as useful as just writing what you know will work for everyone, except it's a bigger pain in the ass. At the end, you have the same thing: A website that doesn't actually follow any standard. How much hair you pull out in the process is the only real difference.
Like I'm going to take advice on how things should look from a guy with a moustache.
It's very short. Exceptionally short. .. but I may be first to market!
http://www.bitworksmusic.com/
BitWorksMusic.com -- odd tunes for odd times
That was from a year ago. Now even he has seen the light and is starting to build standards-based sites. It just took a while.
One invaluable resource for identifying browser CSS support is this page which has nice pretty colors showing the amount of support.
People are never as simple as their stereotypes. This applies equally to Christians, Muslims, and Emacs-lovers.
Examing the parent's link to Amazon, one can see that a referrer link, kaleidojewel1-20, is present.
I find your ideas intriguing and I would like to subscribe to your newsletter.
You set it up in a layout table and use CSS to control what it can be relied upon to control consistently.
"Here's what's happening. You're starting to drive like your Dad..." - Red Green
Standards-based design is not just about browser compatibility. It's also about separating style from content. Tables are for tabular data, not graphic design. What you describe is the HTML equivalent of spaghetti code, and it's one of the main targets of Zeldman and other of proponents of standards-based design.
HTML (unlike, say, PDF) is not a layout language. Tags are meant to describe the content they enclose, not specify how it is to be displayed. It is the job of CSS to present that content in different contexts. Violating that separation, for example using tables for layout, makes maintenance difficult because content and style cannot be modified independently. It denies users the ability to re-style your content (e.g. with custom stylesheets). It creates barriers to accessibility for those who do not interact with computers visually (e.g. those with disabilities), or who use other devices to access the web. It misrepresents the content of web pages to machine analysis - search engines, for example, use tags to determine the role and importance of text on a page.
Of course, the reality of the HTML and CSS standards and their support in popular (*cough*) browsers is somewhat different. It is sometimes necessary or practical to misuse HTML as you describe. But it should not be done without an understanding of the standards and the consequences of ignoring them. Books like Zeldman's give designers and developers the knowledge and tools they need to use HTML and CSS correctly where possible, and to minimize abuse otherwise.
For some reason, programmers seem to be trailing designers when it comes to understanding how to use HTML and CSS correctly. They figure if it looks right, it must be right. That was certainly my attitude. Perhaps it's because we don't take designers or HTML seriously ("it's not Turing complete!"). I don't know. But do read Zeldman or Eric Meyer or someone like them, either in hardcopy or online. Knowing how do this stuff right made me a much better web programmer.
Do we really need another standards book? First of all this thing is going to be defunct within at least 6 months and second I don't know a single self-respecting web developer that cracks a book when working on a site. Yeah, I just skimmed the article but it just seemed like a total rehash of the last five or six books that were thrown up here. I mean, if it were an E-Book of some sort then I might be into it because I could reference it while working at my station but honestly if its got a spine and paper then I dont have time to get my fat butt out of my chair and go to the shelf to look up a technique when I could just as easily find it in two seconds on google.
Hybrid layouts make use of CSS and HTML tables to layout a page, although the table usage is minimized. Zeldman is correct to take this approach, which gives readers practical advice...
I felt a powerful disturbance in the force, as if thousands of CSS-P zealots died reading this.
Just painful, at least until you get used to it. I'm trying to develop an entire web based (graphical, 2d overhead) MMO, following XHTML 1.1 and CSS standards. PHP and Javascript for life :)
It's never just a game when you're winning. - George Carlin
Many of the more persistent issues in IE6 aren't due to impelementation of the CSS standard (or lack thereof), but rather of bugs. I mean, sweet baggigty, how on Earth can you predict if IE6 is going to double the margin on a floated element or not? Hell, it's a "here today, gone tomorrow" issue for a full-time web designer.
And don't get me started on the peekaboo bug. That one alone took me a day and a half to figure out. For the most part, IE7 will respect web standards (and hell, even better than Firefox 2 in some places), but for IE6, and parts of IE7, you just need to build a nigh-encyclopedia knowledge of various bugs and workaround.
A List Apart and are fantastic resources for bug hunting
I was at a meeting recently where a Mozilla Foundation official said roughly, "Mozilla doesn't necessarily follow W3C standards because the individual developers in the open source model have to take the initiative to follow them, and if they don't want to, it doesn't happen."
Item 7 was a surprise:
http://www.librarything.com/unsuggester/1426655
Now wash your hands.
As a web developer of 7 years as my main source of income, web standards is a waste of time. Personally I try to adhere to them as much as humanely [no, that's not a typo] possible. "Web Standards" changes constantly with what is "in" and "cool." Right now the big thing is AJAX. I, personally, have never used it and I suggest everyone else does the same. Except in situations like Google's Writely. Web Applications are useful, but not necessarily worth the effort. Because "Standards" never actually stay put, I have this to say:
Web Standards is an Oxymoron.
Thank you for your time.
Let's hold our horses and calm down a bit. You are confusing data with presentation. HTML is for content description, CSS is for presentation. Use the right tool for the job, and you can get the effect you want - without using HTML tables. And you will gain accessibility, maintainability, and so on.
The banners, nav bars, headings etc. that you mention are not tabular data. They do not necessarily have rows and columns. A navigation bar, for example, is typically one-dimensional, not two: it's a list of links - hence current best practice is to represent it in HTML as a list (<ul> or <ol>). Because these things are not tabular data, they should not be represented in tables.
Again, HTML is not a layout language. HTML tables are more like database tables than a grid system; like database tables, the relationship between rows and columns exists regardless of what they look like. The browser chooses how to display that information - typically in a tabular format, by applying CSS. That's right, CSS that specifies the layout, not HTML. You can use <div>s instead of <table>, <tr> and <td> tags and still display your information in a tabular format by applying the correct CSS table properties. These properties are about presentation, they say nothing about the nature of the data.
In your case, the banner should probably be something like <div class="banner">, the headings should be <h2>, <h3> etc. (that's why they're called heading tags), and the columns should probably be <div>s, located correctly with CSS (there are some very clever ways of doing this involving negative margins and the like (see A List Apart), none of which force you to misrepresent your data as tables - though in a few cases, using a table for columns is the most practical solution).
No one is telling you what your web pages should look like. They are, however, recommending the most effective, flexible, accessible, and maintainable ways of getting that look using the tools available. Using tables for layout is seldom any of those things.
As an owner of the first edition, it is a must own title for anyone into webdesign and programming. If only Microsoft started to adhere to the W3C specification, the world would be a better place.
Yea, I got the first edition years ago then when I found out the second ed came out I got it right away. I'd like to get a good book on CSS too, perhaps one of Meyers. What I'd really like to get though is a good book on accessibility, while following web standards helps a lot there's more to accessibility than just this, for instance the Fog index, on readability.
FalconShould there be a Law?
Who was the idiot that decided now that we use css for our layouts that tables and such can just be deprecated. Tableless layouts are NOT a good idea, although the need for tables has dropped significantly since the introduction of css.
For example, in the header of my site, I want 3 columns, a left,right, center, with different aligns on each.
The "CSS" solution would look something like this.
<div class="header">
<div style="float:left;text-align:left"> Left Content </div>
<div style="float:right;text-align:right"> Right Content </div>
<div style="text-align:center"> Center </div>
</div>
Now this may not have any tables in it, and produces 3 columns, the float order is odd (if I put the float:right after the center, it'll start on a new line since it's after a non-floating div). Also Floats tend to not resize that well in firefox for some reason, leaving ugly trails that look like dragging around a window on a frozen windows desktop.
Now when I start adding more and more content and fine tuning it in the floating div's, it starts to become a confusing mess and become hard to tweak and manage precisely.
With a table, the same effect is achieved with slightly less code.
<table width="100%"> <tr>
<td align="left"> Left </td>
<td align="center"> Center </td>
<td align="right"> Right </td>
</tr> </table>
Also, lets not forget the fact that my table can be fully styled with css as well. So my point being that don't use div's for a solution where another tag exists to solve your problem.
It's good css practice (not professional practice, educational FOR LEARNING practice) to write a site completely in div or spans, but most these other tags are not going anywhere soon, and provide context for your document, for example, in a layout I'm working on now, I use styled <ol> to achieve the same effect that I would traditionally get from a table. I could also achieve the same effect using a series of divs or with styled tables. Although the <ol> makes the most sense when viewing the source because the nature of the content in it is a list, a series of divs or a table would make it a lot harder to immediately distinguish this list.
Css opens possibility of styling your html in many ways, but I can't emphasize this enough CSS IS NOT XHTML, it does not excuse you from ignoring tags because a div with the proper css can produce the same effect. Just because you can do an entire site with only div tags does not mean you have to.
HTML is there now to provide context to the document, and if something is a list, it should be stored in a <ol> or a <ul>, if something resembles a table, it should use table tags, etc.
The idea is that the implementation of the html and the css should be done in which the html document shows clear context, and the css should be based on that context so that there is a clear separation between data/display. using divs and spans only makes it hard to identify context (aside from the classes your using). And when you spend more time solving a problem with div's that a table would still solve in 10 seconds, then you are wasting your time.
When someone makes a site that's IE only, he's not just hurting firefox and opera users. It makes it much more difficult for it to be compatible with future versions of IE. Such short sighted thinking...
Firefox Power http://firefoxpower.blogspot.com/
Oh and that's a myth haunting us from 1995-6 by the way. Tables are as accessible as they can be nowadays, especially if used in moderation.
Ever experienced a table with a screen reader or braille display? True tested and used in moderation tables can be accessible but how many do the testing?
FalconShould there be a Law?
Nothing brings home a rant about poor web design like wrapping your post in <tt>.
Well done! </sarcasm>
If you were a serious contributor, you'd define "poor HTML production". What has hampered the web more than anything else is poor interpretation of existing standards . If nothing else, the first browser wars did their best to annihilate as many "standards" as possible.
On the web, MSFT may have a point; even if it isn't good, it should look good. Using hybrid or even table-based layouts is a necessary evil in certain cases.
Now, where is that "Blind Billionaire"? I have a bridge to sell.
This post © Copyrite Duggeek, all rights reversed.
True, but my question has long been: why is CSS not better at layout? Say I want a page with a header, three columns of content, and a footer that gets pushed down according to whichever column has the longest content. That's a very common layout task, and it's dead simple to do with a table, but so difficult with CSS that (the last time I checked) it was considered a difficult problem even for authors of CSS books! (I haven't tried your link to the Holy Grail on A List Apart, but you must admit that a layout solution that relies on negative margins is the very definition of a kludge.)
Don't get me wrong: I love using style sheets, and most of the time I'm grateful for CSS. But I hate it that some important things that were once easy have now become hard, all in the name of avoiding tables.
Q: What does the "B." in Benoit B. Mandelbrot stand for? A: Benoit B. Mandelbrot
I totally agree. I tried to be a CSS-zealot for a while. I even made the mistake of trying to totally avoid tables except for 'tabular data' and I am seriously paying the price for it now in the application I'm working on. It's very tempting to go back and rework it so that I don't have to worry about it any more.
The issue? jQuery. There's a TON of neat things like slide and calendar than simply break my CSS, no matter what I do. If I'd designed more simply, with a well-placed table or 2, then I'd have a great looking interface AND be able to use jQuery's Interface plugins.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
Yada! Yada! Yada!
Table-less layouts enable you to change the layout of your website without the need of rewriting a single line of HTML...
Good luck making one of those -td- go from left to right...
Table-based layouts are for WYSIWYG wannabe designers/developers.
You are probably still using gif-based whitespace.
Well the goal of any good developer should be to implement the solution as elegantly and simply as possible. Being a css-zealot is not bad, as long as you don't go out of your way to say "look what css can do". It's about using the right tools for the job at hand.
And you aren't defining the specific px placement of the div because...?
Your fault for using style=float:left
But honestly, I know what your saying, with your example its gonna be a problem when the new CSS 3.0 gonna be implented and most webdesigners will use the div border image tag...and we all know the old browsers won't support it, nor some new ones until a later time. To solve this you will need to create a table around the div, so you can have that border image effect.
Honestly, we are all screwed unless something changes, either all browsers are to follow one standard, or webdesigners keep the code they have and not go with the new simplistic way of making things.
No IE7 coverage to speak of? WTF?
The only point in actually buying one of these books is to have a current and comprehensive breakdown of what works and what doesn't. Rather than finding one webpage that discusses one issue.
You were too lazy to use the nine characters ?
If you're too lazy to type nine extra characters, why should anyone bother to read your point of view?
That's what I used to do too, until I read Zeldman. I loved it. One of the big disadvantages, however, is that you lose the semantics of HTML (such as they are). Those semantics are valuable - for search engines (clean HTML can make a big difference) and for other applications. There aren't a lot of data formats as well-understood and universal as HTML; that's worth taking advantage of. Remember, your HTML is likely to outlast whatever data source you're pulling your content from.
These days I depend on those semantics. I've been doing DOM work with Javascript to add dynamic annotation with margin notes and highlighting to web pages. I need to know the content model so I can determine where I can insert tags to add highlighting (<em> can go in <p> but not in <style>, for example). I locate highlights by counting words, so I need to know where words break. Block-level elements break words, while inline elements don't (so in your example you need a minimum of div, a, and span). I also collect other metadata, like the title and author of the annotated content, and so on. I do that by looking for elements in the document tagged with specific microformat classes.
What are the benefits? Well, if you look at my code, the output of my Javascript or my Atom feed, the information is all meaningful in a standard way. This can reduce or simplify glue code if you need to work with my data - and I think the universal experience with glue code is that although it seems simple and brainless, it gets heavier and heavier until it places serious limits on application complexity. Over time, I hope this kind of standardization can slowly lead to apps and libraries being easier to plug together. The standardization of HTML, and the shared meaning of some of its elements has already proved a huge win on the Web, messy, inconsistent, and broken as it is.
But I'm a geek of simple pleasures. Right now, I'm just thrilled that my transport format I picked - Atom (with embedded HTML) - is machine readable and shows up with sensible formatting in a generic feed reader. (I couldn't afford to use HTML if were a layout language, because then changing the look would break my machine parsing.) It's not rocket science - but that's kind of the point.
I agree too.
if you need columns, tables have columns. use a table. a div is not a column without some extra effort.
Bottom line: use the tags for how they behave naturally first, before applying style.
just because you can style a div tag to behave as a column doesn't mean you should.
you can also style a headline tag to behave like a column, but it also doesn't mean that you should.
The path of the zeolet is never easy, and sometimes even blind.
It's funny, first you say that using tables for layout is justified, then the rest of the post is the argument that the HTML should reflect the nature of the content, which can then be styled by CSS. Which is of course exactly the argument against using tables, since after all your entire page is not tabular data.
I've been having more fun with HTML since I really "got" seperating content and style; you find out about new tags you never knew about, like <address>, and I didn't even know about <dl> tags until recently. The <div> tag should be used as a last resort, when no other HTML tag fits the bill; that's usually the case for blocks that are just layout units.
All that said, the three column layout is used so often, is so simple with tables and so complex to do well with divs (especially when you want them to be equal height automatically), I think using them there is justified. But that's about the only exception.
I believe posters are recognized by their sig. So I made one.
The CSS 2 standard actually supports table-based layout applied to any markup. However, it's one of the many things that Microsoft simply haven't bothered to implement in their butchered tag soup layout engine. Let's not blame CSS here, but instead blame the one browser that leaves out the two most important layout features of CSS: the table model and generated content. With those two things, the common grid-based layouts that we all desire would be so much easier to create.
There are still several things missing in CSS2, of course. Many of them are addressed in CSS3, but I doubt that'll ever see the light of day.
Not at all! It's not in any way good practice to use divs and spans except where there's no more appropriate element! What you're talking about here is HTML development, not CSS development. You can't do CSS without HTML to hang it on (well OK XML, but let's not get into that).
One of my pet hates is sites which have source code consisting entirely of divs with no semantic markup whatsoever. If you can point to any educational resources which advocate the use of semantically null elements over decent markup, then please post them here so they can be educated!
P
For your information, Opera 8 won't load your brokenpixel site...
To have a right to do a thing is not at all the same as to be right in doing it
CSS gurus tend to assume that style, form and content can be separated.
.n2 .clickable and .whiteBG next to .internalLink. MySpace has #copyRight as well as .borDkGrey -- and so on.
In reality, they're all mixed up.
Think of a really good poem or film or advertisment -- where does content end and 'style' begin? Likewise for web pages.
Of course it's good to get rid of font tags and separate CSS from HTML, but it's daft to think you can completely split semantics from presentation.
Hence the problems people have naming CSS classes: from a quick look at Amazon's code, I found
Sometimes I wish we could just start again with something completely different: not HTML, not CSS.
Consider the following code, a slight modification to your attempt: You'll see that the left column extends all the way to the bottom but the middle and right columns are cut short. Now this isn't a knock against you, against CSS, or even against the famed "buggy implementation" of CSS in today's (and tomorrow's) browsers. It's a knock against the ridiculous bitchiness of CSS adherents who, for religious reasons, think that using a table for layout is the same thing as pureeing a panda cub into a beverage and enjoying it with a garnish of baby.
Just use a table!
I don't make the rules. I just make fun of them.
Simple and effective. The very definition of elegance. I'd friend you if I had more slots available, but it seems that I hate too many people. ;)
I don't make the rules. I just make fun of them.
My point is that many who use tables for layouts do not make sure they are accessible.
:)
You're absolutely correct. Over here, don't give a flying fig about accessibility. And the most we will suffer from this choice is some sanctimony on slashdot. I think I can handle that!
I don't make the rules. I just make fun of them.
To be clear, it's not all in the name of avoiding tables. Perhaps the best reason to avoid tables is accessibility. CSS is designed to degrade well. When you say what you mean in HTML, web browser can do intelligent things in a sub-optimal environment. Is the web browsing machine simply not powerful enough to handle complex layout (say, on a cell phone or a PDA)? Chuck the CSS and get Just the Facts. Is the internet connection painfully slow or charge by the byte? Turn off CSS and maybe image (an option my my Palm's browser) to speed things up and still get the essential information. Deaf and using a screen reader? A more straightforward layout makes things easier to say to the user; tables are reserved for tabular data for which a better interface can be provided ("This is table titled Budget. Columns are titled 2004, 2005, 2006, and Total. Rows are titled Staff, Hardware, Software, and Total.")
Search 2010 Gen Con events
Not sure what you have in mind about poems: most poems are pure content which can be marked up structurally and given almost any presentation. Some presentations will be prettier than others, and will also affect mood and so forth, but the fact remains that content, structure, and presentation have clear distinctions which can be easily drawn in such cases. In some cases, the poem's author may impose a particular presentation, but that's still a separately identifiable property of the poem.
When it comes to film or other really rich media then sure, the lines are not so sharp. But films aren't made with text markup! You can't cut and paste text from a film, you can't reformat it much for different browsers or display devices, etc. etc.
BTW, separating content from presentation doesn't mean that there's no connection between the two. Obviously, there's a connection, and that goes a long way towards explaining the naming issue you mention. However, the point is to allow things that can be separated, to be represented separately, to allow mixing and matching, and to help the computer in dealing with the material.
The biggest problem with the HTML/CSS world is that most of the people working with it don't have the necessary understanding to really do it right, so they rely on rules that someone else has handed down, which are then followed slavishly, often to the point of stupidity. Anyone capable of figuring this stuff out correctly themselves isn't going to stay in front-end web development for long, since there are greener pastures for someone like that.
In my many years of web development, I have found too few sources of mentor. Eric Meyer and Jeffery Zeldman have always been the few!
Presuming you can't also see the browser, you're probably as frustrated as Paris Hilton at a tent revival.
My company doesn't speak for me, nor do I speak for my company.