Re: Renamed topic: focus and length of HTML5

On Fri, 4 Dec 2009, Julian Reschke wrote:
> > 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 
> > ...
> 
> He who defines what a milestone is...

I'm not sure to what you are referring here. I would have thought the 
milestone of "zero open issues" was a pretty uncontroversial milestone 
definition -- it's the same one we're using in this working group, no?


> > 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.
> 
> I guess it depends on the definition of "progress". If it means 
> "approving what the editor wants", then yes, the HTML WG isn't as good 
> in it as the WHAT WG.

Actually, most of the things I disagree with in HTML5 were the result of 
discussions on the WHATWG list. So your characterisation is incorrect.


> > > 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.
> 
> You mentioned a lot of specs that are separate from HTML5. So this seems 
> to support the point that modularity is good.

That the specs exist is not a point in support of modularisation or a 
point against it. In fact there is also a spec that exists that has many 
of those specs in one document. By your logic that would support the point 
that modularity is bad, which is a contradiction (since both exist).


> > > 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. ...
> 
> Increasing the number of specs doesn't necessarily mean that the number 
> of specs *you* edit need to increase. (and yes, we had that discussion 
> before)

I wasn't implying that I would edit them. From the point of view of 
editing _any_ specification, having more smaller specifications that 
interact with it would make the editing take longer. For instance, it is 
easier for me to write specifications that interact with CSS2.1 than CSS3 
modules. Since you bring it up, though, it's worth noting that Shelley's 
concern (that the spec would take longer) is made even worse if the 
individual modules are edited by multiple people, especially when the 
modules are as tightly integrated as the modules she is suggesting would 
need to be.


> > > 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.
> 
> Sorry, that doesn't make any sense at all.
> 
> First of all, microdata is truly optional; it's not part of HTML4, and 
> it's not in actual use except in experiments.

Sure, it's optional in the same sense that <section> is optional, or in 
the same sense that <img> is optional. However, that doesn't mean we 
should put them in separate specifications -- if they're part of the 
language at all, then they should be defined in the same language 
specification.


> How can you say "it's part of the language" then? Unless you mean "it's 
> in the spec, so by definition it is part of it".

I mean "it's part of the language", in the same was that <ruby> was part 
of XHTML, despite being defined in a different document. Microdata adds 
elements, attributes, and DOM APIs that are an integral part of text/html 
documents. Defining parts of the language in different documents leads to 
a fragmented language with an incoherent design (a problem we've seen all 
too often in HTML's history for exactly this reason).


> If we'd buy that argument we'd have to re-open lots of discussions about 
> other features such as RDFa, @profile, whatnot.

Yes, all of those should be in HTML5 if we think they should exist at all.


> > > 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.
> 
> One difference is that these were removed *before* LC.

IMHO this is not a relevant difference. I have been editor of several 
specifications that have gotten to LC or even CR and still had huge 
sections removed. I've also been part of several efforts (including HTML5 
itself) that have dropped entire sections after those sections have 
reached REC. I do not think that the status of the document in the W3C 
process would have any effect on our ability to drop the sections.

(Other factors would; e.g. whether or not implementations exist.)


On Fri, 4 Dec 2009, Shelley Powers wrote:
> On Fri, Dec 4, 2009 at 8:46 AM, Ian Hickson <ian@hixie.ch> wrote:
> > 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 technology 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.
> 
> Yes, but the WhatWG group went to last call when there was still issues 
> and bugs pending in the W3C bug database and issues tracker.

Are you saying that the W3C HTML WG should wait for WHATWG process issues 
to be addressed, if the situation was reversed?


> >> 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?
> 
> No fancy stuff with words here, dictionary definitions will do.

"integrate" means "combining parts so that they become a whole", which 
seems to be the opposite of what you are requesting, so I still don't 
understand what you mean.

"focused" means "concentrating interest or activity on something", which 
we have done successfully for many years on HTML5 (the "something" being 
improving the state of the Web technology stack for the purposes of 
writing Web Applications).

So by the dictionary definitions, I agree that "It's easier to integrate 
the specification with other specifications, if it's focused", and I 
further would argue that that is exactly what I am suggesting: that we 
have a single integrated specification for everything we are focused on.


> > 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.
> 
> That's today. I'm talking about tomorrow, or the next year.

So you are arguing that we should change the spec to address a problem 
that you admit we are not currently having, and may not in fact have for a 
year? If so, then I think it would be a better use of our time to wait 
until we had some idea what the problem looked like before trying to 
address it. What if the problem turns out to be that the spec is too 
short? (I think that makes about as much sense as being worried that it 
might one day be too long.)


> >> 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).
> 
> I think you misunderstood my use of modularization. When I'm talking
> about modularized, I'm talking about focused specifications that limit
> scope to specific areas of interest. Perhaps another word would have
> been better, sorry.

If you meant that they should be focused on small topics, rather than 
large topics, then my argument above still holds. Specifications focused 
on small topics taken as part of a group of specifications that cover a 
larger topic have historically in the W3C been significantly less 
successful than "monolithic" specifications focused on the larger topic as 
a whole. CSS3 vs CSS2, and the XHTML Modularisation specifications vs 
XHTML1.0, are good examples of this. I'm not aware of any examples where 
the opposite is true (where a specification focused on a small topic that 
is part of a group of specifications that cover a larger topic has been 
more successful than its monolithic counterpart).


> To me, the fact that HTML was separate from the DOM was separate from 
> the CSS and SVG and so on, meant that these specifications could 
> progress at their own rate, but there is a good degree of integration 
> between the specs.

The fact that SVG and CSS were separate from each other led to a long set 
of problems that we are _still_ dealing with. Similarly, separating HTML 
and the DOM and CSS and the DOM led to such a complicated set of issues 
that we are still now, more than a decade later, trying to fix the mess. 
Separating SVG and HTML led to the pain felt in this very working group 
earlier this year and last year in trying to reintegrate them, and will 
lead to decades of ripple effects as the resulting integration affects 
every HTML parser from here on out, and every Web author that tries to 
use SVG and HTML in the same page.

So no, I strongly, strongly disagree. I think the examples you picked in 
fact could not more strongly disprove your point.


> >> 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.)
> 
> I don't see broad implementation of HTML5 in user agents or the 
> community.

Then, with all due respect, you're not looking.

   http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers
   http://a.deveria.com/caniuse/#agents=All&eras=All&cats=HTML5&statuses=rec,cr,wd,ietf
   http://html5gallery.com/


> >> 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.
> 
> Microdata has not been implemented as part of HTML4, or by any browser 
> that I know of. I don't think any but a few have implemented in their 
> sites.

The same applies to many other features of HTML5 -- should we put them in 
their own spec too? Should we put everything that isn't in HTML4 in a 
separate spec than HTML5? This seems to be a non-tenable position that 
would lead to a highly fragmented, and not very useful, set of documents.


> Now is exactly the time to consider removing it.

Now is a time to consider removing it entirely (it's always that time, for 
that matter), but it doesn't make sense to put it in a separate spec.


> >> 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.
> 
> Not after LC or CR. Once HTML5 hits the streets, it is going to be 
> extremely difficult to remove features.

It's difficult to remove _implemented_ features regardless of what stage 
in the process we are at. However, splitting microdata into a separate 
specification (the decision that is before us) does nothing to change 
that.

It sounds like you think the proposal before us is to drop microdata 
entirely. That is not Manu's proposal. The only two proposals before us at 
the moment are keeping Microdata in HTML5, and putting Microdata in a 
separate document. Neither of those changes would make any difference to 
implementations (other than making implementations a bit harder to get 
right, in the case of splitting the specification out, due to requiring a 
lot of cross-referencing).


> You, yourself, have stated in many emails how you don't like supporting 
> one thing or another, but to remove support would "break" the web.

That is in reference to supported features, and has no bearing on whether 
a feature is in one spec or another. We could (with great effort) take out 
many features of HTML5 and put them in other documents. That would not 
break the Web, since they would still be defined.


> There's a world of difference between dropping stuff now, then a year 
> from now.

We are not discussing dropping microdata now.

Whether microdata is in the same spec or a different spec will make no 
difference to how easy it is to drop a year from now.


> > 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?
> 
> I never said anything about length per se, but about the spec being too 
> big because it's unfocused, and includes components that have little or 
> nothing to do with the fundamental components of an HTML spec: HTML, an 
> XHTML serialization, and the DOM.
> 
> A spec can be thousands of pages long, and still relevant if it's 
> tightly focused on its core topic. Another spec can be only a hundred 
> pages long, but hopelessly compromised, because it doesn't know its 
> audience, its function, or its topic.
> 
> The size in pages has little to do with anything. Well, other than some 
> of the HTML5 related publications cause browsers to fail.

I disagree with the premise that there are parts of HTML5 remaining that 
have nothing to do with HTML, its serialisations, and its DOM APIs. 
Certainly, the microdata section is an integral part of the HTML language 
and its APIs, and so the argument above at a minimum doesn't apply to this 
thread, even if it turns out there are parts to which it does apply.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'