Slashdot Mirror
Return of the WaSP
No_Weak_Heart writes "After a brief hiatus, the Web Standards Project (WaSP) has returned. Here's the story at Wired about this grassroots coalition which works to promote the adoption of web standards by authors, tool makers and in browsers. In a related vein, the Boston Globe has a comfy chat with Tim Berners-Lee, the guiding force behind many of those standards."
The W3C is here to design standards. They are not here to help web developers create web pages with no compatability issues. That is what WaSP is for. So, yes there is a difference.
Canadian Cynic, canadian politics is less boring than you
Here's a good explaination of the font issue and why IE is the worst for individual font sizing.
---
eeww, I'll have a crab juice.
These "web standards" people, however, seem to be using a font size a step down from standard for the main text on their page. Why?
Probably because (according to their stylesheet) they intend the main text to be displayed using the ubiquitous Georgia font and Georgia has a high aspect value, making it look "too big" when the default font-size is used.
See the W3C CSS spec (scroll down a bit):
Arien
Anyone or anything that stands up to prevent the next BLINK tag from running rampant on the net deserves some respect...
Most standards-advocates (myself included) would love to use 'font-size: small', or percentages, or ems to size text relative to users font preferences.
The problem is, support for these relative values are still too broken in IE6 and Opera (Opera is better though) for us to use them. Much as we'd like to, we can't be truly accessibility and standards-driven when the most popular browser on the web gets is wrong.
Theres only really 2 options open just now - use px as the font unit, or don't size at all. Most developers/designers aren't quite Zen enough to not size the text at all, as the default text size in most browsers is fucking ugly.
<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HTML//EN"> works.
It's totally possible to create great looking tableless, liquid, three-column layout using CSS.
o script.htm
These sites have different tutorials for various column combinations and even backwards compatibility with Netscape 4.
http://www.glish.com/css
http://www.saila.com/usage/layouts
http://homepage.mac.com/realworldstyle
http://www.projectseven.com/whims/cssp_3box/3boxn
The beauty of not using tables is that you're seperating structure from presentation. Basically, around some content, you specify what it is (structure). In the case of Slashdot's side navigation, in the XHTML/HTML you'd might surround the content with a DIV tag and give it an id/class of "sidenavigation".
With tables, you're already forced to predetermine that you want to use it on the left column when you mark up the whole table in TD and TR tags.
So how's CSS better than tables? Well, once you've defined the structure in XHTML/HTML, you can use CSS to define the presentation to say, I want anything tagged as a "sidenavigation" to be a vertical box on the left side that's X pixels wide.
This presentation can be easily be altered by changing the CSS. You can tell CSS to move things to the right, maybe center it or whatever. And you can define a CSS specifically for handhelds. You can tell it to hide data, change font sizes, redefine colors, or anything you want. For the sight-impared, you could define the CSS to display it all in a simple, column-less layout. And since you have not predetermined the presentation in the HTML, the user could have defined their own stylesheets to override your CSS to present the content in the way they want it.
With HTML and CSS (and also the XML and XSLT recommendations), websites can be so much more flexible.
Here's an excellent tutorial on how to get some common layouts without using tables for layouts. It's a little tricky at first but entirely possible. I've built my last three sites using no tables.
"Luck is the residue of design" --Branch Rickey
With proper HTML and CSS use, the abstraction at the presentation level doesn't actually break the structure. It merely seperates presentation from structure, while keeping structure together with the content/data.
Scott Andrew said it best here:
"...this illustrates a common misunderstanding about CSS. CSS is for separating structure, not content, from the presentation. Markup is meant to give meaningful structure to content. The content can come from a database or text files; the structure from page templates, a CMS or XSL transformation. Keeping your content free of meaningless structural elements allows you to pour your content into another structure suitable for different devices. CSS allows you to apply client-appropriate and easily-varied visual style to that structured output, without having to alter your markup."
Why should there be "abstraction" at the presentation level? It might help the content creator, but it doesn't do much for the reading end.
Tables are meant for tabular data - no-one is saying not to use tables for tabular data. What they are saying is not to use tables for _layout_.
Given a table - how do you tell whether its for layout or tabular data? I doubt you could always get it right.
adding a layer of abstraction doesn't help when extracting the meaning of the content
The meaning of the content is in its document strucutre, not in whether its left or right aligned. Presentation just makes content look presentable, not add meaning to it.
a h1 element will tell you more about some text than a font-size.
Decoding programs have to expand out all the style sheet stuff
No they don't. Presentation doesn't add anything to the content. How a heading is displayed gives no more significant information than knowing a piece of text is a heading.
The only time your statement could ever be slightly accurate is if people insist on using tag-soup instead of logical HTML markup.
Yes, you can make something _look_ like a heading by sticking it in a paragraph and alter the attributes of that paragraph to _look_ like a heading. There's no point in doing so, since the structure of the elements doesn't describe the structure of the content adequately -- that's tag soup.
Abstraction breaks all that geometric structure
Disagree. Abstracting the presentation (those bits that don't add value to the content structure but only describe style attributes) will clarify the geometry of a document right down to a clean hierachial list of nodes that are easily traversed.
Parsing an XML file is much easier than a random tag soup. And it can be done with standard freely available tools.
Speaking as someone who decodes elaborate HTML material with programs
These programs will be common accessories to the normal web user (transparent to them of course), precisely because of the direction WaSP and others want to go.
The Semantic Web is just an extension of the WWW.