Re: Renamed topic: focus and length of HTML5

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

Individual modules edited by multiple people would most likely take no
longer, and in fact, would take a shorter period of time then if one
person was editing. That's why companies have teams. Teams of people
do work. Teams collaborate on getting things done. With teams, not
only can people help each other, but you ensure the concerns and needs
of a broader community are met. That the work doesn't reflect just one
person's views.

Even as a writer, I'm part of a team. There are individuals that
determine whether there is a market for a book. I have a lead editor
who helps ensure my Table of Contents and outline touches all of the
important points of the topic. There are tech reviewers who ensure
that the material is correct (or as correct as possible), and then
copy editors who help me find all my typos. Then there's the
production staff.

So even an act as seemingly solitaire as writing a book is more of a
team effort than not. And the team helps ensure I meet my deadlines, I
finish the tasks, and they help me by freeing me from many aspects of
the book's production.

So, no, I completely disagree that it would take longer to have more
editors. More importantly, more editors ensures an essential
comprehensiveness.

As for tighter integration, I don't think I said that anything about
this. I believe that  a natural process of modularization is that
there are clean "hooks" for other applications, such as a published
API. With a specification, you work to ensure that your stuff doesn't
contradict other people's stuff, and that you don't put anything into
the spec that will break other specs. Again, this ensures that people
are given consistent specifications.

And I'm not sure that you have to do overmuch to integrate with either
CSS 2.1 or CSS 3.0. There are points of synchronization between the
two, but beyond that, CSS is from one domain, HTML is from another.
That CSS 3.0 introduces all new attributes and properties should
matter little in the HTML document. You don't have to repeat what's in
CSS in HTML.

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

I'm curious -- you've said multiple times that you really don't like
Microdata in the spec. I actually linked an email that said this. So
now, you do like having Microdata in the spec?

As for being defined in the same spec, because Microdata is based in
HTML, why? There are probably hundreds of thousands of examples of
libraries and extensions and modules that are based on a "language"
but are not part of the core. Why would HTML be different? HTML is a
markup language--nothing more, nothing less.

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

They aren't an integral part of the HTML specification. And to repeat,
we have hundreds of thousands of examples of modules, extensions, and
various other libraries that extend language functionality but are not
part of the core language.

You're seeing problems that don't exist.

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

I have to ask you to put on your application developer's hat and think
about what you would think if a person creating an application said,
"Oh, I can't use libraries, or other modules, or other people's
objects -- I have to create everything in this application, from
scratch, and all in one file". I believe you would be appalled at such
an attitude, or probably scathing of the resulting app.

Why then do we drop everything we know, everything we've been taught
as technologists--all of the good and best practices--just because
what we're creating is a specification rather than an application?

Everything that can apply to an application can also apply to a specification.

- You don't duplicate what's handled in other works

- You break the work up so that each piece is focused

- You ensure that your work covers what's needed, and no more

- You eliminate bloat

- Your work is clean, and well documented

- You work with others, so all the work can happen in parallel

- You provide tests for the work

- Above all, you make sure the work is what the community wants, not
what you want

I could go on, but you're a tech, you know what the rules of good
application development are. The rules for developing the
specification should be no less.

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

It should impact, because the closer we get to CR, the more others
implement the functionality. For instance dialog: you'd be surprised
at the number of articles and tutorials online that cover dialog. And
that's with the spec still only in first draft.

We should work to decrease confusion, not be blithely unaware of it.
The more drastic changes we make later in the process, the more
confusion we generate. We can add later, but we should be very wary of
dropping later.

I don't want this to seem like a personal attack, but your attitude
about dropping sections, as if there is no impact on doing so, is not
an attitude I would expect from an editor in a W3C working group.

Regardless, other yours is not the only opinion determining what is
added, or dropped. Hopefully other members of this group aren't as
blasé about dropping material later in the cycle.

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

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

I'm saying that knowing there were bugs and issues still open in a
database you partnered with. When we're ready to go to LC here, I
would hope that if there are bugs in the WhatWG database, that someone
has copied said bugs into the W3C bug database, so everything is
tracked in one place.

Regardless, the announcement caused confusion. We should do everything
in our power not to cause confusion.


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

No, I stand by this. A web page is made up of many parts, each of
which is defined in a different specification. CSS, HTML, ECMAScript,
even the protocols -- all working together to create a whole that
works, and is displayed as the web page.

All these specs don't have to be in the same document. The same as
applications don't have to consist of one single file.

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

HTML5 is HTML, an XML serialization, and the DOM. We should be focused
on HTML. This is not the Web Applications group. I wonder if perhaps
you're not happy being the editor of just HTML. Would you be happier
working more closely with the Web Apps group, and we could work on
finding new editors who are happy working on just HTML for this
group's efforts?

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

I'm saying that a good specification, like a good library, can be
created in such a way as to encourage innovation, rather than strangle
it.


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

Wow, I think you're extrapolating a lot. For one, I don't think CSS3
is a failure. Seems to me, there's a lot of CSS3 in many of the new
browsers. As for XHTML 2.0, I don't believe the topic size was the
primarily problem with that effort.

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

I listen to this and I think to myself, "My goodness, no wonder
there's only a thousand pages on the web."

There will always be decisions that were made that shouldn't have been
made, and bumps and hiccups along the way. We learn, and we work to do
better. But there will never be perfection, and there will always be
little gaps and imperfections as the specs all grow along their own
paths.

You can't work to ensure perfection by putting a stranglehold on
others efforts. You can't ensure perfection by attempting to grab
EVERYTHING and control it. That way stifles innovation. It handicaps
everything before it even starts.

I'd rather a bumpy road than a safe cage.


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

I repeat, I do not see broad implementations of HTML in user agents,
or in the community.

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

I think we need to stop trying to control everything.

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

Ah, OK. You have a good point here. Now I see where the response above
came from.

I think we should consider removing Microdata permanently. I agree with you.

Issue 76 is such a way that a proposal to remove Microdata permanently
doesn't really fit that topic. Perhaps I should write a bug asking
specifically for this.

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

Actually, this kind of counters what you wrote above.

But I agree, we should address just removing Microdata permanently.

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

I agree, but Issue 76 seemed to preclude writing a proposal to drop
Microdata entirely. I could be wrong.

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

Agree.

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

We have to disagree then. Material specific to only a subset of user
agents does not belong in the HTML 5 specification. And there are
other aspects, as I've written up in bugs.

Speaking of which, how are you doing with handing all of the bugs? Do
we need to consider adding another editor to help you with all the
bugs?

I'm not a chair, but it seems to me that there's a lot of work, and
only you. I imagine this can leave you overworked. At a minimum, it
definitely fails the beer truck test, another of the good practices
we've learned.

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

Shelley

Received on Saturday, 5 December 2009 14:44:43 UTC