Introduction:
The inspiration for making this post was prompted by a question posted to the IE Web Development forum. Bug in IE9, table won't stretch 100%.
ref: http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/293f9d47-ac11-4197-92f9-cd5d55eefcf2
A post by McGerlach1 got me thinking....
it seems that the "relative to parent" does not work in nested tables.
This example works fine in Chrome, but in IE9 the nested table height of 100% is displayed much to large.
Any Ideas, what to do?
Thanks,
Marco
I copied and pasted his code, and sure enough Chrome and IE10 RC for win7 did produce different outcomes....
A cursory look at his markup will immediately indicate that he is not using valid html5 markup (he is using the depreciated height attributes instead of style rules... It looks like he has used an old snippet of markup and just added the html5 document type declaration...
Sure enough passing the markup through the html validator, confirms that there are errors...
Here is the w3c validator error output... (http://validator.w3.org )
- Line 4, Column 27: Element head is missing a required instance of child element title.
>
- Content model for element
head: - If the document is an
iframesrcdocdocument or if title information is available from a higher-level protocol: Zero or more elements of metadata content. - Otherwise: One or more elements of metadata content, of which exactly one is a
titleelement.
Line 6, Column 18: Attribute height not allowed on element tr at this point.
>
- Attributes for element
tr: - Global attributes
Line 9, Column 14: Attribute height not allowed on element tr at this point.
>
- Attributes for element
tr: - Global attributes
Line 15, Column 6: A table row was 1 columns wide, which is less than the column count established by the first row (2).
>
- Attributes for element
tr: - Global attributes
The errors for attribute height not allowed on element tr at this point seemed odd.... I would expect a warning or error to the effect, "html5 does not allow the use of depreciated attributes (height, width, align, valign, bgcolor, scroll, disabled...) use style rules instead. browsers will ignore the value of these attributes and only apply style rules that you have specified in stylesheets or inline."
If we use the w3c validator to change the document type declaration to 'strict', we see a different output...
Line 6, Column 13: there is no attribute "HEIGHT"
1
You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).
This error may also result if the element itself is not supported in the document type you are using, as an undefined element will have no supported attributes; in this case, see the element-undefined error message for further information.
How to fix: check the spelling and case of the element and attribute, (Remember XHTML is all lower-case) and/or check that they are both allowed in the chosen document type, and/or use CSS instead of this attribute.
This error may also result if the element itself is not supported in the document type you are using, as an undefined element will have no supported attributes; in this case, see the element-undefined error message for further information.
How to fix: check the spelling and case of the element and attribute, (Remember XHTML is all lower-case) and/or check that they are both allowed in the chosen document type, and/or use CSS instead of this attribute.
So... it would appear that xhtml5 is not a 'strict' dtd.... could that be? The document type declarations were introduced by the w3 consortium to provide a means of introducing new elements and style rules to the original SIGML (Special Interest Group Markup Language) without breaking existing web documents. It was intended that the document type declaration would give hints to the web browser or html editing software on how the markup should be parsed and errors corrected.
If xhtml5 is not a 'strict' dtd, then there exists the situation where a developer will reuse Quirks markup (no dtd, uses the depreciated attributes) and just add the html5 document type declaration to the top of his markup....a common misconception... in Australia we would call this 'Dressing Mutton up to look like lamb... regardless of how good it looks it will still taste poorly'. Putting a document type declaration on the top of an existing Quirks document does not make it standards compliant!.. There will still be uncertainty in how different browser vendors will 'interpret' how the depreciated attribute values are to be translated into style rules.
For example, how is a web browser to interpret the intentions of the author in this case
do they mean that the height of the table-row is 100px or 10px or is it just a typo? Which one will which web browser choose? Although the xhtml5 spec is the first to give guidelines on how
If xhtml was 'strict' then the guidelines would be clear.... web browsers would ignore depreciated attributes and only interpret the cascading style rules.
>tr height="100px" style="height:10px" >
would be interpreted as
<tr style="height:100px" > or <tr style="height:10px">
other ambiguous examples might be
<tr height="10px" style="height:10em" >... etc
How is every web browser going to interpret the correct correction for each possible error case?
What is going on in the test case submitted by McGerlach1? Which interpretation is the correct one?
Is Chrome (webkit actually) correct or is the IETeams' interpretation correct...
lets do some testing......
The Test Plan
Browser suite: the latest version of each vendors browser was used.... Internet Explorer (IE10 RC for Windows 7 10.0.9200.16439 - Pre Release), Google Chrome (version: 24.0.1312.52 m), Safari for Windows (5.1.7 (7534.57.2)), Mozilla Firefox (17.0.1) and Opera (12.02.1578) for Windows.
Method: the original source code by McGerlach1 was modified by only adding id attributes for the elements that will determine the 'strictness' of how each browser makes corrections.
Here is the slightly modified original source...with a html5 DTD.
Four other variations of this markup were created, replacing the html5 DTD with
HTML4 'Strict'
http://www.w3.org/TR/html4/strict.dtd
">HTML4 'Transitional'
http://www.w3.org/TR/html4/loose.dtd
">the 'Tidy HTML' abbreviated (and incorrect) HTML4 DTD.
No DTD...
.... the DTD was removed, leaving only the tag as the first tag in the document... web browsers should interpret this as a 'Quirks' document...there are no depreciated attributes. The values for these should be honored by the browser when deciding how to correct the markup.
Each document type variation of the markup was loaded into each of the browsers of the test suite, and using the developer tool of each browser the following javascript idioms were executed and the results tabulated. To test 'strict'-ness the idiom
{attributename as string} in element was used...
'height' in document.getElementById('trstar')
document.getElementById('trstar').height
document.getElementById('trcontent').height
document.getElementById('trcontent').style.height
document.getElementById('trstar').currentStyle.height
document.getElementById('trcontent').currentStyle.height
document.compatMode
Outcome....
Results:
Two Outcomes were observed. For convenience in the tables of results they have been labeled as A and B. Depending upon the forced Document Mode or the Document Mode determined by the Document type declaration (or lack thereof) MSIE and Opera browsers returned various results.
The Chrome, Firefox and Safari browsers ALWAYS had outcome B, regardless of the strictness or lack thereof of a document type declaration...
It should be noted that all of the available DocumentModes available in IE10 were tested by toggling the DocumentMode on the Developer Tool... the Default documentMode for the given DTD is marked as such.
For ease of presentation the two outcomes are presented as screen shots below, but are tabulated as either Outcome A or Outcome B...
Outcome A: the clientHeight of the nested table assumes the body height
Outcome B: the clientHeight of the nested tab assumes the height of its parent row element.
Which outcome is the 'correct' one?
Tables of Results:
| 'height' in document.getElementById('trstar') | document.getElementById('trstar').height | document.getElementById('trcontent').height | document.getElementById('trcontent').style.height | document.getElementById('trstar').currentStyle.height | document.getElementById('trcontent').currentStyle.height | document.compatMode | Outcome | |
| IE10 Standards (Default) | TRUE | "" | "" | "" | auto | auto | CSS1Compat | A |
| IE10 Quirks | TRUE | "" | "" | "" | auto | auto | BackCompat | B |
| IE9 Standards | TRUE | "" | "" | "" | auto | auto | CSS1Compat | A |
| IE8 Standards | TRUE | "" | "" | "" | auto | auto | CSS1Compat | A |
| IE7 Emulation | TRUE | "" | "" | "" | auto | auto | CSS1Compat | A |
| IE5 Quirks | TRUE | "" | "" | "" | auto | auto | BackCompat | A |
| Safari | FALSE | undefined | undefined | "" | error | error | CSS1Compat | B |
| Chrome | FALSE | undefined | undefined | "" | TypeError: Cannot read property 'height' of undefined | TypeError: Cannot read property 'height' of undefined | CSS1Compat | B |
| Firefox | FALSE | undefined | undefined | "" | [11:16:26.571] TypeError: document.getElementById(...).currentStyle is undefined | [11:16:26.571] TypeError: document.getElementById(...).currentStyle is undefined | CSS1Compat | B |
| Opera | TRUE | "*" | "" | "" | auto | auto | CSS1Compat | A |
Strict DTD.
Loose DTD
Conclusion:
As of the date of publishing the xhtml5 spec remains un-ratified...
Although the xhtml5 spec is the first that specifies how web browsers should correct errors only the IE Team has made submissions and these too are yet to be ratified.
ref: http://w3c-test.org/html/tests/reporting/report.htm
Using any of the tested document type declarations, Opera and MSIE browser always return false for the 'strict'-ness idom... 'height' in document.getElementById(elid)
but it would appear that even with a 'strict' DTD ALL browsers apply some form of error correction, the values of depreciated attributes are never completely ignored as the error output from the w3 validator suggests they should be.
Is Outcome A or Outcome B correct?
at this stage, while xhtml5 remains un-ratified, the answer is up in the air, although having submitted their test suites for ratification, the IETeam, Opera teams' interpretation (Outcome A) may be the winners.
But I think we are getting into Quantum Physics.... the outcomes are being determined by the Observer...
so...
Is xhtml5 'strict' - At first appearances it would appear not, although not all browser vendors use the same 'strictness' idiom.... {attributename as string} in HTMLElement
Even when a 'strict' document type declaration is used, browser interpretation of its meaning varies.
Should xhtml5 be 'strict' - In my opinion it should be. If it were then there would be no room for ambiguity by browser vendors in how they correct the interpretation of depreciated attributes to the equivalent style rules. Browsers would completely ignore the depreciated attributes and not attempt to apply corrections. However this assumes that web site developers will not use depreciated attributes in their markup. As is seen in the HTML forums, this is not always the case and it is easy for developers to assume that adding a document type makes their Quirks document 'standards' compliant... HTML editors with built-in error correction ('intellisence') are not widely available to all html editor vendors... Indeed many students of 'Web Design' are only offered 'Notepad' as their only HTML editor choice. The use of the w3 validator is not religiously practiced.
... it should be!
Can xhtml5 be 'strict' - It can at this stage... but as in the past when the 'strict' DTD's were ratified..interpretation of the 'standards' is subjective...
Already we are telling our web development communities to use the three tiers of web design.
Markup, CSS and Script
neither Markup, CSS or Script are compiled languages. They come down the wire 'as is'.... Unless the web developer does some kind of testing or validation before posting to their web servers there are bound to be mistakes.
A new DTD standard gives the Web Development Community the opportunity to move forward and not to be shackled by the mistakes of the past.
Unfortunately there is no means of policing web design practices.
