W3C home > Mailing lists > Public > www-html@w3.org > February 2005

Nesting <HTML>...</HTML> tag pairs

From: Neal Murphy <neal.p.murphy@alum.wpi.edu>
Date: Sun, 20 Feb 2005 03:35:51 +0000
To: www-html@w3.org
Message-Id: <200502191448.25060.neal.p.murphy@alum.wpi.edu>

As near as I can determine, the HTML spec allows for only one pair of 
<HTML>...</HTML> tags to be present in a document. However, there are at 
least a few browsers that happily nest these tags and seem to display the 
information in the nested document as its author intended.

"Why would you want to do that?" you ask. Suppose I have a website built using 
tables to define the various 'areas' of the page, and that one of the 
website's pages displays the minutes from a meeting. I don't have the time to 
take their Word docs containing the minutes, reformat them to fit the 
website, create the HTML and install the document on the website. I would 
like to allow authorized folks to prepare content for one of these page 
'areas' and upload the complete HTML doc that they've prepared without having 
to rewrite the document to fit the website.

I've found that at least several browsers are quite happy to correctly display 
the contents of a nested HTML doc within a table cell. The people creating 
the 'sub documents' are not computer/programming/HTML gurus - just operating 
MS Word is a bit of a challenge for them - so I cannot hope to require they 
produce nice clean HTML snippets. I intend to rely on this 'feature' so they 
can prepare the web document using standard tool and put it up without 
requiring excess work from me (or them).

Is this browser behavior 'proper'? If not, should it be? Yes, ideally the 
whole document should be consistent, but realities often treat ideals 
roughly. Should the spec allow nesting of <HTML>...</HTML> tag pairs so that 
any reasonable containing object can format and display an HTML document 
fairly independently of the rest of the page?

Received on Monday, 21 February 2005 18:35:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:10 UTC