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."
Well, yes, I don't think many people but the most hardcore of standards purists could claim that IE isn't pretty good at following the rules. Thats not the issue.
The issue is that it's not very good when the code doesn't follow the rules. The problem here is that IE "guesses" what you're trying to do.
This in itself isn't a bad thing and from an end user perspective is a damn good idea. If I go visit a site that someone has made a basic error then at least I can still view the content, their mistake doesn't prevent me from getting what i want.
The problem comes when people start getting used to writing sloppy HTML because it works on IE (yes, I made that mistake before I found the w3 validator and Opera) and when Microsoft products start producing sloppy HTML (Words and Powerpoint being two apparant examples, although I've not looked personally).
So yes, web-standards great idea. But there should be a standard on what to do with badly formed HTML too.
Avantslash - View Slashdot cleanly on your mobile phone.
Canadian Cynic, canadian politics is less boring than you
Your point is fine in theory, but you have to remember two things. Firstly, the vast majority of internet users don't even know that they can change their default font size (let alone how to do it). Secondly, the default font size on most browsers looks plain ugly.
Uh-huh. I'm not the slightest convinced. These are people who say "follow standards and everybody will be happy". Making tradeoffs to cater to the default font size on IE undercuts their message.
-Rob
Government workers and contractors, you have to (or already have) comply with Section 508 Accessability Guidelines (as stated in the article), which means that most of these pages need to be rewritten anyway, now's a good chance to knock out XHTML1.0 compliance while you're at it, and shoot for the Web Content Accessability Guidelines (WCAG) too ... so all those neat Powerpoint presentations that are autogenerated into HTML need to go!
...
Getting to level A is not hard at all, anyone hit AAA yet?, I'm finding XHTML1.1 and WCAG-AAA a little bit to unwieldy for everyday web use
As someone who has spent lots of time in the last 5 years trying to automate extraction of information from the web, I welcome wider use of RDF (I have used it for years on my site) and separation of content and layout.
While the web as we know it is all about supporting human readers, the Semantic Web is all about supporting software agents.
-Mark
That's the sacrifice we as web designers have to make. IE holds the lion's share of the browser market, and we can't expect MS to change the way it behaves in regards to web standards just to please you communist Moz users - it's an integrated part of their OS!!!
That's fine. I have my differences with this argument, but fine, whatever.
It is also, irrelevant. The original message is about an outfit promoting web standars. They are not promoting "code to IE". They are promoting standards. Given that, they should be coding to standards, not changing the way it behaves in regard to standards just to please you IE users.
We're not talking corporations or banks supporting customers here. We're talking a web standards advocacy group.
-Rob
The W3C designs recommendations. They are not a standards organization (such as ISO or ANSI).
Java is the blue pill
Choose the red pill
For example, IE tries to guess what to do with a remote resource based on the contents of the file, rather than following the Content-Type header. Not only is this insane, as the server should be telling the browser what kind of file it is serving, not vice versa, but it has caused serious problems when trying to actually make IE treat a file with a particular content type differently. Want IE to download the file rather than display it? Well, unless you want to create stupid workarounds which break other browsers, you may have a hard time with this.
What WaSP should be pushing, and what I feel is one of the important parts of a web standard, is that a browser's behavior is as predictable as possible. When the browser tries to guess everything itself, rather than doing what the code actually says, it causes situations such as the one above. Sure, let the browser correct simple errors, but today's browsers are too "sloppy" when it comes to sloppy code. They should be more strict and unforgiving. This would make things a lot easier for web designers, as the browser would show clearly when there are errors in the code.
I generally find that it is a lot easier to "design for" (bad way to do it, but still) browsers that allow less sloppy code. Opera is excellent to check your code with, as it is even more unforgiving than Mozilla. Although this can lead to more "broken sites" when browsing the web, I find it to be of tremendous help to keep my own pages written properly. Mozilla has strong standards support, and seems to sometimes handle pages better than both Opera and IE (since IE's implementation of various standards has serious flaws), but it allows too much garbage code.
Then again, we have to live in the real world, and with clueless Frontpage users out there, we should back WaSP and try to make both browsers and authoring tools behave better - for a more open and accessible web. Sadly, because of IE's sloppiness, we are currently trapped in web designer hell. And viewer hell if the browser isn't "MSIE compliant".
Clever signature text goes here.
well...
Slashdot relies on tables for layout which is a big sin for WaSP. Not only do table-based layouts violate the structural markup that is the basis of HTML (and XML derivatives) it causes problems in browsers designed for the sight impaired (and therefore violates Section 508).
Slashdot also uses deprecated tags such as (font) and (b) rather than use CSS to change text presentation. I also don't see any structural flow such as using (H)eader tags to enable things like search bots to more accurately determine page content and weighted analysis.
So no, I would suspect Slashdot wouldn't stand up to WaSP scrutiny.
I tried creating a web page that used the ISO HTML DOCTYPE declaration:
<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:1998//DTD HyperText Markup Language//EN">
The W3C validator page complained about it: Fatal Error: unrecognized {{DOCTYPE}}; unable to check documentIt seems standards are not so standard.
Java is the blue pill
Choose the red pill
On the contrary, this knowledge will merely make me whine and poke at Amaya too.
I work in a web agency, and have had real problems in the past with certain designers writing/editing pages that look fine in IE, but don't actually work in either browser (or, on occasion, display at all in Netscape). They then proclaim the page to be finished, never having checked it in Netscape (despite a contractual obligation to support it), leaving it for the rest of us to fix.
I would like to see a "debug mode" in all browsers, whereby any badly-formed HTML is clearly flagged as such. Then you could tell at a glance if there was a problem, and what it was.
Cheers,
Tim
It's official. Most of you are morons.
According to WaSP, modern browsers are a necessity. The problem is, WaSP doesn't have the power the impose such a mandate, and my grandma uses whatever browser came bundled with her machine (how did IE win the browser war?)
IMHO, standards are great, but only if they are, in fact, standards. Thus, everything I write for the web follows the LCD (lowest common denominator) philosophy. Heck, I don't need tricks to put something that looks good on the screen (I'll do the alpha blending during graphics production, not at runtime). I don't like rewriting everything for a new browser (neither do the WaSP gurus), and that is why I'll stick to plain ole' minimal tag set HTML.
HTML is not the problem for me; the problem in getting a site to work properly on any browser comes in when you try to use JavaScript. An standard object model for *JavaScript* is what I really need, and that is just not a reality yet.
Some have pointed out IE's tolerance for mistakes is a problem, and I couldn't agree more. As a development browser, IE is a big mistake, unless you don't care about users of other browsers at all. Thank goodness for Mozilla.
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.
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.