- From: Shelley Powers <shelley.just@gmail.com>
- Date: Fri, 4 Dec 2009 08:54:06 -0600
- To: Ian Hickson <ian@hixie.ch>
- Cc: Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, public-html <public-html@w3.org>
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