Re: Renamed topic: focus and length of HTML5

On Sat, Dec 5, 2009 at 11:14 PM, Ian Hickson <ian@hixie.ch> wrote:
>
> On Sat, 5 Dec 2009, Shelley Powers wrote:
>> >>
>> >> 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.
>
> Great, I'm glad you agree.
>
> Does that mean you no longer support Manu's proposal?
>

No, I do support it. Once Maciej explained that splitting Microdata
off from the spec is equivalent to just dropping it altogether--that
those of us wanting it split out aren't encumbered with having to
create and maintain the separate spec--I felt that his answer
addressed your concern of a separate Microdata specification.

You don't like Microdata, you don't agree with having it at all, so if
the original author doesn't like Microdata, and the support from
others is lukewarm, at best, because I don't see any folk volunteering
to maintain a separate draft of it if it is split, then it's time to
pull it out of HTML5.


>
> On Sat, 5 Dec 2009, Shelley Powers wrote:
>>
>> 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.
>
> This is academic, since we don't have more editors. There are literally
> dozens of specs that are just lingering with no editors right now. If we
> had editors, there are far more important and more useful things they
> could do than edit documents that already have editors.
>

I'm not quite sure what question you're answering here, or what
comment you're responding to. My point is that multiple specifications
with multiple editors won't take longer than having one editor do it
all.


>
>> 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.
>
> It sounds quite similar to HTML5's development. HTML5 had been developed
> by literally hundreds of people -- just see the acknowledgements.
>

No, that is not the same thing.


>
>> So, no, I completely disagree that it would take longer to have more
>> editors.
>
> I didn't say it would take longer to have more editors. I said it would
> take longer -- does take longer, today, in practice -- when specs are
> divided into small modules instead of having a one document per focus
> area. One document for the language layer (HTML/SVG/MathML/DOM), one
> document for the network layer (HTTP), one document for the styling layer
> (CSS/CSSOM/XBL), etc. We'll never get to the level I'd like, but we can
> get close, e.g. by splitting the language layer into four documents giving
> the vocabulary and APIs for HTML, SVG, MathML, and one for the common
> syntax (XML). Similarly, CSS and XBL can be split. But I think it would be
> a terrible mistake to further subdivide -- splitting HTML into smaller
> bits would cause problems just like splitting CSS into smaller bits has
> caused problems. It _does_ take longer when the specs are split up. This
> isn't theoretical, it's going on right now.
>

That makes no sense. You're arguing for a practice that has
demonstrated itself to be grossly ineffective in our distant past. In
fact you're arguing against current established practices in
technology. We have learned that it's better to create focused
deliverables than create monolithic works that attempt to solve
everything.

Your four (three?) documents wouldn't have a clear cut by audience, by
interest, by topic--I am very surprised to read what you just wrote.

Regardless, we have a change proposal in place. If those of us who
would like a cleaner HTML document file bugs, and then file proposals
with a good rationale for the split, and there is agreement with the
rationale, the split will happen. If you're still the only editor, you
will have to remove the section from the document: you have agreed to
abide by this group's decisions.

The point then will be: you'll need to provide counter-proposals and
rationales for your reason why the split shouldn't occur.

You didn't provide a change proposal with Microdata, which I'm
assuming means you want it dropped. I think this is an important fact
in the Microdata counter-proposal discussion.

>
>> More importantly, more editors ensures an essential comprehensiveness.
>
> Actually in my experience it's the other way around -- editors tend to
> silo themselves, leading to gaps between specs. For example, separating
> HTML4, DOM2 HTML, and XHTML1 led to huge gaps in the specs that we spent
> significant effort fixing in HTML5. Avoiding this has been one of the
> important features of work with Adam, Anne, Lachlan, and Larry (who have
> edited specifications spun out of HTML5), and it has not been easy. Ask
> Anne, for example, about handling the event loop mechanism. Ask Adam or
> Larry about ensuring that we keep a coherent interface between their specs
> and HTML5. It's easy to see how having more editors can quickly result in
> a _loss_ of comprehensiveness -- quite the opposite of ensuring it, as you
> assert above.
>

Huge gaps?

Yes, there will always need to be work between groups to ensure that
the specifications work consistently with each other. But you're
talking about an event loop mechanism: what does that have to do with
HTML, a markup? Absorbing everything into HTML5 with one editor,
yourself, may give you the level of control you feel comfortable with,
or believe is necessary, but that doesn't mean that the end result is
better. Or that the work will be less.

What multiple editors and specs require is a level of cooperation. It
also means not necessarily having complete control.

>
>> 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?
>
> I don't like microdata. I think if it exists, however, it should be in the
> spec. (I think microdata is a much better solution for its problem space
> than other technologies that have addressed that same problem space
> previously, but personally I don't really think we should be even trying
> to solve that problem space.)

Definitely information that belongs in the discussion queue related to
the counter-proposal. I'll post a note, linking this email to the
thread.

>
> My opinion is irrelevant to this discussion, though (as is yours) -- the
> chairs have indicated that we are to provide rationales, not argue based
> on our opinions.
>

Opinions do matter -- what do you think rationales are based on?

And debate can be healthy. Sometimes compromises occur from debates.

>
>> 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.
>
> What should be part of HTML is what affects the conformance criteria for
> HTML conformance classes. Microdata does. I guess a parallel with software
> development would be that code that implements the interface for a library
> should be in that library.
>

Oh, no, there's nothing about Microdata that impacts conformance of
HTML. And it is most definitely not equivalent to an interface for a
library.

It is a separate section. It could be pulled cleanly, with no impact
at all to HTML, the markup language. Or the DOM. or the XHTML
serialization.

> (Also, HTML is far more than just a markup language. It's also a
> vocabulary and a set of APIs, and is part of an application platform.)
>

No, it is NOT an application platform. HTML is a markup language. In
the past, we had separate specs for the DOM, since that has,
typically, a different audience than the markup. And we had a separate
spec for the XML serialization of XHTML. I think the spec should be
split down into these three, because to be blunt, past specifications
are sure a lot more consistent and readable than the monolithic effort
of this group. And we can do so and still meet the Charter (the
Charter doesn't say everything has to be in one document).

However, leaving aside those three core functionalities, this group is
not chartered to create a specification that's only for browsers, and
primarily focused only at users with specific needs, such as Ajax
developers, or companies developing applications, like the Chrome OS.

However, we have a change proposal in place that hopefully will allow
us to tame this unmanageable beast, and still provide the
specifications that meet the Ajax developers and the company that's
creating the Chrome OS. But not by sacrificing clarity, succinctness,
and every other user agent and user that are dependent on HTML.


>
>> >> 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.
>
> This seems to be a complete non-sequitur. HTML makes use of a gread deal
> of other technologies. We're not reinventing everything from scratch. That
> has nothing to do with what we're talking about.
>

But you're trying to absorb unrelated technologies into the HTML
specification, seemingly because you want to control how all of it is
created.

>
>> 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.
>
> The "rules" you speak of do not suggest randomly fragmenting a
> specification or application along arbitrary lines based on the
> preferences of members of the team. Applications separate logically
> separate components. Using your analogy, what you and Manu are proposing
> is akin to taking an application and putting some functions in another
> file despite them being part of the same component. What you are proposing
> is emphatically _not_ equivalent to separating unrelated code into
> different modules with minimum interaction.
>

Oh, no, there is no random fragmentation in my recent bugs.

The bugs I've filed recently, and am still planning on filing, are
based on very careful evaluation and examination of the current HTML5
spec, past work, the charter, the user base interested in each
section, and so on.

Every bug I file I also plan on following up with a detailed change
proposal. No, I'm not being random, at all.

>> 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.
>
> You seem to have done a complete 180 in your argument here. First you were
> arguing that it IS easier to add a feature later than remove it, and now
> you are implying that it SHOULD be easier! What _should_ be easier or
> harder is not at issue here, the point is that if you think we need to
> ensure it is easy to remove microdata later, that we make sure that it is
> -- and indeed we have, as I have explained.
>

There is less impact to adding to the specification later, than there
is removing sections later.

This is no different than how we design database systems, or create
multi-tiered applications today. That's why you start very small, and
only add when there's a decided need, and after full discussion about
the ramifications of adding the new functionality.

However, when you remove something later in the creation process, you
then have to fix broken dependencies, you have a very good chance of
functionality being out of sync, it's difficult to determine what the
dependencies are, people have built up expectations, and so on.

So, yes, it is easier, or perhaps I should say, less disruptive, to
add than remove at a later time in the creation process.

>> > 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.
>
> But what if the bugs were then resolved in the W3C bug database, but not
> the WHATWG one? Would you suggest that the W3C should continue waiting for
> a resolution on the WHATWG side before publishing, even if there was no
> timetable for doing so?
>

I would most likely go to the WhatWG database, and if the bugs are
specific to what's in the W3C version of HTML5, copy them over to the
W3C bug database.

Since many of the bugs I see about HTML5 in the bug database at the
W3C are based on WhatWG discussions, I'm assuming that's happening.

> That's the equivalent of what happened here -- the W3C issues have all
> been given full consideration in the WHATWG, the WHATWG just came to
> conclusions faster.
>

No: as far as I know. there is no change proposal in place at the
WhatWG. No offense, but you are more or less supreme ruler in the
WhatWG.

And there are many people involved with HTML in this group that are
not in the WhatWG. After all, there are only a handful of allowed
members in the WhatWG.

It is by invitation only, after all.

>
>> Regardless, the announcement caused confusion. We should do everything
>> in our power not to cause confusion.
>
> I haven't seen any confusion. Do you have any pointers?
>
>

Oh geez, yes. Just search on the terms "html5 last call".

>> >> >> 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.
>
> I agree entirely. The separate parts should be in separate documents. CSS,
> HTML, ECMAScript, and HTTP are separate parts. Microdata, however, is part
> of the HTML part, just like title="", class="", id="", onclick="", <img>,
> and so on.
>

Ian, I don't want to get chastised for this, but I think your response
is a little disingenuous. I do believe you know what I was saying
here. The same as I believe you know there's a difference between one
element, and the entire Microdata section.

> Your line of argumentation doesn't support your premise, unless you also
> think we should separate each set of elements and attributes into its own
> separate spec.
>
>
>> > "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?
>
> My happiness really has nothing to do with this discussion.
>

But if you're frustrated about working on "just" HTML that will impact
on the specification. So I was less concerned about making you happy,
and more concerned that the HTML5 editors are content with the subject
matter, and only the subject matter. This ensures that the spec
remains focused.

>
>> 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.
>
> Splitting Microdata into its own specification would strangle innovation.
>

Nope. Disagree. There's nothing about Microdata being a separate
specification that would strangle innovation. Nope, must disagree.

> (Well, if you're allowed to make completely non-sequitur soundbite-like
> arguments without evidence to back up your position, I figure I am too.)
>

I'm responding to your comments you've addressed to me. I'm involved
in a debate. I'm not sure why you've decided to respond with an ad
hominen response (non-sequitur sound-bite like arguments).

>
>> >> >> Just the same as applications are cleaner, and better when they're
>> >> >> based on modularization.
>> >> >
>> >> > I do not think this statement is a truism.
>> >
>> > 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.
>
> I didn't say CSS3 was a failure, I said CSS3 was less successful than
> CSS2. If you do not think this is the case, maybe you haven't been
> involved with the CSS working group enough.
>

I imagine they've had starts and stops, and acrimonious debate. I have
followed along with other W3C email lists, I understand what can
happen.

But I'm seeing some great stuff come out of the CSS3 efforts, so to
me, CSS3 is a success.

> I didn't mention XHTML 2.0 at all. I talked about XHTML Modularisation,
> which was a 1.x-series set of specifications. That you haven't apparently
> heard of it, or that you confused it with XHTML2, may in fact demonstrate
> my point perfectly.
>

Sorry, my misreading. When I see references to XHTML and lack of
success, I tend to 'see' XHTML 2.0. That is the only "failed" XHTML
that I know of.

Yes, I have heard of XHTML Modularization. I believe XHTML
Modularization 1.1 is a recommendation, is it not? That's farther than
we've managed in this group, so, no, I don't see the effort as a
failure.

>
>> >> 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.
>>
>> 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.
>
> Apparently we _don't_ learn. You are, after all, arguing in favour of the
> kinds of mistaken decisions that led to the exact situation I described.
> If we were learning, we would avoid making those mistakes again.
>

No, I'm saying that bumps and hiccups, and problems happen when you're
creating specifications. It is a natural process. I don't think we
need to eliminate the process, we learn from the specifics of past
mistakes.

So, you think then that the only to remove errors is monolithic
documents, created by one author?

>
>> >> 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.
>
> I repeat, with all due respect, that can only mean that you aren't
> looking. I provided links above demonstrating my point. If you would like
> to disagree, I would request that you at least quantify your argument or
> provide some sort of backing for it. I'm sure hat simply asserting
> positions that point-blank contradict provided evidence is not what the
> chairs had in mind when they suggested the use of rationales to support
> our arguments.
>

I don't see many aspects of HTML5 in all user agents. There are the
new controls, such as details, and Microdata, and its API that it has
created, and changes in the Canvas element, and some of cross document
messaging, and a host of HTML5 components that don't have broad
implementation. Validator.nu still throws an error when you embed SVG
in an HTML document, and only Firefox supports SVG in HTML right now.

There are fragments of adoption across some user agents, like
browsers, but little in HTML editors, and practically none in other
HTML user agents, such as web bots, or content management systems such
as Wordpress or Drupal. I don't believe that Google has changed its
web bot activity based on HTML5, though it may have. I don't think
Bing has.

None of the screen readers have adopted the new elements, as far as I know.

More importantly, there are only scattered sparse web pages using
HTML5 for their web page layout.

Naturally: HTML5 is still in draft. And major changes still occur, so
people are wary of implementing something that may change or go away.

So no, there hasn't been "broad" adoption of HTML5. There shouldn't
have been, it's only a draft. And a heavily volatile one at that.

>>
>> I think we need to stop trying to control everything.
>
> That has absolutely nothing to do with the subject at hand. We're talking
> about whether or not a particular feature of HTML5 should be in the same
> document as the rest of HTML5. That doesn't affect control in any way.
>

Actually this really is a question of control. If pieces are split off
from the HTML5 document, they could end up in their own working
groups, and with their own editors. That means this group, and you,
would have little control over the spec, if this were to happen.


>
>
>> >> 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.
>
> Is there _any_ content in HTML5 that is _not_ specific to only a subset of
> user agents? If that is your criteria for keeping something in the spec,
> what would you suggest we should _keep_?
>

HTML is specific to HTML, so HTML elements and attributes, and rules
regarding the syntax belong in the spec, but the Browser Object Model
has little or nothing to do with HTML, per se, and everything to do
with a specific set of user agents -- browsers.

But again, we don't have to argue back and forth on this one, since
we'll never agree: we have a change proposal in place to manage just
these sorts of situations.


>
>> 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 have been working on other things these past few weeks (including a
> vacation), and will likely not return to dealing with bugs until January.
> Right now we have fewer than 200 bugs; the most we've ever had was 210,
> and that took less than a month to deal with. Since we currently have 32
> issues to deal with, and those take in the region of a month each to deal
> with, it is my understanding that I am not the bottleneck at the moment.
> However, I am in regular contact with the chairs and will ensure that bugs
> are dealt with at a suitable pace.
>

Some of those bugs are major. Very major. And marking bugs as WONTFIX
will most likely trigger issues from this point. More importantly,
you, as the sole author of HTML5 at this time, are also a key
component in most of the issues, too.

I would say, from what you just said, that it's time for this group to
bring in more editors. You're obviously overwhelmed with work.


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


Shelley

Received on Sunday, 6 December 2009 14:50:35 UTC