161 In reply to Chris Hester

“This already happens. If the page contains the right doctype it will be shown in standards mode. If it has no doctype, or a non-strict one, it gets shown in quirks mode.”

I know that. But using only the doctype to determine the rendering mode is unreliable, because there is no guarantee that it correctly declares the version of the following HTML markup.

“If it was, that would mean a huge delay when surfing, as each page would have to be checked first. Is that really what you want?”

Nope. You’re right — that would be a rubbish user experience.

Perhaps it could work in the same way as the Phishing filter – check a list of known sites for standards compliance and use strict or quirks mode depending on the result. There’s still be a delay while the check is carried out, but would be quicker than validating the page, and the result could be cached.

Intranets, extranets and web apps can be added to a whitelist/blacklist to skip this check and force whatever mode is required.

posted at 03:09 pm on January 24, 2008 by Derek Ahmedzai

162 Support the past by forgetting it.

All I can say is, give IE a fair chance to correct what they screwed up in the past. The IE6 legacy is huge and cannot be solved by a simple poof

The meta tag is not an ideal solution, but other solutions aren’t ideal either. The meta tag is quite solid in it’s current proposal, and allows us to have more control over the rendering of our documents. While it does complicates things a little, it gives us more control too.

I’ve written a longer follow-up to the article but the bottom line is simple. This is IEs solution to a path where they can actively care about web standards. I believe they’ve earned that chance with IE7 and the announcement of IE8 (and it passing the Acid2 test).

posted at 03:18 pm on January 24, 2008 by Niels Matthijs

163 Untitled

You then want to make sure developers use those specs? have browsers block ALL rendering if the DOCTYPE is missing or invalid.

That’s not as good of an idea as you think it is. Here’s why: What happens when a new, valid DOCTYPE comes out? Now no document of that type can be rendered…at all…in current browsers, making it unusable for years.

posted at 05:21 pm on January 24, 2008 by Luke Sneeringer

164 Don't go there

It seems a lot of you weren’t there (or have already forgotten) but this kind of idea is just a (very bad) patch-style fix.

Yes, a lot of IE6-only websites are broken in IE7. But it’s not OUR fault. The W3C standards were there, the IE6 team didn’t follow them. It’s YOUR fault for making your website up to Microsoft flawed understanding of the W3C specs.

The doctype IS THE BEST WAY to ensure rendering: it’s already used by the browsers, nothing new needs to be put in place.

As for the IE5, IE6 and IE7 websites, there’s still a hope: the Microsoft conditional comments. They’re regular comments to all other browsers, our files are still XHTML-compliant and they even allow us to target specific versions of IE, from inline XHTML to including external files.

The C in CSS allows us to make standards-compliant websites and to over-ride these good values with whatever values the different IE versions are expecting (taking the box model as an example).

We’re not going to help those who made a mess with their IE6 websites, get over it. You made our own mess, now clean it up. Microsoft has put the tools you need inside IE since at least version 5, use them.

posted at 07:21 pm on January 24, 2008 by Yvan Rivard

165 Reality check

While at a certain point I agree with the comment above, it’s simply not a realistic view.

It’s easy to point fingers and say “you did wrong!”. It’s easy to tell them “fix it!”. But for the most part, the people you’re pointing at don’t really care (and I’m not talking about the IE team here).

Most people that made broken sites don’t realize it or don’t care enough. Everyone can build websites and that’s basically a good thing. Sadly, in combination with IE6 this brought us many problems.

We as web loving web developers should fix those problems, as good as possible. And we don’t do that by pointing to people who don’t really care that we’re pointing at them anyways. Maybe they’re not even there anymore.

Apparently, some of us rather shift the responsability to the people that know the least about good web practises. That in itself is bad practise, making you part of the problem we’re facing today.

Let’s face reality and work with that. It’s nice to have ideals, but let’s not hop mindlessly behind those ideals without considering the real world out there. It will bring us nowhere.

posted at 07:44 pm on January 24, 2008 by Niels Matthijs

166 Just Say NO to MS + CHEAP SITE OWNERS + LAZY DEVEL

“Most people that made broken sites don’t realize it or don’t care enough.”

So, if they don’t care, let ‘em burn.

“We as web loving web developers should fix those problems, as good as possible.”

No. Those who care about the broken site should fix the problem. I have my own clients to worry about, as do other web-loving developers. I do not have time to do the work because people like you, or people who have sites that broke and don’t care to fix them, say so. That, and I don’t care that their sites broke. That is not my problem.

posted at 08:07 pm on January 24, 2008 by Ray McCord

167 Serious Solution

Future versions of IE should ship with an animation that floats over the menu/tab bar area. It would be a big red boot that says “Kick Me”.

When the user encounters a website that doesn’t render properly, she just clicks the ‘kick me’ button. The animation then floats to the outer edge of the window frame and ‘kicks’ the window, which shakes like an earthquake and re-renders the page in another mode.

Users are already familar with the idea of banging on something that doesn’t work. Of course browsers that work don’t get the boot.

posted at 09:05 pm on January 24, 2008 by Thom McCann

168 Don't swallow this pill.

So, you’re thinking, what is the worst that could happen if they do this?

A Glimpse of the Near Future

THIS IS AN ATTEMPT TO UNDERMINE OUR STANDARDS AND SILENCE OUR DISSENT ONCE AND FOR ALL. DO NOT LET THIS PROPOSAL GO UNCHALLENGED. DO NOT ACCEPT THIS BLEAK FUTURE FOR OUR WEB.

Our feedback was not solicited. The community was not consulted. We were not involved. This was done covertly with the participation of self-proclaimed gurus and individuals NOT REPRESENTING the web development community at large NOR the official position of the Web Standards Project (WaSP). WaSP has made public this FACT:

1. WaSP Statement and Discussion

1. Disclaim of Responsibility by Andy Clarke – Co-lead of WaSP

DO YOUR PART TO PROTECT THE OPEN WEB. BOYCOTT THIS ATTACK ON CHOICE, INTEROPERABILITY, AND STANDARDS.

Thank you for your generous devotion of your valuable time.

posted at 09:20 pm on January 24, 2008 by Ray McCord

169 Untitled

@Ray McCord
You forgot to use super- and subscript (glad Textile doesn’t provide an alternative for <blink>)

But thanks for the links anyway.

posted at 09:49 pm on January 24, 2008 by Sander Aarts

170 <BLINK>;)</BLINK>

@Sander Aarts:

Nah. No blinks or extraneous cruft for me ‒ in general, anyway. Heh.

The fact is, it is simply more important that the post gets noticed and its point driven home than the feeling of Zen I get that comes from having dutifully pondered whether to use bold or strong, emphasis or italic, directly uppercased inline text or text-transform:uppercase.

Fighting with Textile would just kill the buzz anyway. :)

Try hyphenating words where the first word of the compound ends in “s”. It renders without the “s” and everything from the hyphen on to the next hyphen or rendered punctuation character is struck out. Not having a means to escape special characters without rendering side-effects is a definite disadvantage to using Textile.

Regards

posted at 10:47 pm on January 24, 2008 by Ray McCord