- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 4 Dec 2009 14:46:25 +0000 (UTC)
- To: Shelley Powers <shelley.just@gmail.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, public-html <public-html@w3.org>
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:47:01 UTC