Slashdot Mirror

The "standards accepted by the Web-authoring communities" today are pretty much "Code everything for IE6. If there's free time after that's done and the pub isn't open yet, test in Firefox"...

That's not true. Common good practice is "code a solid base for standards compliant browsers and add unobtrusive IE fixes later". I've been working like that for the past 4 years and I can't recall meeting any other web designers that do otherwise. Maybe I am just lucky to work in a web agency that cares, though my general impression is that this has (finally) become a standard, and some of our clients (especially the large corporations) have started to request that full Firefox compatibility be part of the project plan -- just 2-3 years ago we had to convince them of the necessity.

That said, yes, Microsoft needs to clean up its act concerning W3C standards. IE7 was a step in that direction (as it also helped phase out quite a bit of old quirky IE5.5 installations), but far from done (hasLayout problems still persist). According to Bill Gates "there will be disclosure by MIX08" concerning IE8.

Before I go further, I use CSS everyday I design, especially since I'm still learning all of it's annoying idiosyncrasies, mainly because (and I'm not the only one) the CSS language itself is flawed (constraints & variables being some of which CSS lacks). The idea of what CSS created for, style sheets, is great & is a step forward, but the way we have to use style sheets with CSS sometimes makes me wonder what an abortion feels like.

I admit, some days it seems to get *easier* to deal with since I actively remember the times I more or less lost my shit because the stupid code wouldn't render correctly in different browsers, so I also remember (most of the time) what to avoid, but I really don't think the full potential of style sheets will be fufilled with CSS as the way it is. Even with CSS 3 (I'm not touching HTML5; I'm one of those "wacky" people who think we should stick with what we have until it's stable enough to warrant additions; a more eloquent way of putting it has already been said: http://www.molly.com/2007/06/14/defy-the-pedantic-semantic-html5-and-xhtml-11-must-stop-for-now/ ), I just don't see the difficulties of CSS, which warrant most of the CSS books being made, being resolved anytime soon.

I know I'm not the only one who begrudgingly uses CSS (I realize they are other technologies to use instead or to supplement CSS' shortcomings, I'm currently looking into that...), and I know I'm not the only who thinks something new should be made to address what CSS fails to do. I'm not talking about HTML5, nor CSS3, and defintley not FLASH (although, personally, I think if HTML & CSS were to somehow utilize a plug-in for browsers to render shit properly, standards would be able to compete with FLASH, but I'm just rambling there).

While googling out of frustration, I came across this:

PSL (Proteus Style Sheets): http://www.cs.uwm.edu/~multimedia/papers/jucs/jucs.html

Why Current Style Sheet Standards Have Failed to Improve Document Engineering: http://www.cs.uwm.edu/~multimedia/WWW8/webEng.html

I know every single Pure-CSS zealot is going to moan & groan at me for thinking differently than them, but honestly, PSL seems like a way better idea than simply adding on to an inheritantly broken style sheet language in which books & books need to be made to tell people what hoops to jump through to get it work. I don't know, I guess that sounds stupid to too many people; often I've let that prevent me from expressing my not unreasonable doubts.

Sometimes I feel like some poor bloke who time traveled back to the Titanic but can't prevent anything due to paradox. :\

The posting from Paul Thurott was not last week. It was a year ago. This article is a dupe.. http://it.slashdot.org/article.pl?sid=05/08/02/185 3256

I'd bet that Paul has a better understanding of IE7 now. Not that IE7 is at 100% CSS 2.1, but with CSS folks such as Molly Holzschlag (http://www.molly.com/2006/03/01/microsoft-ie7-pro gress-sneak-preview-of-mix06-release/) and Malarkey http://www.stuffandnonsense.co.uk/archives/mix06_v iva_las_vegas.html backing it, maybe that piece is a bit out of date?

I'm not so sure the .mobi TLD had much of a chance to begin with, but this will certainly kill adoption. Mobile design is still in its infancy, and there's nothing close to a reasonable and unified standard for mobile page design. There's no real agreement on how content will display on a given device.

Ultimately, compliance with standards should be on a user agent level. If your device can't parse the code that a certain site is sending, it can either fall back to a "quirks mode" rendering scheme (as standard browsers do) or refuse to display the data at all. If you don't follow the standard, too bad, you get left out of the market.

By making .mobi domains contingent on certain standards, it will only insure that fewer people are going to be willing to create .mobi domains. What if the standard changes with the next generation of mobile devices? Who decides what the standard is? What if adopting the "standard" means leaving a significant fraction of users out in the cold? Why bother with a .mobi TLD when you can simply use device detection to provide the user agent with a proper version of the file. If you're already doing the right thing and developing sites with separate content and presentation layers, that should be a piece of cake.

With all the hassles inherent under those rules, why would anyone bother with a .mobi domain?

From Dave Shea: IE7 CSS Updates
From Joe Clark IE7 The saga begins
And finally Molly Holzschlag, speaking on behalf of WaSP: That's why it's called beta

Molly is an amazing writer, and she really knows web design. When I got busy and couldn't update my book "Special Edition: Using HTML 4", Molly took it over and reworked it from the ground up into a much better book. And she's not only a great web designer and writer, she's a fantastic human being. Check out her site at http://www.molly.com/

The Acid2 test is not about squashing browser bugs

Huh? From WaSP:

Acid2 is a test page, written to help browser vendors ensure proper support for web standards in their products. [...] Of course, if you uncover a bug in your browser, report the bug!

From the Acid2 Guided tour:

It has been written to help browser vendors make sure their products correctly support features that web designers would like to use. These features are part of existing standards but haven't been interoperably supported by major browsers. Acid2 tries to change this by challenging browsers to render Acid2 correctly before shipping.

From Molly E. Holzschlag:

It's important to keep in mind that the point of acid2 is precisely to show browser and tools developers what's lacking in their products.

Unless you don't consider fucking up stylesheets to be buggy behaviour, you are wrong.

So far, most browsers claim almost full compability with CSS1 and CSS2.

I've never seen a browser developer claim CSS 2 compliance. The whole reason CSS 2.1 was published was that browser developers weren't implementing all of it, so the W3C took out the more difficult bits and added some previously proprietary code. And only one browser developer has claimed CSS 2.1 compliance as far as I've seen (a KHTML developer mentioned it in a CVS commit log).

Acid2 is meant as a way to speed the adoption towards CSS3

Acid2 doesn't use any CSS 3.

just as the orginal Acid-test was supposed to speed the adoption of CSS2

The original Acid test didn't use any CSS 2.

Are you trying to imply that the thousands of XHTML Strict websites out there produced by web/graphic designers, web developers, bloggers, and those who are supporting the standards are doing something wrong?

Yup. Check out Ian Hickson's "Sending XHTML as text/html Considered Harmful" for a quick primer on what most sites that do XHTML are doing wrong. Check out Evan Goer's list of "X-Philes" for a list of the very few sites which get it right, and his purge of sites from that list for an indication of how easy it is to go wrong even after you've initially gotten it right.

As for HTML generally not producing good markup and being "too loose", I hate to break it to you but XHTML 1.0 and HTML 4.01 are element-for-element identical; the only difference between the two is that one is an SGML application and one is an XML application. And when you serve XHTML 1.0 as "text/html" (e.g., when you do XHTML the way ESPN and others do) you don't gain any of the strictness benefits of XML. And the only thing XHTML 1.1 does on top of that is deprecate a couple more things and add modularization and ruby support, so I'm really not sure where all the "good markup" would come from in a transition to XHTML. Plus there's no reason to believe that serving XHTML 1.1 as "text/html" is conformant, so if you use 1.1 you either break the spec or you shut out IE. Likewise, switching to an XHTML DOCTYPE and using XML syntax doesn't magically confer accessibility on a page; it's just as easy to write a horrid, bloated, table-based images-for-everything page in XHTML as it is in HTML 4.01.

I suspect that you're making a common mistake among people who've just discovered web standards: you're confusing XHTML with good markup and best practices (check out Molly Holzschlag on what standards are and aren't). Anyway, it's quite possible to write beautiful, clean, accessible, semantically rich HTML 4.01 with separation of content from presentation; after all, it's got the same set of tags and attributes as XHTML 1.0, so if you can do it in one you can do it in the other just as easily. And when you consider that serving valid, well-formed XHTML according to the spec can be a nightmare at times, it's no surprise that even "gurus" of the standards world (e.g., Mark Pilgrim, Anne van Kesteren) have gone back to or recommended sticking with HTML 4.01 unless you really need one of the features gained by an XML-based HTML.

And lest you continue to think I'm some sort of skeptic or enemey of web standards, well, every site I've built in the past three years (basically, since I discovered there was such a thing as a "web standard") has been valid, accessible, and CSS-based. I just know from experience that valid markup and stylesheets are one part of the equation, and there are an awful lot of those "best practices" that aren't ever published in a spec from the W3C or anyone else.

As much as I would Microsoft to up and go away, well, these ads are not going to kill IE. IE is just too easy to get, runs all the stuff people want, and it comes on their Windows boxes.

However, sites that use these features are likely to lose users. Yeah, they'll keep their techy users who use Mozilla, etc., but their joe-average users will disappear. (Why should I read Boston.com when I can read CNN.com and get none of those crappy ads?)

Case in point is that I almost never visit C|Net or ZDNet anymore. The ads are lousy. The content doesn't justify the annoyance. I use to read Builder.com all the time. Now I just visit Molly.com and see where her latest articles are.

Reality is that advertising is only tolerated as long as it's justified. I click on the ads on Slashdot because they're well targetted. I read BBC News because there are no ads. I used to watch Sci-Fi because there were fewer ads. If it really comes down to it, eventually I'll only visit government sites and my paid subscriptions because like many a business user, I don't have time to wait the 5 seconds on a page while checking to see if an article is worth reading.

Before you start, determine your purpose and your audience: what do you want to communicate, and with whom?

Some suggestions:

• First, meet with management to determine what they want to communicate, and with whom they believe they will be communicating. (if they don't want to meet with you, run like hell and find a different project).
• Next, meet with a group of customers. You don't mention whether you're designing for a local government agency, something statewide, something federal, a UN agency, a provincial government not in the US, or whatever; but your customer is the person who either receives services from your agency or is required to pay your agency directly, whether your agency renders services or not. Meet one-on-one and with small groups of your customers to discover what they expect from your agency, and by extension, your agency's website. Take lots of notes.
• Evaluate how managements' and customers' views differ and complement one another. Write a project scope that accounts for these, including detailed explanations for features and design elements that management has not requested. be sure to include reasonable estimates of the time and cost involved in developing the project within the scope you have envisioned.
• Receive written management approval for your project scope and budget before proceeding.

Don't start coding yet:

• Draw a document hierarchy for your site. This can be done with pencil and paper, with Visio, whatever. But establish the relationships among the areas of the website before you make coding decisions.
• Sketch or mockup with a graphics tool the general look of your home page, index pages, content pages, form pages, etc.
• Receive written management approval for your hierarchy and visual design before proceeding.

Now it's time to choose your platform.

• Choose your platform wisely. Whether the site's going to be built from static HTML, upon an open source platform like Linux, Apache, PHP and MySQL, with a commercial product like NT, IIS, ASP, and SQL7, or in some combination, be sure your choice will meet the established scope and objectives -- and stay within budget.
• Don't choose a product because "that's what Department CYA is using." Every project is different.

Think you're ready to write some code? Not yet:

• Read Designing Web Usability by Jakob Nielsen. Feel free to disagree with some of his conclusions.
• Read Web by Design: The Complete Guide by Molly Holzschlag. Feel free to disagree with some of her conclusions.

Okay. Now you can write code:

• Write vendor-neutral, standards-compliant HTML.
• Separate presentation from content.
• Follow the rules you've learned from Molly and Jakob.

Good Luck!