Re: An HTML language specification

On Mon, Nov 17, 2008 at 5:24 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Mon, 17 Nov 2008, Mark Baker wrote:
>>
>> For a markup language, it defines the meaning of the elements and
>> attributes, and their composition.  e.g. it defines what "img" means,
>> and how "alt" affects that meaning.
>
> 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.

>> > Presumably you intend this set of sections to indicate a desire to
>> > exclude the DOM APIs from the language, but wouldn't that mean that
>> > SVG was also not a language specification? What makes SVG a language
>> > specification when HTML5 is not?
>>
>> Yes, I forgot SVG included a DOM, so shouldn't have mentioned it.
>
> So two of the most important specifications that the W3C is producing
> aren't what you think should be produced?

They're producing something which could have been produced in a
superior form, yes.

>> And just to be clear, both the current HTML 5 and SVG specs do include a
>> specification for a language.  They just also include a lot of other
>> stuff which isn't required for a language specification.
>
> But it _is_ required for a _useful_ specification. Which is far more
> important.

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

>> I can certainly see ample complexity in the interaction of DOM and
>> scripts/objects, but can't see how the declarative aspects would enter
>> into that complexity.
>
> 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?

I skimmed through WF2 forms and certainly saw that a lot of
declarative features are defined in terms of the DOM, e.g. "output",
but that just seems an editorial convenience - or perhaps more
accurately, that as Web & former browser developer, you're just
reusing a tool that you're very familiar with.  I see no reason why it
couldn't be defined completely independently of the DOM.

>> > One of the biggest goals of HTML5 is to fix up the mess that was left
>> > from leaving things like Window and the navigation algorithm
>> > undefined. These are core to how HTML works. We can't leave those out.
>>
>> IMO, those are not core to how HTML works, they are core to how HTML
>> with scripts is processed by browsers, which is a very different thing.
>
> Ok.
>
>
> 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.

Mark.

Received on Tuesday, 18 November 2008 15:12:18 UTC