Renamed topic: focus and length of HTML5 was Re: ISSUE-76: Need feedback on splitting Microdata into separate specification

Just putting this into the proper thread.

On Fri, Dec 4, 2009 at 8:46 AM, Ian Hickson <ian@hixie.ch> wrote:
>
> There are some points here that I strongly disagree with and that I think
> are pretty fundamental to many of the decisions that the working group
> will need to make in the coming weeks and months, so I think it might be
> worth putting these issues as a meta question to the group, to give me
> guidance (as one of the editors of specs that this working group is
> publishing) on what kind of policy I should be following.
>
>
> On Fri, 4 Dec 2009, Shelley Powers wrote:
>>
>> It's easier to get a specification cleanly finished when its focused on
>> the technology it's supposed to be focused on.
>
> HTML5 _is_ focused on the technologu it's supposed to be focused on.
>
> 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
> HTMLWG, despite the "lack of focus" you infer. Therefore it seems to be
> untrue that the current development model will prevent progress: it is in
> fact arguably the requests that the specification be more "focused" that
> are, in part, preventing that same progress in this working group.
>
>
>> It's easier to integrate the specification with other specifications, if
>> it's focused.
>
> What do you mean by "integrate" and "focused" in this context?
>
> 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.
>
>
>> Just the same as applications are cleaner, and better when they're based
>> on modularization.
>
> I do not think this statement is a truism.
>
> For specs in particular, I'd go as far as saying that it's flat-out wrong.
> Modular specifications have historically in the W3C been significantly
> less successful than "monolithic" specifications. Consider CSS3 vs CSS2,
> or the XHTML Modularisation specifications vs XHTML1.0. I'm not aware of
> any examples where the opposite is true (where a modularised set of specs
> has been more successful than its monolithic counterpart).
>
>
>> When you open the door to everything under the sun, the spec will never
>> be finished.
>
> Ironically, again, the spec is closer to being finished in the working
> group that does not espouse the position you are advocating. Certainly
> from an editing perspective having more smaller specifications is more
> costly to my productivity than having one single specification.
>
>
>> More than that, it will always have problems getting accepted by the
>> wider community.
>
> HTML5 is having no trouble getting accepted by the wider community. In
> terms of acceptance by the wider Web authoring community, and in terms of
> acceptance by user agent vendors, it is one of the most successful
> specifications the W3C has published in the past five years. In fact the
> main communities with which it has been finding trouble getting acceptance
> are the much smaller standards committee communities such as the TAG and
> PFWG, not the wider community at all. (Smaller in terms of raw numbers,
> compared to the the WHATWG mailing list subscription count, at any rate.)
>
>
>> 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.
>
>
>> What's another thing we know from application development? It's easier
>> to add at a later time, then it is to remove.
>
> This indicates a lack of familiarity with HTML5's development over the
> past few years. We have dropped numerous sections with far less effort
> than they took to be written. Repetition templates, <datagrid>, form
> prefilling, space-separate form="", peer-to-peer TCPConnection, the
> <eventsource> element, <datatemplate>, <font>, the entire "out of scope"
> section, several introduction sections... Not to mention the numerous
> sections that were split into other specs, such as XMLHttpRequest, Web
> Storage, Web Database, Web Workers, Web Sockets API, Web Sockets protocol,
> the Server-sent Events API, Content-Type sniffing, and URL parsing.
>
> No, if there's one thing we _do_ know about HTML5, it's that we've had no
> trouble dropping features. In fact the _only_ exceptions I know about are
> the ones that you mentioned, and the only reason we've had trouble
> dropping them is that you and others have objected to dropping them
> (summary="", for example). I presume that wouldn't apply here, since you
> are specifically _asking_ that we drop them.
>
>
> To return to the point I was making at the top of this e-mail: IMHO, the
> issue boils down to this:
>
>   Is it the group's opinion that specification length should be one of
>   the working group's primary concerns?
>
>   Or is it the group's opinion that the length of the specification
>   should be at most a secondary concern?
>
> Could I ask the chairs to consider putting this question to the working
> group? If we have a strong concensus one way or the other, we could save a
> lot of time (for example, if the working group thinks many small specs is
> better than one spec, independent of the content of the specs, then I
> should just split the spec up into smaller parts now, and save us the
> trouble of fighting over each subpart in turn over the next few months).
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Friday, 4 December 2009 14:54:40 UTC