W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: Renamed topic: focus and length of HTML5

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 05 Dec 2009 13:57:41 +0100
Message-ID: <4B1A58C5.4090603@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: Shelley Powers <shelley.just@gmail.com>, public-html <public-html@w3.org>
Ian Hickson wrote:
>>> Even if we grant for the of argument the premise that it is not, it is 
>>> still the case that the WHATWG has reached a later milestone than the 
>>> ...
>> He who defines what a milestone is...
> I'm not sure to what you are referring here. I would have thought the 
> milestone of "zero open issues" was a pretty uncontroversial milestone 
> definition -- it's the same one we're using in this working group, no?

I simply don't think "no open WHATWG issues" is a significant milestone, 
when we have several other bug trackers containing open issues.

> ...
>>> HTML5 and a number of other specs (XHR, Origin RFC, Sniffing RFC, Web 
>>> Sockets, CSSOM, CSSOM Views, Web Storage, etc) are working closely 
>>> together as it stands today. It doesn't seem to have been a problem.
>> You mentioned a lot of specs that are separate from HTML5. So this seems 
>> to support the point that modularity is good.
> That the specs exist is not a point in support of modularisation or a 
> point against it. In fact there is also a spec that exists that has many 
> of those specs in one document. By your logic that would support the point 
> that modularity is bad, which is a contradiction (since both exist).

The existence of a document that combines the contents from a set of 
smaller documents doesn't prove anything.

> ...
> I wasn't implying that I would edit them. From the point of view of 
> editing _any_ specification, having more smaller specifications that 
> interact with it would make the editing take longer. For instance, it is 
> easier for me to write specifications that interact with CSS2.1 than CSS3 
> modules. Since you bring it up, though, it's worth noting that Shelley's 

And that's why? In addition to the fact that you need a longer table of 
document references?

> ...
>>>> Microdata doesn't need to be in the spec [...]
>>> Microdata "needs" to be part of HTML5 because it is part of the 
>>> language. Taking Microdata out of HTML5 makes about as much sense as 
>>> taking out <h1>, <p>, or title="", IMHO.
>> Sorry, that doesn't make any sense at all.
>> First of all, microdata is truly optional; it's not part of HTML4, and 
>> it's not in actual use except in experiments.
> Sure, it's optional in the same sense that <section> is optional, or in 
> the same sense that <img> is optional. However, that doesn't mean we 
> should put them in separate specifications -- if they're part of the 
> language at all, then they should be defined in the same language 
> specification.

If we didn't have consensus for <section>, then yes, the best thing 
would be to remove it and develop a spec separately.

<img> is in wide use and uncontroversial, so I don't see the connection.

microdata has no significant deployment, is controversial, and competes 
with another W3C technology, so the situation simply is different.

>> How can you say "it's part of the language" then? Unless you mean "it's 
>> in the spec, so by definition it is part of it".
> I mean "it's part of the language", in the same was that <ruby> was part 
> of XHTML, despite being defined in a different document. Microdata adds 

Is it?

> elements, attributes, and DOM APIs that are an integral part of text/html 
> documents. Defining parts of the language in different documents leads to 
> a fragmented language with an incoherent design (a problem we've seen all 
> too often in HTML's history for exactly this reason).

Defining a language with clear extension points helps developing specs 
at different speeds, and helps adding stuff later.

It appears there's fundamental disagreement about whether modular is 
good or bad, and whether allowing other groups to extend the language is 
good or bad. I don't think that any additional discussion over here will 
change that.

>> If we'd buy that argument we'd have to re-open lots of discussions about 
>> other features such as RDFa, @profile, whatnot.
> Yes, all of those should be in HTML5 if we think they should exist at all.

OK, in that case I'll probably have to change my position on several of 
these issues :-)

> ...
> IMHO this is not a relevant difference. I have been editor of several 
> specifications that have gotten to LC or even CR and still had huge 
> sections removed. I've also been part of several efforts (including HTML5 
> itself) that have dropped entire sections after those sections have 
> reached REC. I do not think that the status of the document in the W3C 
> process would have any effect on our ability to drop the sections.
> (Other factors would; e.g. whether or not implementations exist.)
> ...

So a much less controversial way to do this would be to develop a 
feature like this as a separate spec, and then *potentially* consider 
integration once it has succeeded in practice.

The only reason why Microdata is in the spec right now is because you 
made that choice, and had the editorial power to do so.

 > ...

Best regards, Julian
Received on Saturday, 5 December 2009 12:58:33 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:54 UTC