doctype of webpage.doc

7/29/2019 doctype of webpage.doc

1/19

Adding a doctype to your webpage

Doctype is a special declaration at the very top of your webpage source, right above the

tag, that informsvalidators 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, presentationalattributes, deprecated elements, and link targets. It is meant to be used for webpages that

are transitioning to HTML 4.01 strict:

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:

HTML 4.01 frameset is identical to Transitional above, except for the use of

over :

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:

Use XHTML 1.0 Strict when your webpage conforms to XHTML rules and uses CSSfor full separation between content and presentation:
http://validator.w3.org/http://validator.w3.org/http://validator.w3.org/


2/19

XHTML 1.0 frameset is identical to Transitional above, except in the use of the

tag over :

XHTML 1.1 DTD

XHTML 1.1 declaration. Visit the WC3 site for an overview and what's changed from

1.0:

Six months ago a readerof my site alerted me to an important bit of data: when using adoctype that switches Explorer 6 to Compatibility Mode, several properties ofdocument.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 allproperties ofdocument.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 W3CRecommendations 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:

document.documentElement has been standardizedby 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.
http://www.w3.org/TR/xhtml11/http://www.w3.org/TR/xhtml11/changes.html#a_changeshttp://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/DUWindowsNS6.htmlhttp://www.xs4all.nl/~ppk/js/index.html?fixedmenu.htmlhttp://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html#i-Documenthttp://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html#i-Documenthttp://www.w3.org/TR/xhtml11/http://www.w3.org/TR/xhtml11/changes.html#a_changeshttp://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/DUWindowsNS6.htmlhttp://www.xs4all.nl/~ppk/js/index.html?fixedmenu.htmlhttp://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html#i-Document


3/19

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 wecan 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 isfrequently 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 thebrowser 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 isno official W3C way to read out this information. (Shouldthere 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/Height and Explorer 4 and up supports

document.body.clientWidth/Height . All this works fine, though without the

blessing of W3C.

Doctype switching


4/19

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, Ihaven'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 propertiesofdocument.body and document.documentElement. The pairs are:

1. clientWidth, clientHeight

2. offsetWidth, offsetHeight

3. scrollWidth, scrollHeight4. 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

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 listcause 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
http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp?frame=true#cssenhancements_topic2http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp?frame=true#cssenhancements_topic2http://www.xs4all.nl/~ppk/js/doctype_on.htmlhttp://www.xs4all.nl/~ppk/js/doctype_off.htmlhttp://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp?frame=true#cssenhancements_topic2http://www.xs4all.nl/~ppk/js/doctype_on.htmlhttp://www.xs4all.nl/~ppk/js/doctype_off.html


5/19

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 ageneral rule, please note it in a comment below.

One rule concerning Explorer 6 in Strict mode has been made clear by Michael van

Ouwekerk of13th Parallel. He wrote:

From what I've gathered so far, IE6 in Strict mode always makes the html element as bigas 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 doctype-

sensitive: in standards compliance mode in Explorer 6 these properties belong todocumentElement, 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 bothbody 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 aresome examples that survive using a doctype that switches Explorer 6 to compatibility

mode:
http://www.xs4all.nl/~ppk/js/index.html?doctypes.htmlhttp://www.13thparallel.net/http://www.xs4all.nl/~ppk/js/index.html?doctypes.htmlhttp://www.13thparallel.net/


6/19

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 indocument.documentElement.scrollTop/Left . Opera is unreliable here. Fortunately

the old Netscape properties window.readerXOffset/pageYOffsetstill work in allNetscapes and Opera. So the script would become:

if (window.readerYOffset)

{

pos = window.readerYOffset

}

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 indocument.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.


7/19

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 resultswill 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 thisresearch, 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 internationalJavaScript 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, andO'Reilly's Web Dev Center, in

addition to Evolt.

13 comments on this article. Log into add your comment | Rate this article:

not so bad...

Submitted bybobince 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 asdocument.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 bothstandard.
http://www.xs4all.nl/~ppk/js/index.html?doctypes.htmlhttp://www.xs4all.nl/~ppk/js/index.html?doctypes.htmlhttp://www.quirksmode.org/http://www.quirksmode.org/dom/list.htmlhttp://www.digital-web.com/columns/keepitsimplehttp://alistapart.com/authors/k/peterpaulkochhttp://developer.apple.com/internet/webcontent/bestwebdev.htmlhttp://developer.apple.com/internet/webcontent/bestwebdev.htmlhttp://www.oreillynet.com/pub/a/javascript/synd/2002/11/15/css_pitfalls.htmlhttp://www.oreillynet.com/pub/a/javascript/synd/2002/11/15/css_pitfalls.htmlhttp://www.oreillynet.com/pub/a/javascript/synd/2002/11/15/css_pitfalls.htmlhttp://evolt.org/userhttp://evolt.org/userhttp://evolt.org/node/30655#comment-31350http://evolt.org/user/14476http://evolt.org/propstar/rate/30655/5http://evolt.org/propstar/rate/30655/4http://evolt.org/propstar/rate/30655/3http://evolt.org/propstar/rate/30655/2http://evolt.org/propstar/rate/30655/1http://www.xs4all.nl/~ppk/js/index.html?doctypes.htmlhttp://www.quirksmode.org/http://www.quirksmode.org/dom/list.htmlhttp://www.digital-web.com/columns/keepitsimplehttp://alistapart.com/authors/k/peterpaulkochhttp://developer.apple.com/internet/webcontent/bestwebdev.htmlhttp://www.oreillynet.com/pub/a/javascript/synd/2002/11/15/css_pitfalls.htmlhttp://evolt.org/userhttp://evolt.org/node/30655#comment-31350http://evolt.org/user/14476


8/19

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 InitialContaining 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 stuffthere 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 wemust 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 usebody.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 orregisterto post comments

Re: not so bad...

Submitted byppkon June 24, 2002 - 03:00.

This is less complicated than you think.

I think you underestimate the problem .
http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-31393http://evolt.org/user/380http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-31393http://evolt.org/user/380


9/19

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 bothstandard.

Yes, you're right. It's standardized in theDOM 1 HTML spec. I'd forgotten to lookoutside Core.

Secondly, the CSS2 box model does not allow you to set something's height to be relativeto 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 alsosupported 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 eitherscrollHeight oroffsetHeight,depending on the browser). It's not standardized, but who cares? (Besides, I'm still

wondering if thisshouldbe 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 haveto 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'thave 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'sbrowser 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 writtenfor 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 necessarynonetheless 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.
http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html#ID-1006298752http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html#ID-1006298752http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html#ID-1006298752


10/19

if (document.compatMode=='CSS1Compat') return

document.documentElement.clientWidth;

As I said before, I will not use this way of compatibility detecting. Otherwise your scriptseems sound.

ppk


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 littlemore: 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 withMozilla 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.


viewport vs. document elements

Submitted bybobince 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 onlyan 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 thesame height as the viewport).
http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-31437http://evolt.org/user/24720http://13thparallel.com/?issue=2002.06&title=viewporthttp://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-31452http://evolt.org/user/14476http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-31437http://evolt.org/user/24720http://13thparallel.com/?issue=2002.06&title=viewporthttp://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-31452http://evolt.org/user/14476


11/19

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. Thiscould 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 aworkaround 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.clientHeightas 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...


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 theheight 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 rootelement, with no content and with a lot of content? Should it always be as high as the

viewport?


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 runningin. (I think from v0.9 upwards).
http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-31454http://evolt.org/user/24720http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-31512http://evolt.org/user/16518http://richardinfo.com/case_studies/doctypes.htmlhttp://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-31454http://evolt.org/user/24720http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-31512http://evolt.org/user/16518http://richardinfo.com/case_studies/doctypes.html


12/19

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.


Specific implementations of DHTML model

Submitted by Doctor_Unclearon 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 notanswered 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. Ifscrollbars 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 thewidth 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 thebrowser's viewport (the window height and width as given by the browser or the user'sresizing 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" isconfusing 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 thescrollbar 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.


13/19

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 browserswill "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 thewindow object.

You said: "Microsoft defined lots of properties, the most important of which areclientWidth 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 adocument; 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 arealso 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 andwindow.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 canmeasure 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 thedocument.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


14/19

6 in standard compliant mode... and others on the documentElement element.

Well, these 12 properties (offset*, scroll* and client*) are not W3C standards to beginwith. 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 thesehttp://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 agreedupon 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 6is 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 inthe field of DHTML and DOM support.

You are right: there are no standards, no general rules. It's confusing, chaotic, anarchy inthere 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 theMSIE 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 bug-

free hassle-free 100% interoperable cross-browser code is there and will be furthermorestronger 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 pagewhich 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 Mozilla0.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...
http://bugzilla.mozilla.org/show_bug.cgi?id=62536http://bugzilla.mozilla.org/show_bug.cgi?id=62536


15/19

"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. Whenthere 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 theright 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 removethis 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 contentedge 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.
http://www.w3.org/TR/REC-CSS2/visuren.html#containing-blockhttp://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/DEOWWithOUTVScollBar.htmlhttp://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/DEOWWithOUTVScollBar.htmlhttp://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/HtmlBodyBugsMoz098.htmlhttp://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/HtmlBodyBugsMoz098.htmlhttp://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-detailshttp://www.w3.org/TR/REC-CSS2/visuren.html#containing-blockhttp://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/DEOWWithOUTVScollBar.htmlhttp://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/DEOWWithOUTVScollBar.htmlhttp://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/HtmlBodyBugsMoz098.htmlhttp://www.geocities.com/Area51/Realm/8655/HTMLJavascriptCSS/HtmlBodyBugsMoz098.htmlhttp://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details


16/19

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 matterof 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 whydoctypes 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, therewould 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 orhas 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 andnothing else.

The height/width of the html element within the viewing area, within the browserviewport, 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 suchpropertynames as they are in the other browser, otherwise this deliberately creates chaos,

confusion, cross-browser headaches.

Best regards,

DU


17/19


compatMode unreliable

Submitted by tarquinwj on July 2, 2002 - 03:19.

if (document.compatMode=='CSS1Compat') returndocument.documentElement.clientWidth;

Gecko browsers also give this property as 'CSS1Compat' if using a strict doctype.

However, they still give properties of body, not documentElement.


Re: compatMode unreliable

Submitted bybobince 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.


Demo case

Submitted by Doctor_Unclearon 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 htmlpadding-left + html content + html padding-right. Client area does not include scrollbars

nor html borders nor html margins.
http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-32272http://evolt.org/user/27934http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-32476http://evolt.org/user/14476http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-32930http://evolt.org/user/31232http://bugzilla.mozilla.org/attachment.cgi?id=90581&action=viewhttp://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-32272http://evolt.org/user/27934http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-32476http://evolt.org/user/14476http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-32930http://evolt.org/user/31232http://bugzilla.mozilla.org/attachment.cgi?id=90581&action=view


18/19

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 towardthe 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


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


THANKS!

Submitted byjellybellyjo 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 isthe only place i found any mention of the documentElement object, which fixed my

problem.

so once again, thanks heaps!! :)
http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-33353http://evolt.org/user/33352http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-60203http://evolt.org/user/60465http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-33353http://evolt.org/user/33352http://evolt.org/user/loginhttp://evolt.org/user/registerhttp://evolt.org/node/30655#comment-60203http://evolt.org/user/60465


19/19


your coments on:document.myBodyId vs document.body

Submitted by rgfon July 26, 2003 - 16:20.

Upto now I've used an id for the body element with Explorer to access properties of thebody.

(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

address this id with:document.myBodyId.clientWidth or document.myBodyId.scrollTop etc.

This reduces code in ppk's examples to :if (window.readerYOffset)

{

pos = window.readerYOffset

}

else if (document.myBodyId.scrollTop)

{

pos = document.myBodyId.scrollTop

}

doctype of webpage.doc

Documents

Transcript of doctype of webpage.doc