Re: An HTML language specification

On Tue, Nov 18, 2008 at 4:10 PM, Ian Hickson <ian@hixie.ch> wrote:
>> 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.

Depends what you mean by "orthogonal" here.  I agree that there are
complex interactions between the various components in play.  I just
don't agree that this means that they can't be specified
independently.  I *do* agree that it would be more work than
specifying them together though, because simplification always takes
effort.

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

I agree that's complex, but I don't see why script needs to be any
more carefully defined than "This element encapsulates a script of the
type defined by its type/language attribute".  Inside the DOM spec,
and/or browsing context spec, or wherever, the complexities of that
state machine you describe can be laid out in excruciating detail.

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

Again, I agree that is a complex interaction that needs to be
specified carefully.  But as with the previous example, I don't
understand why that necessitates defining the meaning of those
attributes in terms of the DOM.

Mark.

Received on Thursday, 20 November 2008 15:18:54 UTC