|
JUN
12
2006
|
Strict Is Just Another Quirky ModeSome might have seen the summary before, because I posted this blog last week, but pulled it again because I wanted to double check that my recommendation is sane in MSIE. Turns out my assumption was right so here it is again: Let me start with a rant. I see more and more websites using strict DOCTYPES, apparently webdevelopers have some misguided notion that this is most correct thing to do and guaranties the most consistent result. Nothing could be more wrong! Let us examine the theory. Strict more is a mode for the browser to implement correct standard behavior. The browser will implement 'transitional' and 'quirks' mode to handle every broken site it gets delivered and provide 'strict' mode as a tool for webdevelopers to check if their design works when interpreted as strict as the browser is capable of. This means in theory that when strictness bugs are detected in the browser implementation, they are always fixed in strict mode, but only fixed in transitional and quirks if no important websites depend on the bug. This means for a website that uses strict DOCTYPE that the website can be rendered differently for each new browser version and suddenly end up looking broken, because it actually relied on a bug. For this simple reason, websites should never be published with strict DOCTYPE. Strict doctype is only a development tool. Now for the facts: There are many websites everywhere that uses strict doctypes. Even nerdy technical minded ones like slashdot makes this stupid mistake. This of course means that browsers cannot fix bugs in strict mode without breaking websites (and breaking websites is the last thing a browser developer want), and with so many important websites relying on bugs in strict mode, strict becomes more and more quirky. For Konqueror this basically means: The next thing that comes up when I tell people this is: "But, this is all fixed with XHTML right?"... Nope, XHTML is much much worse! Since XHTML doesn't really work in MSIE when served correctly 99% of all XHTML sites out there doesn't follow the XHTML standard in even the most basic ways (delivered with text/xhtml+xml and starts with <?xml> tag). As a result all the browsers treat sites with XHTML doctype in either a special XML-quirky transitional mode or simply as HTML4 transitional, and thus bugs are not detected and thus websites depend on being treated quirky. So... What's to make of this: I don't really know. Except that the idea of making new strict types doesn't really work in practice, and just results in more and more weird modes in the browsers; all with their own set of quirks. The only clear lesson is for web developers: Just use HTML4 transitional.
|
 |
Comments
wait a minute
I agree that the assumption that strict DOCTYPE "guaranties the most consistent result" is wrong. But what are you talking about when you say "it actually relied on a bug"?
First, notice that "Strict DOCTYPE" and "strict mode" are different things. The former is defined by W3C, and its companions/rivals are Transitional and Frameset DOCTYPES. The latter is a render mode in major modern browsers, and it's usually triggered with any of the above DOCTYPE (since having a DOCTYPE means a page is developed post-standard), and its counterpart, quirks mode, renders things like older browsers, and is triggered by the lack of a DOCTYPE, or an incomplete one.
DOCTYPEs declare the "document type". Looking at the DTDs they refer to, each DOCTYPE just specifies the valid tags, their attributes, and places where they can be used. The Transisional DOCTYPE allows using some deprecated elements and attributes (deprecated usually because replaced by CSS), which Strict doesn't allow; the Frameset allows using frames in addition to Transitional. The DOCTYPEs really just defines the (X)HTML "syntax", not how browsers should render pages. This means that the right time to use Strict is if the (X)HTML is Strict, i.e. not using "deprecated elements and attributes".
Granted, browsers could render things differently across the DOCTYPES. Your post says Konqueror implements Mozilla bugs for Strict DOCTYPE (but presumably not in Transitional). Even if this is true, and Mozilla's those behaviors are "buggy" (non-conforming), it doesn't mean that Konqueror is doing the right thing, nor that all browsers, especially conforming browsers will do the same. If an actually Strict document is rendered improperly due to this reason, the one who relied on bugs in this case is Konqueror or another non-conforming browser, not the web designer.
Konqueror vs the world?
While I was surprised at first about the title, I've come to understand that "strict" isn't really "strict" speaking from the point-of-view of the browser-developers. Strict mode is only really strict mode if your HTML/CSS validated correctly, otherwise it's indeed becoming yet-another quirks-mode.
XHTML is ment as "browsers should not add tags", "should reject invalid code" and "should not correct coding mistakes". The sad part is , they actually don't/can't do this. While you can strive to reject all non-confirming XHTML, but you'll actually lose market share that way.
The way I see it, "strict mode" is a lot better then "quirks mode", simply because you force browsers to behave the same, and avoid a lot of intentional bugs (see http://developer.mozilla.org/en/docs/Mozilla_Quirks_Mode_Behavior for a nice list). But even for strict mode, browser-developers still need to implement all error recovery features because webdevelopers depended upon them unknowingly.
they actually don't/can't do thi
Gecko doesn not display a website served as XHTML if it countains errors. So, yes it is possible and it is done.
Konqueror should do the same as writen in the w3c norms.
Browsers developpers lose a lot of time trying to fix bugs that are not bugs beacause HTML norms didn't countains way of handling bad code. So every browser invented a way to solve bugs : closing tags, ignoring tags, uting news tags in the code. After that the website does not look like the same on all the browsers. Normal because error handling is not discribed anywhere and if you want to do so, you can write a encyclopedia because error handling of HTML is an horror.
You have too much faith Gecko
Gecko doesn't display XHTML if it contains XML errors. If the page contains DTD errors, which they don't check, then it is displayed and the web-developer assumes his page is correct.
And even if page is encoded 100% correct, it might still depend on rendering bugs in the browser, again something that might be fixed later.
back to the topic?
Notice that these issues have nothing to do with (X)HTML Strict DOCTYPE. Strict simplify defines a "stricter" markup language, not stricter processing or rendering, and browsers are no more or less obligated to be tolerant about markup errors, or even implement bugs, for Transitional than Strict.
Since CSS came out, it's always (or more and more, at least) been the smart thing to do to avoid presentational markup. And Strict DOCTYPE is exactly what enforces developers to follow that tenet, and allow validators to check it. Therefore, there's no reason to use Strict only for development, but not for release.
One reason I can think of for using Transitional instead, when you actually can write Strict pages, is when you insert things like web counters, Google ads, which use presentational markup, frames, etc.
Not the whole picture
You have a very limited view of what the STRICT doctype does. Try comparing loose.dtd to strict.dtd.
Besides disallowing most of the presentational styles (not all of them). It also disallows several objects such as EMBED, APPLET, IFRAME, etc. What is worse is that it redefines what objects can contain. For instance in Transitional a BODY element can contain any %flow element (most elements), but in Strict it can only contain %block|SCRIPT|DEL|INS. This means that the following code:
Here is a link
Render as expected in Transitional, but should be a blank page in strict. Guess how many strict DOCTYPE pages that rely on inline content under BODY? (Answer: most of them).
Not the point
"Guess how many strict DOCTYPE pages that rely on inline content under BODY? (Answer: most of them)."
And any good validator will point out that they are in fact not Strict HTML 4.0. My point is people who read the specs and aim to create Strict pages should declare them as so, and validate, (and people who don't read the specs probably can't write correct Transitional, Frameset 4.0 either).
Since HTML 4.0 is SGML but not XML, it may have looser requirements. I'm not sure if the specs allow browsers to patch things up for pages that don't conform to the DTD, but they probably should given today's situation. However, it's very easy to use validators to check for errors, and the features provided by HTML Strict is enough for most purposes. Therefore, people should choose Strict whenever possible, for separation of content from presentation, and often better semantics. Therefore, please admit your mistake and stop saying that Transitional should be preferred over Strict.
(X)HTML Strict and Quirk Mode
(X)HTML Strict means (X)HTML without presentation or style elements in the code so no "font" tags, no "height", "color", "border"... attributes in the tags. All will be in the stylesheets.
So (X)HTML is very very good and very important because it is more accessible, more customisable by the user using user stylesheets,...
I am sorry to tell you that but you don't understand anything :)
And I hope what you say is wrong : "in strict mode we implement Mozilla bugs". Reporting bugs to Mozilla and following the W3C norms is much better than keeping bugs. Moreover Mozilla can changed and be corrected quickly. So I can understand that in quirk mode IE bugs are emulated but please don't do this with Mozilla.
Of course browsers can fix
Of course browsers can fix bugs in strict mode. If a page breaks because it depended on a bug, that's the fault of the page's author. Why should browser standard support lag because of bad page authors?
As for XHTML, it is treated properly in Mozilla and Opera. If KHTML acts as if XHTML is quirky HTML, that's the fault of KHTML.
Not quite
No XHTML is only treated correctly in Mozilla and Opera if served 100% correctly, and it is usually not served correctly, because that doesn't work in MSIE.
Pages