Doctype of Webpage

Adding a doctype to your webpage
Doctype is a special declaration at the very top of your webpage source, right above the <HTML> tag, that informs validators the rules in which to validate your page using, and for modern browsers (IE6+, Firefox, NS6+, Opera, IE5 Mac), whether to display your page in Quirks or Standards mode. Below lists the major doctypes you can deploy on your webpage. All of them enters modern browsers into "Standards" mode when used. HTML 4.01 Transitional, Strict, Frameset HTML 4.01 transitional doctype supports all attributes of HTML 4.01, presentational attributes, deprecated elements, and link targets. It is meant to be used for webpages that are transitioning to HTML 4.01 strict:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
HTML 4.01 Strict is a trimmed down version of HTML 4.01 with emphasis on structure over presentation. Deprecated elements and attributes (including most presentational attributes), frames, and link targets are not allowed. CSS should be used to style all elements:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
HTML 4.01 frameset is identical to Transitional above, except for the use of <frameset> over <body>:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
XHTML 1.0 Transitional, Strict, Frameset Use XHTML 1.0 Transitional when your webpage conforms to basic XHTML rules, but still uses some HTML presentational tags for the sake of viewers that don't support CSS:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Use XHTML 1.0 Strict when your webpage conforms to XHTML rules and uses CSS for full separation between content and presentation:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XHTML 1.0 frameset is identical to Transitional above, except in the use of the <frameset> tag over <body>:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
XHTML 1.1 DTD XHTML 1.1 declaration. Visit the WC3 site for an overview and what's changed from 1.0:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Six months ago a reader of my site alerted me to an important bit of data: when using a doctype that switches Explorer 6 to Compatibility Mode, several properties of document.body are reassigned to document.documentElement. This information enabled me to get one of my scripts working in Explorer 6 with a doctype. At first I thought that all properties of document.body were reassigned to document.documentElement, but this turned out not to be the case. Because the data confused me and because I had other things to do, I only skimmed through the W3C Recommendations and Flanagan's "JavaScript, the Definitive Guide" to get a theoretical overview. I postponed the necessary browser tests, because they were likely to be complex and time-consuming.
Theory
The overall picture that emerged was as follows:
has been standardized by W3C as a kind of shortcut to the HTML element, the highest element in the DOM tree of any (X)HTML page. W3C has not defined any properties for this element. document.body has been added by Microsoft. Originally it was a convenience object that had several properties with information about the current state of the browser window and the document in it. Microsoft defined lots of properties, the most important of which are clientWidth and clientHeight which store the current size of the browser window. It also has properties like document.body.text, accessing the old TEXT attribute. It thus (also) refers to the BODY element.
document.documentElement
Netscape 6, Explorer 5 and Konqueror have adopted documentElement as part of their W3C DOM support. body was originally Explorer-only, but more recently both Netscape 6 and Opera 6 have started supporting it (Konqueror not tested). So documentElement refers to the outermost box in a document, the HTML element, while body refers to its only child box: the BODY element. Through their properties we can read out information about the two most important elements.
-------------| HTML | |------------| || BODY || || || || || || || || || |------------| --------------
Unfortunately my tests have proven this theoretical model to be unfounded when applied to properties like clientWidth and offsetHeight. Besides there is a third box that needs to be measured: the browser window itself. It is frequently far smaller than the HTML document it contains. The theoretical model described above doesn't leave any room for the window dimensions; nonetheless they are present.
No standards
What we want is to read out interesting information about the entire HTML page and the browser window. One of the problems is that the properties that contain this information are not standardized. In the W3C DOM, to read out the total height of the HTML document you'd have to do
document.defaultView.getComputedStyle(document.documentElement,null).ge tPropertyValue("height")
Apart from the syntax being way too complicated, this only works in Mozilla. It's even worse if you want to know the window width and height or the scrolling offset: there is no official W3C way to read out this information. (Should there be one? At the moment I don't think so. But feel free to disagree.) Fortunately the browser vendors have created their own properties: Netscape 4 and up supports window.innerWidth/<wbr>Height and Explorer 4 and up supports document.body.clientWidth/<wbr>Height. All this works fine, though without the blessing of W3C.
Doctype switching
When Explorer 6 added the possibility of entering strict standards compliance mode by using certain doctypes, it turned out that using these doctypes also influenced the value of some of these properties. As far as I know this happens only in Explorer 6 on Windows, I haven't yet found a trace of doctype-switching effects on JavaScript properties in Mozilla and Explorer on Mac. (But I stand ready to be corrected) So what exactly happens? I wondered for six months, then finally found the time to do some browser tests.
The experiment
So I set up an experiment. I researched four property pairs, all of which may be properties of document.body and document.documentElement. The pairs are: 1. 2. 3. 4. clientWidth, clientHeight offsetWidth, offsetHeight scrollWidth, scrollHeight scrollTop, scrollLeft
I created two test pages which print out the values of these properties. They are exactly the same, except that I added the doctype
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN">
to one of them. It causes Explorer 6 to enter compatibility mode. I chose this doctype more or less randomly. For the moment I assume that all doctypes in Microsoft's list cause the same compatibility mode. (Here, too, I stand ready to be corrected in case anyone has noticed a difference). View the test pages for yourself, if you like.

Test page with doctype Test page without doctype
I tested the various properties in several browsers: Explorer 5.0 and 6.0 on Windows, Explorer 5.0 on Mac OS 9 and 5.1 on OS X, and Mozilla 1.0 final. I also studied Opera 6, which doesn't support documentElement at all. There were no differences between both Mac Explorers, only very slight differences between the Windows Explorers on the no-doctype page. The actual testing consisted of carefully measuring the various widths and heights and finding out which properties contained these numbers.
No general rules
I'd hoped to find some general rules for dealing with document.body, document.documentElement and doctype switching. Unfortunately the conclusion must be that there are considerable differences between body and documentElement and that a lot happens in Explorer 6 when switching between quirks and standards mode, but that it is impossible to formulate a general theory. See the table of research results and try to make sense of it. I can't. If you do find a general rule, please note it in a comment below. One rule concerning Explorer 6 in Strict mode has been made clear by Michael van Ouwekerk of 13th Parallel. He wrote: From what I've gathered so far, IE6 in Strict mode always makes the html element as big as the viewport. The styles given by currentStyle are width: auto, height: auto, overflow: scroll. The offsetWidth and offsetHeight are always equal to the viewport's width and height. When there is a lot of content, the overflow: scroll takes care of that. This seems to explain the values I found, so I think he's right. A few more interesting points:
Above I said document.body is supposed to represent the BODY element, while document.documentElement should represent the HTML element. This turned out only to be the case with the offset properties in Mozilla and the scrollWidth/Height properties in Explorer 6 in standards compliance mode. Otherwise this theory has little to do with practice. Explorer 5 on Mac and Opera 6 are inconsistent in their use of the offset properties. While offsetHeight gives the height of the entire HTML document (as it does in most other browsers), offsetWidth gives the width of the window, not of the HTML document. The only reliable property pair is scrollTop/Left: it always gives the amount of pixels the page has scrolled. Unfortunately this information is highly doctypesensitive: in standards compliance mode in Explorer 6 these properties belong to documentElement, while in quirks mode they belong to body, just like in all other browsers. In Explorer 5.0 on Windows these properties were assigned to both body and documentElement. I wish Explorer 6 had done the same regardless of doctype, it would spare me the need to rewrite scripts. I have been unable to find out what function the scrollLeft/Top property pair has in Opera 6. The values simply don't make sense.
Practice
So how do you write cross-browser scripts that avoid all these complications? Here are some examples that survive using a doctype that switches Explorer 6 to compatibility mode:
Scrolling offset The scrolling offset of the page is reflected in document.body.scrollTop/Left, except when you use a doctype in Explorer 6, then it is reflected in document.documentElement.scrollTop/Left. Opera is unreliable here. Fortunately the old Netscape properties window.pageXOffset/pageYOffset still work in all Netscapes and Opera. So the script would become:
if (window.pageYOffset) { pos = window.pageYOffset } else if (document.documentElement && document.documentElement.scrollTop) { pos = document.documentElement.scrollTop } else if (document.body) { pos = document.body.scrollTop }
and pos contains the vertical scrolling offset. Window dimensions The window dimensions are reflected in document.body.clientWidth/Height, except when you use a doctype in Explorer 6, then they are reflected in document.documentElement.clientWidth/Height. Opera is unreliable here, the window height is never less than the height of the HTML document. Fortunately the old Netscape properties window.innerWidth/Height still work in all Netscapes and Opera. So the script would become:
if (window.innerWidth) { theWidth = window.innerWidth } else if (document.documentElement && document.documentElement.clientWidth) { theWidth = document.documentElement.clientWidth } else if (document.body) { theWidth = document.body.clientWidth }
and theWidth contains the width of the window. Note that the clientWidth is always the width excluding the scrollbars. Generally (but not always), offsetWidth/Height gives access to the window width including the scrollbars.
Conclusion
The conclusion must be that the implementation of the body/documentElement properties in the various browsers, with and without doctypes, is very complicated. I can find no overall theoretical model that explains what the four property pairs are for and what the effect of a doctype switch is. I hope my table of research results will allow people to formulate theories. If you think you understand the behaviour of a certain browser (or, better yet, all browsers), please leave a comment below. Peter-Paul Koch is a freelance browser expert and JavaScript guru living in Amsterdam, the Netherlands. He has been an Internet professional only since 1998, so he's definitely second generation. His personal site is www.quirksmode.org. It includes the W3C DOM Compatibility Tables, currently the best resource on the Internet for this subject. Because of this research, he has been asked to co-edited chapters 17 to 19 of Flanagan's "JavaScript, the Definitive Guide", O'Reilly, 4th edition. He is an administrator of the WDF-DOM mailing list, that counts most international JavaScript gurus among its members. He has written the "Keep it Simple" column on Digital Web Magazine, as well as articles on A List Apart, Apple Developer Connection, and O'Reilly's Web Dev Center, in addition to Evolt. 13 comments on this article. Log in to add your comment | Rate this article: not so bad... Submitted by bobince on June 23, 2002 - 12:46. This is less complicated than you think. Firstly, both document.documentElement and document.body are fully standardised in DOM Level 1. document.documentElement is DOM1-Core and refers to the root element, in this case html. It would return the same thing as document.getElementsByTagName('html')[0]. document.body is DOM1-HTML and refers to the body element. It would return the same as document.getElementsByTagName('body')[0]. document.body is supported by a few more browsers (IE4, Opera) than document.documentElement, but they are both standard.
Secondly, the CSS2 box model does not allow you to set something's height to be relative to the height of the viewport unless the element has 'position: fixed'. This may be remedied in CSS 2.1, but currently the spec does not define how high the Initial Containing Block is, or whether the root element is the ICB (it is self-contradictory on the matter, in fact), so you can't guarantee the html element will be any particular height at all. You also can't even read the height of an element in standard DOM - clientHeight etc. are IE extensions, albeit ones also supported by Moz, Konq and Op6. By far the best way of reading the size of the viewport is window.innerWidth/Height. Unfortunately, IE (and only IE of the JS browsers AFAIK) doesn't support it, so we have to come up with a backup plan for that browser. We can use the clientWidth/Height stuff there only because we know IE does make the root element the Initial Containing Block and does make that the height of the viewport. It is best not to rely on this where we don't have to. The way to detect whether IE6 Standards Mode is in operation is to use the document.compatMode property. If it is "CSS1Compat" we have IE6 Standards and we must read documentElement.clientHeight; if it is "BackCompat" we have IE6 Quirks; if it is undefined we have IE5.5 or earlier. In both the latter cases we must use body.clientHeight. Finally, window.innerWidth may legitimately be zero, and hence generate a false negative with "if (window.innerWidth)". Pull it together and you get code like: if (window.innerWidth!=window.undefined) return window.innerWidth; if (document.compatMode=='CSS1Compat') return document.documentElement.clientWidth; if (document.body) return document.body.clientWidth; return window.undefined; (and similarly for height) BTW if you're interested in emulating 'position: fixed' in IE/Win for things like sticky menus, see http://and.doxdesk.com/software/js/fixed.html login or register to post comments Re: not so bad... Submitted by ppk on June 24, 2002 - 03:00. This is less complicated than you think. I think you underestimate the problem <g>.
document.body is DOM1-HTML and refers to the body element. It would return the same as document.getElementsByTagName('body')[0]. document.body is supported by a few more browsers (IE4, Opera) than document.documentElement, but they are both standard. Yes, you're right. It's standardized in the DOM 1 HTML spec. I'd forgotten to look outside Core. Secondly, the CSS2 box model does not allow you to set something's height to be relative to the height of the viewport unless the element has 'position: fixed'. You can't guarantee the html element will be any particular height at all. You also can't even read the height of an element in standard DOM - clientHeight etc. are IE extensions, albeit ones also supported by Moz, Konq and Op6. Which is exactly the problem I'm adressing. The HTML element is interpreted differently by different browsers. Fortunately you can read out the width and height of the HTML element in all browsers (though you must use either scrollHeight or offsetHeight, depending on the browser). It's not standardized, but who cares? (Besides, I'm still wondering if this should be standardized. Any comments are welcome.) By far the best way of reading the size of the viewport is window.innerWidth/Height. Unfortunately, IE (and only IE of the JS browsers AFAIK) doesn't support it, so we have to come up with a backup plan for that browser. We can use the clientWidth/Height stuff there only because we know IE does make the root element the Initial Containing Block and does make that the height of the viewport. It is best not to rely on this where we don't have to. I don't get this. There are two possibilities for reading out window height: window.innerHeight and document.something.clientHeight. They may not be perfect, but what is? Something may theoretically be better than something else, but it's browser behaviour that counts. The way to detect whether IE6 Standards Mode is in operation is to use the document.compatMode property. If it is "CSS1Compat" we have IE6 Standards. This is one way, certainly. The advantage of my way is that it's not specifically written for IE6. What if another browser, that doesn't support document.compatMode, also stores clientWidth in document.documentElement? With your method we wouldn't catch it. I never use any browser-specific coding if I can help it. (Of course, it's necessary nonetheless in the majority of cases). Finally, window.innerWidth may legitimately be zero, and hence generate a false negative with "if (window.innerWidth)". Pull it together and you get code like: That's true, a simple else return 0 at the end of the code would solve this.
if (document.compatMode=='CSS1Compat') return document.documentElement.clientWidth; As I said before, I will not use this way of compatibility detecting. Otherwise your script seems sound. ppk login or register to post comments related article / extra comments Submitted by Michael on June 24, 2002 - 14:02. Hey, you quoted me :) Then I might as well pimp the article I wrote about this a little more: The Viewport. This offers some scripts and a lot of examples and testcases for some of the problems described here. The only reason why some browsers support unexpected features appears to be "let's support this property because Internet Explorer has it". This seems certainly true with Mozilla and Opera, since they have (partially) implemented the offset and client properties. The problem with such implementations is that they copy the property names but they do not behave the same way because the rendering engine is different in undocumented ways. Perhaps it's true that the W3C specs are not precise enough about the root element - I would very much like to see some clarifications in a CSS 2.1 recommendation. login or register to post comments viewport vs. document elements Submitted by bobince on June 24, 2002 - 15:23. Besides, I'm still wondering if this should be standardized. Any comments are welcome. The problem with the IE way of doing it (clientHeight, scrollTop etc.) is that it mixes up document-specific DOM elements and view-specific properties. DOM Views had a better seperation but remains unstandardised, the current DOM 2 Views document being only an empty shell. In any case, relying on a document element to read the size of the viewport is a doubtful proposition when CSS says they're essentially unrelated (unless you go to the lengths of making body fixed-positioned with 100% height, in which case you can be sure it's the same height as the viewport).
Some other browser that supports the clientFoo extensions but takes CSS literally on the height of the root element might return the height of the entire document for document.documentElement.clientHeight instead of the height of the viewport. This could even happen in IE7 if they make an Even More Standards Compliant Mode! :-) That's why I prefer the window.innerHeight method and consider the clientHeight stuff a workaround to that. It has been documented for ages and is widely supported by everyone except MS. As for the compatMode switch, you'll notice if it fails it tries document.body.clientHeight anyway. The thinking is that a theoretical browser trying to emulate IE but not knowing about compatMode is most likely to be putting the height in document.body.clientHeight as IE5 did. I admit it's a guess, but it's probably a good guess. And a good guess is the best you can do with object sniffing. Roll on CSS 2.1... login or register to post comments html element size Submitted by Michael on June 24, 2002 - 16:03. "Some other browser that supports the clientFoo extensions but takes CSS literally on the height of the root element might return the height of the entire document for document.documentElement.clientHeight instead of the height of the viewport." This is something I've been wondering about. What should be the height of the root element, with no content and with a lot of content? Should it always be as high as the viewport? login or register to post comments document.compatMode also in Mozilla Submitted by www_richardinfo_com on June 25, 2002 - 04:23. Hi, Last year I spent some time trying to detect which mode the browser was running in: http://richardinfo.com/case_studies/doctypes.html It's not all that correct, and pretty messy. I was however contacted by a mozilla developer, who said that document.compatMode had been added to Mozilla, to make it easier to determine the mode Mozilla was running in. (I think from v0.9 upwards).
This actually complicates things though, as you now cannot rely on if(document.compatMode) being IE6 in strict mode. Finally I gave up on this stuff, and designed pages a little more loosely. It's a bit like font-sizes, if we don't set a fixed font-size, the user can view it like they want. If we try to set the fontsize the same cross-browser/platform, we fail. login or register to post comments Specific implementations of DHTML model Submitted by Doctor_Unclear on June 26, 2002 - 21:49. Hello Mr. Koch, First let me congratulate you for the research you did. I myself researched this issue quite a lot as well. There is an important question that your article (and 13th parallel's article) still have not answered yet. And it has decisive consequences for a lot of other questions and answers. Scrollbars are part of what, of which object? Once browser makers, sites developpers all agree on the answer to that question, only then we will all see things differently. If scrollbars are part of the elements which generate them, then it is absolutely illogical to speak in terms of "window height/width with/without scrollbars" if the html element is the element responsible for the appearance of scrollbars. Would you say: "What's the width of this building when there is an elevator? when there is no elevator? What's the width of this house when the garage door is opened? when the garage door is closed?" Such questions would all be irrelevant. When a document width or height exceeds the browser's viewport (the window height and width as given by the browser or the user's resizing actions) then an overflow on the document happens. That's why CSS allow us to set the overflow property on the html element, or the body element. If the window object was the object responsible for scrollbars, then there would be a property for that: something like window.scrollbars = true or window.scrollbars = none window.scrollbars = auto or window.overflow = scrollbars, etc...would be possible, doable, implementable. It's not the case. So, speaking of "window height/width excluding/including scroll bars" is confusing matters, is misleading. And when 13thparallel is saying "window.innerWidth/Height does not exactly get the viewport size the way we want it, because these properties add the space for the scrollbar if it is visible" this also confuses matters, misleads. Window.innerWidth/Height never adds nor substracts the space for the scrollbar because scrollbars are not part of the browser's viewport. Chrome elements adds or substracts available space for window.innerWidth/Height. Open up Opera 6.x without any loaded document: you could then measure the window.inner* properties while there would not be any document at all. This is where I do make the distinctions.
One thing that your article failed to say is that in standards compliant rendering mode, MSIE 6 treats scrollbars as part of the html element when MSIE 6 in compatible mode and MSIE 5.5 treat scrollbars as part of the body element. That is what these browsers will "tell" you: I've tested this in several ways and always got the same answers. The browser's viewport size/dimensions should be, always should be properties of the window object. You said: "Microsoft defined lots of properties, the most important of which are clientWidth and clientHeight which store the current size of the browser window." Hold it right there! clientWidth and clientHeight do not represent the size of the browser window since scrollbars, borders and margins are not stored in there. Scrollbars are part of the elements which support them, which use them. Therefore, scrollbars are part of a document; a document's width and height should compute the width and height of these scrollbars if present. Scrollbars must be considered as part of the elements which generate them, which display them, otherwise you would have to say that scrollbars are part of the window chrome just like toolbars, statusbar, etc. and that cannot be the case. Borders are also part of an element's display as well ... otherwise, you would have to say that borders on a div are part of the window chrome. When one tries to figure out the current size of a browser window, he has only 2 choices: either access a property which gets this value (Netscape window.innerWidth and window.innerHeight do exactly that) or calculate the whole height or width a document takes within the browser's rendering area, content area while being displayed and here you have to include margins, scrollbars, borders as well as these are display properties of the element. You can measure the hole or you can measure the substance, the matter filling, covering perfectly the hole: either way, you should end up measuring the same distance. You can measure inner size of a window or you can measure the document's view (its content, margins, borders, padding, scrollbars) which fills the viewable area of the window which you are actually viewing. Later you repeat: "The window dimensions are reflected in document.body.clientWidth/Height, except when you use a doctype in Explorer 6, then they are reflected in document.documentElement.clientWidth/Height." Again, I disagree. If you want the strict width/height of the document (content + padding), then clientWidth/Height is good enough: if you want to measure the window width and height, then you have to measure these from the "document" perspective in MSIE and use the document.documentElement.offsetWidth/Height. Even the event.clientX/Y and evt.clientX/Y property support my reasoning here for both MSIE 5+ and NS6+. Even the event.offsetX/Y property MSIE 6 support my reasoning as well. You mentioned that 1) document.documentElement is the current W3C standard through which we can now access the root element of a document 2) properties like clientWidth, offsetHeight, scrollHeight, etc... are not properly supported by Mozilla, Netscape, MSIE
6 in standard compliant mode... and others on the documentElement element. Well, these 12 properties (offset*, scroll* and client*) are not W3C standards to begin with. They are all part of MSIE's DHTML object model and even that DHTML object model (as explained by MSDN) is not without any contradiction or bugs you know. So, it may take some time to Mozilla to implement these http://bugzilla.mozilla.org/show_bug.cgi?id=62536 where it is clearly indicated that these scrollHeight, scrollWidth, clientHeight, clientWidth properties are only for divs. "One of the problems is that the properties that contain this information are not standardized. " In my opinion, the properties that contain this information are not standardized and that's the only problem. Once an informal or official standard is agreed upon some kind of rules (like DHTML object property specs), all of these problems will disappear. Without standards, only confusion, workarounds headaches, etc. will prevail. I'm convinced we're moving toward more smooth and hassle-free interoperability. The fact that MS corrected a lot of its faulty CSS implementation with the release of MSIE 6 is a sign that we're slowly moving toward such direction. MSIE 6 just looks like an incomplete work but nevertheless one cannot claim that others (like Opera) are better in the field of DHTML and DOM support. You are right: there are no standards, no general rules. It's confusing, chaotic, anarchy in there simply because there are no known official standards covering these properties. IMO W3C should have standardized the DHTML object model as well. IMO, W3C is bound to standardize these properties. IMO, this is exactly what Mozilla tries to do anyway, with or without W3C getting involved, soon or later. Mozilla.org implements the MSIE properties which are useful, relevant to web page designers. "It's even worse if you want to know the window width and height or the scrolling offset" Exactly. Absolutely true. "there is no official W3C way to read out this information. (Should there be one?" Yes, there should be one, absolutely. The need for reliable bugfree hassle-free 100% interoperable cross-browser code is there and will be furthermore stronger as time passes. Let me give you 2 examples here. On february 18th 2002, I posted in comp.lang.javascript (subject line: offsetLeft bug in IE5.5) the full code of an html page which would generate (via an alert) 4 different offsetLeft values in 3 distinct browsers: 2 totally different values for MSIE 6 (1 with a full doctype and the other without any doctype decl.), a 3rd different value for Opera 6.01 and a 4th different value for Mozilla 0.9.7. Just incredible! 1 single page, 1 single DHTML property question and 4 different answers coming from 3 distinct browsers. MSIE 5+ uses screenTop, Gecko-based browsers uses screenY and Opera 6.x uses screenY as one of the window properties...but when you examined carefully each of their implementation, you end up with 3 different - totally different and totally incompatible implementations. And I'm not talking about bugs here or absence of support, you know...
"From what I've gathered so far, IE6 in Strict mode always makes the html element as big as the viewport." And that is a W3C standard spec violation! The root element should not be stretching to fit the viewport if its contents are smaller than the height of the viewport. According to CSS2, section 9.1.2: http://www.w3.org/TR/REC-CSS2/visuren.html#containing-block says: "The height of the initial containing block may be specified with the 'height' property for the root element. If this property has the value 'auto', the containing block height will grow to accommodate the document's content." http://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/DEOWWithOUTV ScollBar.html and you'll see that only Opera 6 respects the standard. MSIE 6 doesn't. "The styles given by currentStyle are width: auto, height: auto, overflow: scroll. The offsetWidth and offsetHeight are always equal to the viewport's width and height. When there is a lot of content, the overflow: scroll takes care of that." Just open a blank page with MSIE 6 and it will have a dimmed vertical scroll bar at the right side. This is the effect of the stated styles up there. If you declare html { overflow:auto; } in the style sheet of a blank page with a full doctype in MSIE 6, there won't be any scroll bar. Say you have a document and an absolutely positioned div in that document. But you position this div at, say, top:800px. Now, I tested this with Mozilla 0.9.8, MSIE 6 in compliant mode and Opera 6, and... surprise!.. Opera is the only browser that will remove this div from the body and then remove it from the html element and place it outside the visual display of the html element. http://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/HtmlBodyBugsMoz 098.html W3C CSS2 10.1 Definition of "containing block" http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details says: "If the element has 'position: absolute', the containing block is established by the nearest ancestor with a 'position' other than 'static' (...) If there is no such ancestor, the content edge of the root element's box establishes the containing block" So, we know that Opera 6 violates a web standard spec here; MSIE 6 and NS 6+ comply with the standard.
There is one thing you never said in your article which is quite important: absolutely positioned elements are removed from the normal flow (and the body element as a matter of fact) and put into the html element outside the body element: that's exactly what W3C says and that's what NS6+ and MSIE 6 in standards compliant rendering mode do. So your html vs body model works regarding absolutely positioned elements. "I wish Explorer 6 had done the same regardless of doctype, it would spare me the need to rewrite scripts." I share your feeling but maybe you need to better understand why doctypes were made in the first place. Doctypes are there so that browsers, user agents, validators get to know which version of HTML is being used, how to parse or check or render the document's syntax, how strictly it should be parsed, checked, rendered, etc. If we were all complying to the same type of strict compliant adherence to standards, there would be no need at all for doctypes. And why should browsers support different modes of rendering? There would be no need for different modes of web page rendering if we were all willing to learn, apply, comply with standards. It is known that Opera only knows of 1 rendering mode and Opera does not bother at all whether a document has or has not a doctype declaration. Opera always try to render the page in strict compliant mode. And this is what all browsers should aim at achieving. In your table of measurements, for Mozilla 1.0 browser, you give this: Height of the HTML element : dE.offsetHeight b.scrollHeight dE.scrollHeight Width of the HTML element : dE.offsetWidth b.scrollWidth dE.scrollWidth In my opinion, the height/width of the html element should be dE.scrollHeight/Width and nothing else. The height/width of the html element within the viewing area, within the browser viewport, client area should be dE.offsetHeight/Width and nothing else. Same thing in your compatibility table, for Mozilla 1.0 browser: document.documentElement.offsetHeight: Height of the HTML element. That shouldn't be the case. document.documentElement.offsetWidth: Width of the HTML element Everytime a browser uses the propertynames of a model which comes from another browser maker, then such browser must implement the functionality of such propertynames as they are in the other browser, otherwise this deliberately creates chaos, confusion, cross-browser headaches. Best regards, DU
login or register to post comments compatMode unreliable Submitted by tarquinwj on July 2, 2002 - 03:19. if (document.compatMode=='CSS1Compat') return document.documentElement.clientWidth; Gecko browsers also give this property as 'CSS1Compat' if using a strict doctype. However, they still give properties of body, not documentElement. login or register to post comments Re: compatMode unreliable Submitted by bobince on July 3, 2002 - 06:11. Gecko browsers also give this property as 'CSS1Compat' if using a strict doctype. However, they still give properties of body, not documentElement. Yes. Again, it's better to use window.innerFoo: where available, it's reliable. the document.fooEl.clientBar properties aren't and shuold be used only as a last resort. login or register to post comments Demo case Submitted by Doctor_Unclear on July 9, 2002 - 00:31. Go to this precise url while using MSIE 6 for windows (MSIE 5.x for Mac might work...I don't know). Using any other browser should not work, will not work. http://bugzilla.mozilla.org/attachment.cgi?id=90581&action=view In there, you'll see a demo case exemplifying what is the client area dimensions in MSIE 6 in standards compliant mode, how to measure them (width, height) what is the browser's viewport dimensions, how to measure them what is the difference between these 2. Simply put, client area dimensions are given by document.documentElement.clientWidth/Height . Simply put, client area is given by html padding-left + html content + html padding-right. Client area does not include scrollbars nor html borders nor html margins.
The browser's viewport dimensions in MSIE 6 in standard compliant mode are given by document.documentElement.offsetWidth/Height . The browser's viewport dimensions include html content + html paddings + html borders + scrollbars. These d.dE.offsetWidth/Height properties are the equivalent of Netscape 6+'s window.innerWidth/Height values. They are the browser's viewport dimensions from the "document" perspective while Netscape 6+'s window.innerHeight/Width are the browser's viewport dimensions from the "window" perspective. As long as the user does not resize the browser window, the d.dE.offsetHeight/Width will not change. The user can add/remove html borders, generate/ "remove" scrollbars, etc.. .: the d.dE.offsetWidth/Height values will not change in MSIE 6 in standards compliant mode. The moving lines (red, blue, purple) are there to see how dynamically generated scrollbars (without any window resizing) affect the client and offset values. Just move the mouse toward the right, beyong the right window border of the browser to generate an horizontal scrollbar and observe the changes in the form fields. Move the mouse toward the bottom, beyond the statusbar to generate a vertical scrollbar and then observe how it impacts values in the form. Using a high video screen resolution for this demo is preferable. DU login or register to post comments about html { overflow:auto; } and mozilla. Submitted by fished on July 11, 2002 - 16:41. Must be only me but Mozilla doesnt like that in your CSS: html { overflow:auto; } Nice for IE though. Ah, interesting topic. Later login or register to post comments THANKS! Submitted by jellybellyjo on April 14, 2003 - 17:44. Just wanted to say a huge THANK YOU for your tips about scrollTop and scrollLeft and how to use them properly depending on your browser. I was getting extremely frustrated because no matter what i did, they were always 0, and my values were inaccurate. This is the only place i found any mention of the documentElement object, which fixed my problem. so once again, thanks heaps!! :)
login or register to post comments your coments on:document.myBodyId vs document.body Submitted by rgf on July 26, 2003 - 16:20. Upto now I've used an id for the body element with Explorer to access properties of the body. (eg the actual document height/width and not the browser window.) I can't see anything against this, but am very interested in your comments/experience. Give the body tag an id <body id="myBodyId"> address this id with: document.myBodyId.clientWidth or document.myBodyId.scrollTop etc. This reduces code in ppk's examples to :
if (window.pageYOffset) { pos = window.pageYOffset } else if (document.myBodyId.scrollTop) { pos = document.myBodyId.scrollTop }

Doctype of Webpage

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Doctype of Webpage

Hochgeladen von

Copyright:

Verfügbare Formate

Adding a doctype to your webpage

Test page with doctype Test page without doctype

Das könnte Ihnen auch gefallen