Re: An HTML language specification

On Tue, 18 Nov 2008, Mark Baker wrote:
> >
> > IMHO this is a dated definition of the term "language". A language 
> > today must include its APIs. Relegating APIs to a second class citizen 
> > status leads to the kind of mess that we have with HTML4+DOM2HTML, and 
> > prevents features like <video> or <eventsource> from being developed.
> 
> You've made the claim that it's difficult to separate the concerns of 
> declarative and imperative programming within browsers, and if that is 
> in fact the case then this would provide evidence for your belief that 
> HTML 5 needs all the features it has.  But you haven't made that case 
> yet, so I'm not ready to accept your re-definition of the word 
> "language", not even for HTML.

The declarative vocabulary and the dynamic API are not orthogonal -- they 
have direct impact on each other. For example, should <video> have a 
start="" and end="" attribute, or should we use a currentTime DOM 
attribute for seeking and the addCueRange() API for pausing?

These decisisons aren't orthogonal.


> A Web browser requires dozens of other specifications be used but that 
> doesn't mean that combining them all into an "uber spec" would be 
> useful, nor does it mean that these specs are not useful on their own.
> We should always try to produce orthogonal protocol specifications
> because no matter how they're specified, they *will* evolve at their
> own pace whether we like it or not.

Sure, and where possible the orthogonal parts are defined in separate 
specs. For example, we don't merge HTTP into HTML5, but we do have the 
definition of how you navigate a browsing context, since that is deeply 
related to how the language works.

Another example of how the vocabulary and DOM parts aren't orthogonal:

We have to define how <script> executes in script-aware UAs when the 
document is parsed, but the execution is also triggered by DOM 
manipulation creating the element and inserting it into the DOM. This then 
can trigger document.write(), which means that the vocabulary needs to 
define how it interacts with the .write() API. The .write() API can then 
trigger the parser, which can restart the whole loop. Or it can trigger 
document.open(), which can cause a navigation of the browsing context, 
thus requiring <script> and the browsing context to be carefully defined.

If we were inventing a language from scratch, then sure, it would be nice 
and easy to make things orthogonal. But we're not. We're specifying 18 
years of features that have grown organically without much guidance from 
the W3C (e.g. this is the first spec to define the Window object).


> The alternative is essentially a "profile" that snapshots the state of 
> the art at some point in time, but will require updating far more 
> frequently than would its constituent protocols had they been defined 
> independently.

A real spec needs continuous updating anyway, as bugs are found. If you 
don't keep updating the spec you end up with something like HTML4, or DOM2 
Core, or HTTP, all of which have many areas where the browser vendors have 
stated categorically that they'll never be able to implement the spec as 
written (e.g. the default value of media=""; getAttribute() on missing 
attributes; the Content-Base header).

We have to keep updating documents, like the CSSWG updates CSS2.1. Web 
specs have to be living documents if they are to be useful at all.


> > Just look at the definition of the form controls for instance. There's 
> > a tighter relationship between the declarative features and the 
> > dynamic features than between the declarative features and the syntax.
> 
> I'm not sure what you're referring to.  Can you point to an example?

Sure. The value="" attribute on the <input type="text"> element represents 
the initial value. When you click a <button type="reset">, the UA has to 
reset the <input> element to its original value="". That's all very well, 
but what events are to be fired when that happens? What if a script 
changes the value="" attribute? Does that change the displayed value or 
just the default value? What happens if a script dynamically changes the 
type="" attribute of the <input>? or the <button>?

These things all interact. They aren't orthogonal. And the above problems 
occur regardless of whether this is HTML or XHTML (i.e. their relationship 
to the vocabulary is closer than the syntax's).


> > At this point I don't really understand what you want. We're not 
> > changing the spec to remove the DOM parts, or splitting the spec into 
> > two along these lines, leastways not while I'm the editor. They are 
> > amongst the more critical parts of the language.
> 
> Well, I think that's the best way forward.

Thank you for your feedback.

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

Received on Tuesday, 18 November 2008 21:10:44 UTC