Re: An HTML language specification

On Tue, 25 Nov 2008, Mark Baker wrote:
> 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.

I guess I don't know what you're looking for. Could you elaborate on what 
it is you want from the spec's definition that HTML4 gives you but that 
HTML5 does not? I actually don't understand what HTML4's text means -- 
what's a "frame"?


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

I don't really understand in what sense there is anything to talk about 
before the document has been parsed and interpreted. I mean, you can have 
an HTML document without it ever being serialised. It's an abstract 
construct, which happens to be expressible in a variety of ways including 
some text serialisations.

The whole point of the language is the interpretation part, which, in the 
case of a serialised document, can only be done once the document has been 
parsed. No?


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

In what sense is there no DOM? The document is still a tree, it still has 
elements, they still have attributes.

What you are saying seems to me to be like saying that printed sheet music 
doesn't have music. That it is just a stave with a clef symbol, time 
signature, etc. That's clearly not true, sheet music represents music, and 
that music could be equally well represented as MIDI data. A 
"specification for music" would describe notes, pitch, rhythm, and so 
forth. It wouldn't talk about a stave except to describe one way to write 
the music down for interchange.

HTML is the music. The angle brackets and so forth are just one way to 
write the HTML down for interchange.


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

In what sense is the concept of a Document, Elements, attributes, etc, not 
relevant to all uses of HTML?


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

I don't know what you mean by "DOM-independent". A browsing context is an 
environment in which document objects are presented to the user. What is 
the problem with that definition?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 19 February 2009 01:26:15 UTC