Re: An HTML language specification

Redirecting to www-archive per Mike's request.

On Tue, Nov 25, 2008 at 1:55 AM, Ian Hickson <ian@hixie.ch> wrote:
> 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.

Only the first sentence in the HTML 4 definition actually defines
anything, sure, but that's more useful than anything I found in the
HTML 5 definition.

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

Ok.

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

[...]

> 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 know, but neither a "Document" nor an infoset are relevant to the
definition of a markup language.  Both can be used after the document
has been parsed and interpreted, but neither need be referenced prior
to that point.

When a newbie user is doing "view source" on an existing site, and
making some changes that they will publish on their own site, there's
no DOM there.  There's just the user, the document, and hopefully some
specification which they can look at to tell them what all those
elements and attributes mean so they can make sense of their changes.

That's just an example of course.  Its intent is to convey the
importance of making as few assumptions about the audience for the
spec as possible, because I bet there are still uses for consuming
HTML that we haven't yet thought of.  Defining the language in terms
of an abstraction which isn't relevant to all uses of HTML is IMO,
prima facie a bad idea.

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

Ok.  So can we get a DOM-independent definition of "browsing context"?
 That would satisfy me, at least for that aspect of iframe's
definition (and any other element whose definition references browsing
contexts).

Mark.

Received on Tuesday, 25 November 2008 19:13:46 UTC