Re: An HTML language specification

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