Re: Renamed topic: focus and length of HTML5 was Re: ISSUE-76: Need feedback on splitting Microdata into separate specification

On Fri, Dec 4, 2009 at 8:57 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> 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.
>>>

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.

I wouldn't call that progress.

>>>
>>>> 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.

>>> 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.

>>>> 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.

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.


>>>
>>>> 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.
>>>

I don't think we're anywhere near close to being finished. I think all
we've done is manage to put off the really tough decisions and issues
until the end. Either in LC, or during formal objects for LC and CR.

The whole reason for the formal change proposal is we all knew that we
were going to have some really tough times ahead of us.

If the people who are "holding" things up are the ones seeking to get
some stuff redefined or removed, it's because you unilaterally made
the changes, typically, as happened with the Microdata section, before
discussing the changes with the group. Sure it's easy to make changes
when you're the one editor, but that doesn't mean the issue won't have
to be addressed by the community at large at some later time.

All you've done being the benevolent dictator, to use your term, is
push the discussions to the end, when it will most likely take five
times as long to resolve, then it would if we had addressed these
issues in the beginning.

You may not agree with me, but I think we'll find that we're no where
near finished. We're no where near LC.

>>>
>>>> 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. Heck, most of the community sees HTML5 as canvas,
geolocation, and oh, yeah, some web app stuff, and a couple of new
elements.

Rightfully so: HTML5 is a draft, not even at LC. Now is the time to
make changes, not after LC, or CR.

As for mailing list subscriptions, there are hundreds of people in
this group, and I see, on average, 10-20 participating actively. I
don't see all that many more in the WhatWG group. Anyone can subscribe
to an email list. It doesn't mean they're keeping up, or even all that
interested.

>>>
>>>> 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.

Now is exactly the time to consider removing it.


>>>
>>>> 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.

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.

There's a world of difference between dropping stuff now, then 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.

>>>   Or is it the group's opinion that the length of the specification
>>>   should be at most a secondary concern?
>>>

See above

>>> 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).
>>>

You asked the chairs, but I think a better approach is to depend on
our change process, as we have been.

>>> --
>>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL

Shelley

Received on Friday, 4 December 2009 15:59:38 UTC