- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 25 Nov 2008 06:55:48 +0000 (UTC)
- To: Mark Baker <distobj@acm.org>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-html@w3.org
On Tue, 25 Nov 2008, Mark Baker wrote: > > > > HTML4: The IFRAME element allows authors to insert a frame within a > > block of text. Inserting an inline frame within a section of text is > > much like inserting an object via the OBJECT element: they both allow > > you to insert an HTML document in the middle of another, they may > > [sic] both be aligned with surrounding text, etc. > > > > HTML5: The iframe element introduces a new nested browsing context. > > Where a browsing context is defined as "a collection of one or more > Document objects, and one or more views" > > Are you suggestinging those mean the same thing? If so, that's not at > all clear to me. I don't know what the HTML4 one really means, it seems to be a hodgepodge of ambiguous terminology. The HTML5 one is a very precise definition of what <iframe> is for. > > HTML4: The contents of the IFRAME element, on the other hand, should > > only be displayed by user agents that do not support frames or are > > configured not to display frames. > > > > HTML5: Descendants of iframe elements represent nothing. (In legacy > > user agents that do not support iframe elements, the contents would be > > parsed as markup that could act as fallback content.) > > Closer still, though the HTML 5 version seems advisory and doesn't > prescribe that the content is fallback content. There's an open issue on what the conformance requirement should be for the contents, which I didn't quote above. (For various complicated reasons to do with parsing and scripting in certain edge cases, it ends up being unusually complicated to define the content model of <iframe> accurately, and I haven't yet figured out the exact wording.) > > I don't really understand what you mean by "DOM-independent". What > > implementation are you considering for which the current text is > > lacking? > > I'm not considering any implementation. I'm trying to understand how to > interpret an HTML document using the HTML 5 specification, without > having to reference the DOM specification. I guess I don't understand why you would want to avoid referencing the DOM specification. Like Unicode, it provides a conceptual basis for the technology defined by the HTML specification. A "Document" (as used in the definition of "browsing context") is an object that represents a document, along with the tree that represents what in other circles is called the infoset of that document. > >> I agree that this doesn't necessitate a split of the spec (though I'd > >> still prefer that happened). But I think the minimum required to > >> resolve the issue would be to split the definitions into two > >> independent sub-sections. > > > > I don't understand what the sections would be. > > Something like; > > 4.8.3.1 Definition > 4.8.3.2 DOM view > > where the bulk of what's in 4.8.3 right now (editors' draft) would go in > 4.8.3.2, and something like what's in the HTML 4 definition would go > into 4.8.3.1. I don't really see the difference between the element's definition and its "DOM View". In particular, the definition of the <iframe> element has being a way to introduce a nested child browsing context is intended to be its definition, not just something that applies if you have a DOM. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 25 November 2008 06:56:33 UTC