- From: Mark Baker <distobj@acm.org>
- Date: Thu, 20 Nov 2008 16:19:40 -0500
- To: "Boris Zbarsky" <bzbarsky@mit.edu>
- Cc: public-html@w3.org
On Thu, Nov 20, 2008 at 11:30 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: >>> How do you want the language to be defined? >> >> Declaratively, in prose. > > Still trying to understand the exact meaning people are putting into their > terms here. Would the text below satisfy the "declaratively, in prose" > criterion? > > ----------------------------------------------------------------------- > 4.10.6 The select element > > Categories > Phrasing content. > Interactive content. > Listed, labelable, submittable, and resettable form-associated > element. > Contexts in which this element may be used: > Where phrasing content is expected. > Content model: > Zero or more option or optgroup elements. > Element-specific attributes: > autofocus > disabled > form > multiple > name > size > > [definition of the DOM interface, definitions of what the element-specific > attributes mean, and definitions of what the behavior of the DOM interface > is skipped] It would need to include the definition of the attributes, but most importantly a definition of what "select" means, like HTML 4 provides; "The SELECT element creates a menu". But sure, something like that. > ------------------------------------------------------------------------ > > This seems pretty darn declarative to me (and a lot clearer and more useful > than HTML4 ever was, I should note). Is the objection to the fact that the > DOM interface for <select> is defined right here next to the markup > behavior? No. As I mentioned to Maciej, *where* the DOM stuff goes isn't as important to me as decoupling the definition of the language from it. > Or is the objection just to the way the parsing algorithm is specified and > not to the descriptions of individual elements? It's both, to an extent. The parser and much of the language is defined in DOM terms. I haven't had a detailed enough look at the parser to know if the DOM gets in the way though, or if it can simply be used as an abstract model as the spec says ("Implementations that do not support scripting do not have to actually create a DOM Document object, but the DOM tree in such cases is still used as the model for the rest of the specification."). As somebody pointed out, html5lib doesn't have a DOM, so that's an argument that it's possible. But I'm still wary of using an implemented model as an abstract one, lest nuances of the various implementations result in differing interpretations of the specification. Mark.
Received on Thursday, 20 November 2008 21:20:18 UTC