- From: Shelley Powers <shelley.just@gmail.com>
- Date: Sun, 10 Jan 2010 19:36:41 -0600
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Cc: Larry Masinter <masinter@adobe.com>, "public-html@w3.org" <public-html@w3.org>
On Sun, Jan 10, 2010 at 2:16 PM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote: > Larry Masinter wrote: >> >> The problem is not that HTML5 is described in a single spec, >> the problem is that the WhatWG design for the Web Hypertext >> Application Platform is not modular enough. Taking a monolithic >> design and hacking the specification into pieces doesn't help >> address the design problem, unless the split into separate >> specifications is used as an opportunity to remove >> interdependencies so that each element of the design can >> be read, understood, and implemented independently, and >> evolved asynchronously -- on their own schedules and >> development timelines, and likely in separate groups >> with focused expertise. >> >> It may well be that there are implementation considerations >> that cross modularity boundaries, but those should be >> exceptions, and would best be placed in an implementor's >> guide, not threaded ad hoc into multiple specifications. > > From my past experience doing QA within Opera for our implemetation of > various parts of the spec, it is significantly easier to have the spec > define both how something is to be used and how it is to be implemented in > the same spec. If these details were somehow split between an authoring > spec and an implementer spec as you seem to be suggesting, my job would be > made significantly more difficult by making it harder to understand how > things are supposed to work, since there would inherently be a lot of cross > references between the 2 specs, no matter what. > > Even when Web Databases was split from the main spec, it made things more > difficult due to the necessary amount of references to things still defined > in the main HTML5 spec (mostly pertaining to Window, Origin and Event Loops > stuff). This split was done well before the availability of the complete > version of the Web Applications 1.0 spec at the WHATWG, so I just had to > accept it. (Though, at least now it is available, I'm largely insulated > from the impact of further unnecessary and unwanted spec splits if this > group still decides to go ahead with them regardless, including the recent > microdata split). > > So I believe calls for further spec splits would be much better served by > instead more carefully reogranising the single spec and dividing it into > multiple pages, appropriately. In practice, any purported benefit gained by > splitting and publishing some section of the spec separately would be > equally gained by publishing that exact same section on its own page within > the multi-page spec, and it doesn't suffer any of the negative consequences > of an actual split. > I think the issue is less to do with splits for the sake of breaking up a large document, though that can be an incentive. A large document without a clearly audience (or audiences) and topic is going to be more vulnerable to misunderstanding, more intimidating to all those impacted, more difficult to maintain, as well as overly constraining--especially when it absorbs functionality that isn't specific to HTML (XHTML or the DOM). The concern is more about scope, consistency, maintainability, readability, and usability. In particular, components that can be used by specs other than HTML, should be accessible directly. And other components that aren't tested, and may fail, should not be included. I don't think we need to stop work, though, because of the possibility of splits. If there are bugs/issues that could result in splits, I think the best approach is to take each one at a time. I am concerned, though, about the fact, as you mentioned in your email, that the WhatWG HTML document has changed its name to WhatWG HTML, and that it includes items split out from the HTML5 specification. In fact, if elements such as details, progress, and meter are actually deleted (not split off), there will be potential variances now between the two documents. This is not a good idea. This is not a sound technical decision. > -- > Lachlan Hunt - Opera Software Shelley > http://lachy.id.au/ > http://www.opera.com/ > >
Received on Monday, 11 January 2010 01:37:14 UTC