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

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

From: Shelley Powers <shelley.just@gmail.com>
Date: Fri, 4 Dec 2009 08:57:29 -0600
Message-ID: <643cc0270912040657r57779b57p1bbf4a1a722aca06@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, public-html <public-html@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>
Sorry, Paul, missed you on the first email. Ian addressed this to the chairs.


On Fri, Dec 4, 2009 at 8:54 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> 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:58:05 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:04 UTC