- From: Shelley Powers <shelley.just@gmail.com>
- Date: Fri, 4 Dec 2009 08:57:29 -0600
- 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. Shelley 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