homepage Welcome to WebmasterWorld Guest from 54.204.128.190
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

This 33 message thread spans 2 pages: 33 ( [1] 2 > >     
Quirks Mode vs. Standards Mode - overview
tedster




msg:614948
 5:56 am on May 28, 2004 (gmt 0)

There's been some question (sometimes a lot of question) about what quirks mode is, and the parallel question, what standards mode is. For many web designers, these are still unknown words - so I hope we can clear some of this up and give a platform for further learning.

Up until version 6 browsers, there was a lot of non-standard rendering built into user agents. A lot of this behavior didn't conform to the W3C rendering recommendations at all, but it was what we worked with and we got very used to it.

And then came the move to standards, with Document Type Declarations (DTD) and all that. But how can new browsers handle those legacy pages all, over the web that depend on "quirky" behavior in order to look good?

That became the question, and the answer is "quirks" mode.

If a browser sees a full DTD as the FIRST element of a document, including the W3C URL for the details, then it renders the page in "standards" mode. Because standards are still relatively young, there is some variation from one browser to another, but it's usually minor.

But if a browser sees no DTD, or a partial DTD, then it goes into "quirks mode", which essentially means rendering the page the wrong way, but the way we were used to up until version 6.

What this all means in specific detail is way beyond the scope of one thread. But I thought it would be very useful to have this explanation and a set of references in one spot, to get people started out on the right foot if this is all new to them. More and more, you will see these two modes mentioned in threads.

REFERENCES

W3C Valid DTDs [w3.org]
Opera re: Quirks Mode [opera.com]
Mozilla re: Quirks Mode [mozilla.org]
Microsoft re: Quirks Mode [msdn.microsoft.com]
DTDs and FrontPage [msdn.microsoft.com]

 

DrDoc




msg:614949
 7:27 am on May 28, 2004 (gmt 0)

Excellent excellent topic!
Why didn't I think of this first? ;)

This is a topic that comes up frequently in the CSS forum [webmasterworld.com]. Understanding (and, usually, avoiding quirks mode) is one of the keys to successfully producing cross-browser compatible web content. While there is much more to it than what first catches the eye ( >> What this all means in specific detail is way beyond the scope of one thread.) it is really important, if not crucial, to have at least a basic understanding for what quirks vs. standards mode means.

Also, I would like to add a reference to the list... Even though this page is linked to from the MS quirks mode page I feel it deserves its own link. Since Internet Explorer is the most commonly used browser today (and, unfortunately, the least standards compliant) it makes the task of web development much easier when one understand the limitations of IE, but also its strengths. MS made some significant changes [msdn.microsoft.com] to the IE6 rendering engine, resulting in a definite separation of quirks vs. standards-compliant mode.

tedster




msg:614950
 2:20 am on May 29, 2004 (gmt 0)

Here's one of the very common issues that keeps coming up - so I think it's worthy of a special mention here.

Say you've got some images held together nice and tight in a group of table cells. And in Explorer that's exactly what happens - the images interface with no gaps at all. Maybe now after some hard work your mark-up has validated to some nice DTD - maybe XHTML strict.

But when you view your page in a recent browser (especially Mozilla, Netscape) you find a fat extra space, commonly below the image.

The issue is that until recent browser versions, every user agent got the rendering of inline images wrong (and images are inline by default) -- and we all got our mark-up wrong as a result.

Inline images in a table cell are "supposed to" be aligned with the BASELINE of the text, or where that baseline would be even if there is no text. Non-standard browsers traditionally have aligned the images with the cell's bottom, not the text baseline.

So standards mode is throwing in extra space between the image (which ends at the text baseline) and the table cell's bottom. Or maybe even adding in more space around the image, because of other padding and margin rules that are inherited from the container's parent elements.

You can fix this nasty little surprise with CSS, by setting a style rule for any <td> that contains images and switching the display of the img element from inline to block.

Try this:

td.imgholder img {
display:block;
margin:0;
padding:0;
}

It's all about standards mode vs. quirks mode!

DrDoc




msg:614951
 2:43 am on May 29, 2004 (gmt 0)

An alternative solution to the above mentioned problem is to simply tell the image not to align with the baseline:

td img {
vertical-align: bottom;
}

photon




msg:614952
 11:25 pm on May 29, 2004 (gmt 0)

Thanks tedster. This is a much needed thread. I'm sure it will be referenced quite frequently in this forum.

And I too wish I had thought of it!

DrDoc




msg:614953
 5:03 am on May 30, 2004 (gmt 0)

Images, tables, and mysterious gaps:

One of the best articles ever, describing this very problem, can be found on Netscape's DevEdge [devedge.netscape.com] website.

4serendipity




msg:614954
 8:30 am on May 30, 2004 (gmt 0)

Up until version 6 browsers, there was a lot of non-standard rendering built into user agents.

To be strictly accurate, the first browser that employed doctype switching was a version 5 browser, IE 5 Mac.

An old O'reilly article detailing the then new feature can be read at:
[oreillynet.com...]

markd




msg:614955
 12:34 pm on May 30, 2004 (gmt 0)

Can't wait for Yahoo to realise this, and incorporate it into their Editorial Judgement criteria for entry into Site Match :)) LOL

Multiverse




msg:614956
 7:47 pm on May 30, 2004 (gmt 0)

Up until version 6 browsers, there was a lot of non-standard rendering built into user agents

Damn, im using Firefox 0.8 and thought that was up to date!

WebDon




msg:614957
 10:01 pm on May 30, 2004 (gmt 0)

Multiverse: I think Mozilla Firefox 0.8 qualifies as a newer browser. When they talk about pre-version 6 browsers they're talking about the browsers that have been around a while like IE, Netscape, Opera, etc.

tedster




msg:614958
 11:42 pm on May 30, 2004 (gmt 0)

the first browser that employed doctype switching was a version 5 browser, IE 5 Mac

That could be a very useful tidbit for me -- thank you. I've got a new client with an old Mac who uses AOL 6 -- which I'm pretty sure was based on IE 5 Mac. It seems no matter what I do for him, it doesn't work right on his browser.

I'm going to assume there's something buggy in the doctype switching and change the design over to quirks mode (I've been going for standards mode and HTML 4.01 strict). I sure am not going to install AOL 6 and Mac OS 8 for testing, unless he buys me a dedicated computer.

gmiller




msg:614959
 1:06 am on May 31, 2004 (gmt 0)

Was IE5/Mac the first official release with quirks mode, or are you counting betas and such? Had quirks mode already made its way into Mozilla milestone releases prior to that?

In any case, one detail that was missed in this thread (but is discussed in the linked-to mozilla.org document) is that recent Mozillas have three modes, quirks mode, almost-standards mode, and standards mode. The number of doctypes that trigger full standards compliance in Mozilla has been significantly reduced.

DrDoc




msg:614960
 1:58 am on May 31, 2004 (gmt 0)

first official release with quirks mode

No, I think NN1/IE1 was the first browser with quirks mode ;)
Seriously, back then -- quirks mode was all you got.

Up until version 6 browsers, there was a lot of non-standard rendering built into user agents

Damn, im using Firefox 0.8 and thought that was up to date!

Let's rephrase that then -- "Up until generation 5 browsers".

tedster




msg:614961
 2:38 am on May 31, 2004 (gmt 0)

I've just been involved with some hands-on testing, something I heartily recommend. This whole area is a bit challenging to master in the abstract, and there's nothing like seeing it with your own eyes.

Take a web document, open it in both an editor and a browser, and play around with the DTD so you switch rendering modes. There's a world of detail to be uncovered. And I'm far from convinced that "quirks mode" means the same thing cross browser. My guess is that it doesn't.

In particular, I'm finding two areas to be yelling "WAKE UP" at me.

INLINE vs. BLOCK
Quirks mode seems to be very casual about observing the strict differences between inline elements and block elements. Example - I have an externally defined class that includes a width rule. When that class is applied to an inline element, the width rule is ignored in standards mode, as it should be.

But switch to quirks mode, and voila! the width rule is applied. Some nasty breaks in the layout are the result.

INHERITANCE
So one page has an unordered list <ul> and some list items <li> inside a unique div, with font rules declared for the id. In standards mode, these rules fall right down the cascade to the <li>. Switch to quirks and that stops happening.

SWITCH MODES WITH CAUTION
I'm learning that this quirks vs. standards thing is not a casual issue. In trying to revert to quirks mode, having designed in standards mode, I'm finding more than few shocks.

I'd imagine that it's more common to be upgrading TO standard mode rather than making a backwards move like I am in this case. Still, either way there's a good bit to learn when you get down into the details.

creative craig




msg:614962
 7:10 am on May 31, 2004 (gmt 0)

I have never fully understood quirks mode Vs standard mode. Thanks tedster this has really cleared up a lot of my questions.

RonPK




msg:614963
 9:48 am on May 31, 2004 (gmt 0)

In IE, one of the most important differences between 'standards compliant' and quirks mode lies in the calculation of the width of a box. An example:

div.mybox {
border: 5px solid red;
padding: 20px;
width: 200px;
}

According to the CSS1 specs, total width should be 250px, with 200px for the contents of the box. However IE in quirks mode puts border and padding inside the box, leaving only 150px for content.

Unfortunately there still are lots of folks out there who use IE 5 or 5.5. For them, you could put a set of quirky style rules within IE's conditional comments. This keeps the main style sheet clean, without any dirty hacks.

4serendipity




msg:614964
 2:56 pm on May 31, 2004 (gmt 0)

No, I think NN1/IE1 was the first browser with quirks mode ;)
Seriously, back then -- quirks mode was all you got.

Too funny

4serendipity




msg:614965
 3:16 pm on May 31, 2004 (gmt 0)

Was IE5/Mac the first official release with quirks mode, or are you counting betas and such? Had quirks mode already made its way into Mozilla milestone releases prior to that?

I believe that the first Mozilla milestone to implement Doctype switching was Milestone 14, which was completed on March 1, 2000. That was after IE 5 Mac by a little bit. However, before compatibility mode was tied into the Doctype, one could switch between modes via a menu item in older Mozilla builds.

An archived discussion of the development of Doctype switching in Mozilla can be read at:
[bugzilla.mozilla.org...]

4serendipity




msg:614966
 3:49 pm on May 31, 2004 (gmt 0)

That could be a very useful tidbit for me -- thank you. I've got a new client with an old Mac who uses AOL 6 -- which I'm pretty sure was based on IE 5 Mac. It seems no matter what I do for him, it doesn't work right on his browser.

from:
[webmaster.info.aol.com...]
Beginning with Windows AOL 3.0 (32-bit), the AOL client does not have a browser embedded, but instead uses the Internet Explorer browser the user already has installed within their system. Macintosh and Win16 versions of AOL do have an embedded version of Internet Explorer which is independent of the user's external browsers.

I couldn't find any definitive answer regarding which version of IE AOL 6 Mac uses, since the latest AOL Mac version listed on the page at <http://webmaster.info.aol.com/detection.html> is 5.0. However, I would think that AOL 6 Mac would be using IE 5.

MichaelBluejay




msg:614967
 10:09 pm on May 31, 2004 (gmt 0)

Beginning with Windows AOL 3.0 (32-bit), the AOL client does not have a browser embedded, but instead uses the Internet Explorer browser the user already has installed within their system. Macintosh and Win16 versions of AOL do have an embedded version of Internet Explorer which is independent of the user's external browsers.

If that's true then why do I have AOL v's 7, 8, and 9 showing up as user agents in my server log?

tedster




msg:614968
 10:30 pm on May 31, 2004 (gmt 0)

calculation of the width of a box

Essential! Thanks for bringing it up. That can be one of the nastiest layout issues if you need to support older user agents. I remember being extrmely confused for a long time on how to declare widths.

CritterNYC




msg:614969
 4:39 am on Jun 1, 2004 (gmt 0)

Beginning with Windows AOL 3.0 (32-bit), the AOL client does not have a browser embedded, but instead uses the Internet Explorer browser the user already has installed within their system. Macintosh and Win16 versions of AOL do have an embedded version of Internet Explorer which is independent of the user's external browsers.

If that's true then why do I have AOL v's 7, 8, and 9 showing up as user agents in my server log?

Because AOL uses IE as the renderer, but drops it's own UI around it. It also sends a customized user agent.

tedster




msg:614970
 5:43 am on Jun 1, 2004 (gmt 0)

Also when you install AOL, it will upgrade your version of IE if you are "in arrears" and if your system can handle it. This is one of the positive things I noted about AOL over the years. They've been very proactive about upgrading their membership to the next browser version.

Now if MS would only kick out a new version of IE with better standards support, that would help a whole lot. I look forward to the day - what, 5 or 6 years in the future? - when we ONLY have standards mode to concern ourselves with.

Right now, it's still a bunch of spaghetti in many situations. As I untangle my particular pile of spaghetti, I'm learning more about standards and quirks than I ever did from reading the formal W3C recommendations.

jpalmer




msg:614971
 1:47 am on Jun 2, 2004 (gmt 0)

Gidday folks

Don'cha just love AH HA! posts?

Thanks Tedster, great post, a while back I spent *ages* inserting/removing a DTD and validating, which resulted in some strange layout glitches, and couldn't get it to work "quite right" across a number of browsers despite good css and code valdiation.

Now I know why.

Cheers and hooroo
JP

yintercept




msg:614972
 10:49 pm on Jun 6, 2004 (gmt 0)

which essentially means rendering the page the wrong way, but the way we were used to up until version 6.

First, I realize that there is often value in standards.

However, I have an extreme distaste when people run around and try to label everything that does not fit in the tiny little restricted world view of the standard committee as "wrong."

Web designers whose pages do not validate DHMTL strict are neither writing "wrong" nor "bad" code.

The real definition of quirk mode is simply: quirk mode is the default DTD. It is the DTD used when a page does not specify a DTD, or when the HTML code in the document does not match the specified DTD. For example, you will go into quirk mode when you forget the closing slash on an image tag, or when you use an align=center attribute in the p tag of the paragraph you want to center.

The only "wrong" code that is written occurs when a person specifies a DTD and does not follow it. Designers who chose to do all their work in the default (quirk) mode are neither writing bad nor wrong HTML. For that matter, they really aren't writing "non-standard" HTML, as their HTML follows the rules of the de facto Netscape 4 standard.

Yes, I realize that commissars reject the existence of de facto standards. Commissars are likely to say that standards can't evolve. Standards have to be dictated by small minds. The W3C has many of the smallest minds in the industry.

For the most parts standard committees are just another playing field where megacorporations battle eachother for dominance. The company that can get the most of its design methodology scribed in the standard wins.

Standards can provide value, but they do so in a strange way. A standards committee stops evolution on one level. Often this lets us innovate on other levels. More often than not, standards simply stop the evolution of ideas.

The effects of standards committee are not always good. The industry should always be free to accept or reject non-critical standards.

My experience is that it is easy for a human to sit down and pound out quirk mode HTML in notepad. Quirk mode is much more organic. It is much more difficult for a human to write code in standards mode. Generally, the only way to get good DHTML strict code is to buy a compliant editor and validator from one of the megacorporations that had their hand in setting the standards.

Sorry about the terse reply, but people who use the default DTD are not wrong. They are not bad people. I prefer them to those who get anal about standards. The W3C calls the default DTD "quirk mode" because it has a nice little implied insult.

If the new standards really are not providing web designers anything of value, then the standards themselves need to evolve.

isitreal




msg:614973
 5:29 pm on Jun 8, 2004 (gmt 0)

For the most parts standard committees are just another playing field where megacorporations battle eachother for dominance. The company that can get the most of its design methodology scribed in the standard wins.

Very nicely put, first time I remember anyone trying to workout how this stuff really happens in these forums, usually it's painted more like a happy nevernever land type world where everything is being done by well meaning souls who only want the best for all of us. The picture you're drawing is far more accurate I think, but that's not going to stop anyone who believes that following standards actually has some instrinsic meaning or value outside of the scenario you outlined.

I'd add to this, many of the decisions made are made not so much as competition between organizations, but in order to establish a lingua franca, to smooth over the transfer of corporate data, things like XHTML 1 strict have virtually no use or meaning outside of that framework as far as I can see, it diminishes significantly what your webpage can do, so the advantage must come from something that has little or nothing to do with your or my webpages.

There is one genuine benefit that I've found for following standards, debugging html code. That's what I use it for, and that's a fairly valuable thing to have available, but it's the only actual advantage I can think of when it comes to following standards.

digitalv




msg:614974
 4:32 pm on Jun 9, 2004 (gmt 0)

yintercept, you should read a thread I started a month or two ago:

[webmasterworld.com...]

It's a long one and there were some pretty nasty responses to what I wrote, including many childish and insulting posts, but it's interesting to see the reaction from the WebmasterWorld community over the mere suggestion of W3C going away.

drbrain




msg:614975
 5:19 pm on Jun 9, 2004 (gmt 0)

yintercept wrote:

The real definition of quirk mode is simply: quirk mode is the default DTD. It is the DTD used when a page does not specify a DTD, or when the HTML code in the document does not match the specified DTD. For example, you will go into quirk mode when you forget the closing slash on an image tag, or when you use an align=center attribute in the p tag of the paragraph you want to center.

No. Quirks mode has nothing to do with the markup of a document. There is no "default DTD". Quirks mode is not triggered by invalid HTML for the DTD specified. (See [msdn.microsoft.com...] for how Standards and Quirks modes are triggered in IE6.)

You will be in standards mode when you specify a DTD with URL, and in some instances when you specify specific DTDs without URLs. When you place a !DOCTYPE on your document, you are saying, as the author, that any content follows the specifics of the !DOCTYPE specified.

Any bad content causing rendering errors is your fault including unclosed elements and invalid attributes.

By not specifying a !DOCTYPE, you are telling the browser to guess what you mean.

isitreal




msg:614976
 5:36 pm on Jun 9, 2004 (gmt 0)

No. Quirks mode has nothing to do with the markup of a document. There is no "default DTD".

That's pretty much correct, but only in a strictly technical sense.

The only difference standards mode makes is in some very slight changes in how stuff renders, and of course the box model in IE goes back to what it should have been if common sense had prevailed when the standards were redone (padding goes in the box, not outside of it, who ever heard of padding going outside a box, that's completely stupid, the box holds what's inside it, padding, borders, then margin is what separates it from other boxes, you'd think the idiots at the w3c had never seen a real box in their lives...).

but:
Standards have to be dictated by small minds. The W3C has many of the smallest minds in the industry.

Even though I don't like IE, it's obvious that MS was listening to the end user, designers, normal human beings, when they came up with this box model, I still can't figure out who the w3c was listening to, obviously not normal human beings. Yet another argument against spending too many years in front of monitors typing little letters to make little things of questionable value happen ...

Each browser has some display bugs that will be triggered by standards mode, that's another reason for real world apps not to use it, like IE 6's xhmtl/colspan bug, which vanishes with html 4 doctype, or the implied generic doctype <html>.

<html> can be considerd the default doctype, all browsers will treat it as such, the default supports all html tags, doesn not care about standards at all, covers <dir> to <iframes>, doesn't care if your code is basically xhtml, using <br /> or <br>, it's all treated as one by all browsers that are reasonably modern, that's the reason most large websites don't use a doctype. This despite completely completely ungrounded claims that coding in xhtml will somehow 'speed' your page rendering, the only way that could happen is if the rendering engine first parses the whole page, decides that it has no errors, then applies the xhtml rendering to it, which of course would increase the time.

py9jmas




msg:614977
 6:07 pm on Jun 9, 2004 (gmt 0)

using <br /> or <br>

<br /> means something completly different in HTML4.0 (SGML) than it does in XHTML (XML).

See [internal.qaotiq.co.uk...]
The fact that it works, (and HTML `compatable' XHTML relies on this) is a complete and utter bodge.

This despite completely ungrounded claims that coding in xhtml will somehow 'speed' your page rendering, the only way that could happen is if the rendering engine first parses the whole page, decides that it has no errors, then applies the xhtml rendering to it, which of course would increase the time.

Another reason why sending XHTML as text/html is rather pointless. Send it as application/xhtml+xml, (which is what it is supposed to be) and as soon as the file fails the XML well-formedness checks, the browser can (indeed, must) throw an error and can stop processing. If it is well-formed, the file should be rendered quicker than a HTML version.

With all the work that has gone in to computer compilers over the years, throwing errors on syntax errors has always been the thing to do, instead of making guesses about what the writer meant to write.

This 33 message thread spans 2 pages: 33 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved