W3C home > Mailing lists > Public > public-html@w3.org > November 2008

Re: An HTML language specification

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
Message-ID: <Pine.LNX.4.62.0811250645520.17401@hixie.dreamhostps.com>

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;
>  Definition
>  DOM view
> where the bulk of what's in 4.8.3 right now (editors' draft) would go in 
>, and something like what's in the HTML 4 definition would go 
> into

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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:39 UTC