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

Re: An HTML language specification

From: Mark Baker <distobj@acm.org>
Date: Tue, 25 Nov 2008 00:50:37 -0500
Message-ID: <e9dffd640811242150q4eff008btaa8444b936a50bb1@mail.gmail.com>
To: "Ian Hickson" <ian@hixie.ch>
Cc: "Boris Zbarsky" <bzbarsky@mit.edu>, public-html@w3.org

On Mon, Nov 24, 2008 at 6:11 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Mon, 24 Nov 2008, Mark Baker wrote:
>> Consider the definition of iframe.  I honestly don't know what part of
>> that section defines the meaning of the element.  The paragraph that
>> defines "sandbox" seems to be the only DOM-independent text I can find
>> there, so that would be part of it.  What about the rest (e.g. see the
>> HTML 4 definition)?
> 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.

> HTML4: The information to be inserted inline is designated by the src
> attribute of this element.
> HTML5: The src attribute gives the address of a page that the nested
> browsing context is to contain.

That's closer, but there's "browsing context" again.

> 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.

> 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 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

Received on Tuesday, 25 November 2008 05:51:13 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:39 UTC