HTML Modularisation

On Thursday, Robin and I presented to the AC on HTML Modularity.  The 
slides are available here:

Robin presented the slides, then I added commentary based on feedback 
that these topics had received during the course of TPAC.  The very 
first question was that I should post that feedback "someplace", and I 
am now doing so.


I noted that I had heard a lone voice questioning the Extensible Web 
Manifesto, but no arguments against greater inclusiveness or greater 

There are questions as to how git + pull requests will work, and at this 
point it is best described as a work in progress.  We will learn as we go.

This prompted questions about tracking IP.  The most that we could 
commit to at this time is preparing reports.  We also noted that the 
ability to produce reports would be a step forward over the current 
situation where there is little or no traceability between contributions 
made via the mailing list and changes to the specification.

There clearly are voices for "bleeding edge only".  I've heard nobody 
advocate "stable releases only".  I'd describe a position of "regular 
releases and making the bleeding edge publicly available" as enjoying a 
comfortable majority.

Everybody agrees that it is hard, it is work, and that it is useful and 

A comment on the contrast to XHTML modularization: a goal of XHTML 
modularization was to enable an "a la carte" model where mobile vendors 
could pick and chose what features they would support.  That would not 
be the case here: the goal would remain "one web".  If (hypothetically) 
<form> support were to be split out into a separate specification, it 
would be normative referenced and not optional.

- Sam Ruby

Received on Saturday, 1 November 2014 20:59:17 UTC