W3C home > Mailing lists > Public > public-html@w3.org > November 2008

Re: Should we Publish a Language Specification?

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 24 Nov 2008 23:27:56 +0100
Message-ID: <492B2A6C.4060806@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: "public-html@w3.org" <public-html@w3.org>

Ian Hickson wrote:
>> It makes sense for the *set* of specifications defining it to treat it 
>> as such. That doesn't imply it necessarily needs to be a single spec.
> Then by the same argument, the argument you were making (that features 
> should be in or out based on whether they are part of a document mmarkup 
> language) similarly doesn't imply that the spec necessarily needs to be 
> more than a single spec.

Not sure what exact point you're trying to make.

Of course good structuring of a single spec can help as well, but I 
think the ability to progress several specs at different speeds, or to 
revise them independently, is something you won't get with a single 

>>>> I think the state of the web really doesn't affect that distinction, 
>>>> and it's still a useful distinction to have.
>>> I disagree. Is the HTML5 spec a document or an application?
>> <http://www.w3.org/TR/2008/WD-html5-20080610/single-page/> appears to be 
>> a document to me.
> And this is an application?:
>    http://www.whatwg.org/specs/web-apps/current-work/

Assuming it contains scripts that are *needed* to use it: no.

If they are truly optional: perhaps.

>>> You didn't reply to my question. How do you draw the line between 
>>> "document" and "application"?
>> I've stated several times that I do agree that where to draw the line 
>> exactly is tricky, and that different people will have different 
>> preferences. That doesn't man that it doesn't make sense to draw the 
>> line somewhere.
>> Without having thought about it a lot, I would expect a document not to 
>> require anything that wouldn't "work" when served from the local file 
>> system, with scripting in the UA being disabled.
> "work" how, in a Web browser? Do you mean indistinguishable behavior when 
> compared to serving the same files to the same browser using http: with 
> scripting enabled instead of file: with scripting disabled?


> So is your proposal that we have one specification A that defines features 
> that would work the same in a Web browser when served over file: with 
> scripting disabled as when served over http: with scripting enabled, and 
> one specification B for everything else? 

Potentially. At least that is a line that could be drawn that came to 
mind first.

> So for example would you want your A spec to include the definition of the 
> browsing context, and the navigation algorithm, and the bulk of the 
> parser, as well as the form controls, but your B spec to include the 
> Window object, small parts of the parser that change under scripting, the 
> DOM parts of elements, and form submission?

I'm not sure why A would need to define those (for instance, it would 
need to define just serializations that are valid, but not handling of 
invalid documents).

> ...

BR, Julian
Received on Monday, 24 November 2008 22:28:39 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:39 UTC