An alternate take on HTML5

16 views
Skip to first unread message

sayrer

unread,
Feb 17, 2009, 3:18:52 PM2/17/09
to
See the dicussion here:

<https://bugzilla.mozilla.org/show_bug.cgi?id=478665>

...but please don't add to it. This venue is better for threaded
discussion.

Here's a summary by Sam Ruby:

"Here's my current understanding: HTML4 is vague and defines a set of
features.
Rob's draft adds well defined error handling and a very select few
features.
Ian's draft adds (as compared to HTML4) well defined error handling, a
rendering section, and quite a bit more features. To the point that I
understand both, at the moment Rob's draft appears to be consistent
with the
direction that Ian's draft is pursuing, largely by virtue of being a
derived
work and containing approximately 60 to 65% of the original text
verbatim.

Rob's work differs substantially from the work of Mike, DanC and
Lachlan."

At this point, it's just an HTML file I produced. I haven't proposed
it to the WG or anything like that. I want to know what the Mozilla
community thinks. However, I'm not asking for requirements of the form
"before you do X, you have to do Y", since those are often used as a
way of directing people to work on things they're not interested in.

Robert O'Callahan

unread,
Feb 17, 2009, 11:21:48 PM2/17/09
to

For the record, I think it's harmless to good, as long as it doesn't
become HTML5 thus leading to headlines like "Video removed from HTML5"
(and similar for other features), which would hurt our work in those areas.

Rob

Henri Sivonen

unread,
Feb 18, 2009, 5:50:25 AM2/18/09
to
In article
<6a70e148-b3dc-44b7...@v31g2000vbb.googlegroups.com>,
sayrer <say...@gmail.com> wrote:

> At this point, it's just an HTML file I produced. I haven't proposed
> it to the WG or anything like that. I want to know what the Mozilla
> community thinks.

I have trouble deciding what I think without knowing what the purpose of
your document is. What's the goal you are trying to achieve and why?

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

sayrer

unread,
Feb 18, 2009, 11:40:11 AM2/18/09
to
On Feb 18, 5:50 am, Henri Sivonen <hsivo...@iki.fi> wrote:
>
> I have trouble deciding what I think without knowing what the purpose of
> your document is. What's the goal you are trying to achieve and why?

To publish a document with well defined error handling and a very
select few new features, quickly.

- Rob

rubys

unread,
Feb 18, 2009, 12:13:18 PM2/18/09
to

The current W3C plan (<http://www.w3.org/html/wg/>) is: 2009-06 HTML5
Candidate Recommendation

I don't believe that achieving that milestone with all of the features
in Ian's draft is achievable.

What's plan B?

One alternative is to take as long as it takes until all of the
features are done.

Another is to take a reasonable stab at pruning features.

Another is to stage features across multiple releases.

Yes, there might be bad press for any and all of the above options.

- Sam Ruby

Robert O'Callahan

unread,
Feb 18, 2009, 3:30:06 PM2/18/09
to
On 19/2/09 6:13 AM, rubys wrote:
> The current W3C plan (<http://www.w3.org/html/wg/>) is: 2009-06 HTML5
> Candidate Recommendation
>
> I don't believe that achieving that milestone with all of the features
> in Ian's draft is achievable.

Sure.

> What's plan B?
>
> One alternative is to take as long as it takes until all of the
> features are done.
>
> Another is to take a reasonable stab at pruning features.
>
> Another is to stage features across multiple releases.

This last one, but calling the releases "HTML 4.x", wouldn't bother me.
I'm assuming that whichever option is taken, Ian's HTML5 document
continues to be the destination.

Rob

Benjamin Smedberg

unread,
Feb 18, 2009, 3:59:21 PM2/18/09
to
On 2/18/09 12:13 PM, rubys wrote:

> The current W3C plan (<http://www.w3.org/html/wg/>) is: 2009-06 HTML5
> Candidate Recommendation
>
> I don't believe that achieving that milestone with all of the features
> in Ian's draft is achievable.

I am concerned that the milestone dates given are unrealistic for any
specification that has relatively complete test suites. From what I've seen,
there are currently very few tests other than some parser tests associated
with hsivonen's references implementation.

Overall, I think it's better to have no new specification than a
specification without significant test coverage.

It's important to get the parsing and DOM specification complete enough that
it can specify correct and useful behavior for elements and attributes which
aren't currently specified. Thus, if <video> or <canvas> or <whatever> is
not included in the spec, the spec should at least be very specific about
the parsing of those unknown elements and the DOM tree that is constructed,
so that future specifications don't have to break the current specification.

Without a diff of sayrer's doc versus the large HTML5 spec, it's hard to
give detailed feedback, but I tend to agree that it's possible and prudent
to produce a specification in stages, by rolling out certain sections such
as parsing and error handling, and then dealing with new features as the
specification of those features matures and tests become available.

--BDS

Sam Ruby

unread,
Feb 18, 2009, 5:37:56 PM2/18/09
to

I'll bet that ECMAScript 3.1 will end up becoming officially
ECMAScript 4 by the time it is published. What was ECMAScript 4 got
its scope "adjusted" (read: significantly reduced) and is now being
called by a code name and not with a number. Some things may be
unfortunate and beyond our control. I'm just pointing this out as I
don't want to mislead anyone. Even if we were to agree now that Rob's
document was to be called 4.1, what it ends up getting published as
may be different. If it takes six years and three releases, those
releases may very well end up being named HTML5, HTML6, and HTML7.

With the caveat that Ian's document is a rapidly moving target and may
contain a number of items that may never attain consensus, I am
comfortable in saying that I feel that Ian's document represents the
best current thinking on the long term evolution of HTML.

> Rob

- Sam Ruby

Ian Hickson

unread,
Feb 18, 2009, 6:44:14 PM2/18/09
to sayrer, rubys, Robert O'Callahan, dev-pl...@lists.mozilla.org
On Wed, 18 Feb 2009, sayrer wrote:
>
> On Feb 18, 5:50 am, Henri Sivonen <hsivo...@iki.fi> wrote:
>
> > I have trouble deciding what I think without knowing what the purpose
> > of your document is. What's the goal you are trying to achieve and
> > why?
>
> To publish a document with well defined error handling and a very select
> few new features, quickly.

I think this is a laudable goal, if executed fully. (My concern is that we
should not leave features define in the spec under-defined, otherwise
what's the point -- after all, HTML4 already does a fine job of being an
incomplete specification!)


On Wed, 18 Feb 2009, rubys wrote:
>
> The current W3C plan (<http://www.w3.org/html/wg/>) is: 2009-06 HTML5
> Candidate Recommendation

The W3C timetable was unrealistic when it was conceived (and I said as
much at the time). The W3C is not well-known for its ability to write
plausible timetables; often the first milestone in a charter is missed
before the charter has itself been approved! For what it's worth I have
been working to this timetable:

http://www.whatwg.org/specs/web-apps/current-work/TIMETABLE

Features have been and will continue to be pruned; that is an essential
part of any standardisation process. Features have also been staged; just
look in the source of the HTML5 spec for the string "v2" for laundry lists
of features that have been pushed off to HTML6 or later.


On Thu, 19 Feb 2009, Robert O'Callahan wrote:
> >
> > Another is to stage features across multiple releases.
>
> This last one, but calling the releases "HTML 4.x", wouldn't bother me.

I would be a fan of having an "HTML4.1" draft which is "HTML4 done right",
maybe with a few additional features like <canvas>. This would be the
equivalent of CSS 2.1, which was "CSS2 done right", with a few additional
features (like the color 'orange').

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

sayrer

unread,
Feb 18, 2009, 7:25:20 PM2/18/09
to
On Feb 18, 6:44 pm, Ian Hickson <i...@hixie.ch> wrote:
> On Wed, 18 Feb 2009, sayrer wrote:
>
> > To publish a document with well defined error handling and a very select
> > few new features, quickly.
>
> I think this is a laudable goal, if executed fully. (My concern is that we
> should not leave features define in the spec under-defined, otherwise
> what's the point -- after all, HTML4 already does a fine job of being an
> incomplete specification!)

This statement seems to imply that improving the specification is an
all-or-nothing proposition when it comes to existing features. I do
not agree. To use a specific example, I don't plan on including a
"Rendering" section, as HTML5 does. I think getting consensus on the
Rendering section is an effort that matches the time scale you have
outlined for HTML5. I don't think this makes getting consensus and
publishing the parser, getElementsByClassName, <canvas>, etc, a
pointless exercise.

I recognize you might not agree, and I expect "getting consensus" is
more important to me than to you. But that's the W3C process, and this
disagreement is about magnitude, not direction. Overall, the goals are
close.

In my goal, I place a lot of value on "quickly". I favor cutting
things that are not critical to the Web if that improves the schedule--
with the caveat that some features and refinements must remain in the
document in order to prevent bad actors from slow-rolling the Working
Group, and the Web itself. To use a concrete example, the parsing
section is non-negotiable to me, but I would favor cutting XML/XHTML
entirely if it looks like I'm wasting a braincell on XHTML2
coordination. In other words, I would rather deliver an incomplete
deliverable on time, than a complete one very late.

- Rob

Ian Hickson

unread,
Feb 18, 2009, 8:06:03 PM2/18/09
to sayrer, dev-pl...@lists.mozilla.org
On Wed, 18 Feb 2009, sayrer wrote:
> On Feb 18, 6:44 pm, Ian Hickson <i...@hixie.ch> wrote:
> > On Wed, 18 Feb 2009, sayrer wrote:
> >
> > > To publish a document with well defined error handling and a very
> > > select few new features, quickly.
> >
> > I think this is a laudable goal, if executed fully. (My concern is
> > that we should not leave features define in the spec under-defined,
> > otherwise what's the point -- after all, HTML4 already does a fine job
> > of being an incomplete specification!)
>
> This statement seems to imply that improving the specification is an
> all-or-nothing proposition when it comes to existing features. I do not
> agree. To use a specific example, I don't plan on including a
> "Rendering" section, as HTML5 does. I think getting consensus on the
> Rendering section is an effort that matches the time scale you have
> outlined for HTML5.

Since the section is non-normative, I actually expect consensus on that
section to be the least of the troubles in HTML5.


> I recognize you might not agree, and I expect "getting consensus" is
> more important to me than to you.

But you don't have consensus on not having the rendering section...


> In other words, I would rather deliver an incomplete deliverable on
> time, than a complete one very late.

I entirely agree with this. You'll note that HTML5 has been exactly on
track to the published timetable ever since we had a timetable.


I guess I don't really see the point of doing something quickly if it
leaves things underdefined -- underdefined (as opposed to omitted
entirely) seems far worse than slow.

sayrer

unread,
Feb 18, 2009, 8:13:07 PM2/18/09
to
On Feb 18, 8:06 pm, Ian Hickson <i...@hixie.ch> wrote:
> > I recognize you might not agree, and I expect "getting consensus" is
> > more important to me than to you.
>
> But you don't have consensus on not having the rendering section...

Well, it's clear that I don't have unanimity.

> I guess I don't really see the point of doing something quickly if it
> leaves things underdefined -- underdefined (as opposed to omitted
> entirely) seems far worse than slow.

If they are underdefined now, it doesn't make things worse. imho.

- Rob

rubys

unread,
Feb 18, 2009, 8:58:21 PM2/18/09
to
On Feb 18, 8:06 pm, Ian Hickson <i...@hixie.ch> wrote:
>
> I entirely agree with this. You'll note that HTML5 has been exactly on
> track to the published timetable ever since we had a timetable.

Question: what is the published timetable for test cases being
complete?

- Sam Ruby

Ian Hickson

unread,
Feb 18, 2009, 9:02:14 PM2/18/09
to rubys, dev-pl...@lists.mozilla.org

The URI I cited earlier in this thread, namely the aforementioned
published timetable, details the timetable for the test suite also:

http://www.whatwg.org/specs/web-apps/current-work/TIMETABLE

(It has to, since without a complete test suite the spec can't exit CR.)

Henri Sivonen

unread,
Feb 19, 2009, 5:16:51 AM2/19/09
to
In article
<6361100b-0d05-4f86...@n20g2000vba.googlegroups.com>,
sayrer <say...@gmail.com> wrote:

Publish in what way? HTML 5 as it exists on any given day is already
published in the sense that it is public and anyone can GET in and read
it freely.

The stability of a given part of the open Web platform doesn't really
depend on the declared publication status of any document. It depends on
whether major implementations have converged on uniform (aka.
interoperable) behavior on the part of the platform. Thus, pushing
*documents* more quickly doesn't help. Writing code does.

Having a spec is beneficial, since it lowers the cost of making the
convergence happen where it hasn't already by lowering the cost of
finding out on what to converge thereby making the writing code part
faster.

Surely browser implementors are well aware of this situation, so
"publishing" a document quickly doesn't achieve anything as far as
communicating with browser implementors goes that a public perma-draft
with stability annotations on a per-section basis doesn't achieve.

Non-rhetorical question: If one works on style system or layout code,
does it make more sense to read CSS 2.1 or to read the latest Editor's
Draft of the relevant CSS3 spec?

If the purpose of "publishing" is to send signals to people other than
browser implementors, to whom and why?

On a more meta-level, in the light of point #7 at
http://blog.mozilla.com/rob-sayre/2009/01/19/where-memes-go-to-die/ :
Do you have a vision on how browser vendors should behave wrt. speccing
and communication among competitors when introducing new features to the
open Web platform? (I have a vision about that. I'll try to find time to
write it down.)

Robert O'Callahan

unread,
Feb 19, 2009, 7:22:47 AM2/19/09
to
On 19/2/09 11:16 PM, Henri Sivonen wrote:
> Non-rhetorical question: If one works on style system or layout code,
> does it make more sense to read CSS 2.1 or to read the latest Editor's
> Draft of the relevant CSS3 spec?

It depends. CSS 2.1 will tell you what authors are likely to be relying on.

The difference is that CSS3 drafts are more likely to change, and be
changeable, than CSS2.1. That matters to browser implementors and authors.

> If the purpose of "publishing" is to send signals to people other than
> browser implementors, to whom and why?

To let authors know what is stable and to raise their expections that it
actually works in browsers.

We could use annotations in a monolithic document for these things, but
I think it's fair to say that a separate document makes the point better.

Rob

Henri Sivonen

unread,
Feb 19, 2009, 8:10:46 AM2/19/09
to
In article <QdCdnW7i7taF0gDU...@mozilla.org>,

Robert O'Callahan <rob...@ocallahan.org> wrote:

> On 19/2/09 11:16 PM, Henri Sivonen wrote:
> > Non-rhetorical question: If one works on style system or layout code,
> > does it make more sense to read CSS 2.1 or to read the latest Editor's
> > Draft of the relevant CSS3 spec?
>
> It depends. CSS 2.1 will tell you what authors are likely to be relying on.

Is it good to deduce that information from a spec? Wouldn't something
like Opera MAMA work better for that purpose?

> The difference is that CSS3 drafts are more likely to change, and be
> changeable, than CSS2.1. That matters to browser implementors and authors.

But the CSS WG is free to change only those aspects of CSS3 that
implementations have not yet converged on. If there's a feature that
implementations have converged on, shouldn't that part be equally stable
in CSS 2.1 and CSS3? It seems to me that if the CSS WG were to change a
part of CSS that has been interoperably implemented, it would be going
astray.

Personally, I think the direction of publishing things like "CSS
Beijing" (as a concept; not necessarily expressed exactly like 'Beijing'
was) for authors while making the "CSS3" perma-drafts available to
implementors and early adopters is more useful than getting CSS 2.1 to
REC at the expense of editorial attention to the same areas in the CSS3
drafts.

Ten years ago, the bar for a REC was way too low, but now the bar for a
REC is so high that any monolithic spec concerning an area of the
platform where innovation still happens is obsolete by the time it gets
to REC. The specs need to be roughly as live as implementations. If the
bar of pushing a spec to REC in far higher than the bar for pushing a
browser to a release, the specs either never get to REC or are obsolete
when they do (at least in the sense of being incomplete accounts of
their subject matter; I don't think CSS 2.1 will be incorrect for the
things it does describe).

Splitting stuff out of HTML5 in order to make it get to REC fast would
mean that the part that got to REC would already be obsolete in the
sense that it wouldn't accurately capture the new action in the
development of the platform even if it were accurate for the older parts.

However, splitting adds overhead in many ways including the technical
overhead of maintaining cross-references, the bureaucratic overhead
around licensing and chartering, the overhead of communication between
editors, etc. This is why I think it's useful to maintain fine-grained
stability annotations within a larger document than to split a document
solely for the reason of being able to use per-document stability
designations.

HTML5 does have mostly independent parts that could be offloaded to
different editors if editors were available. In particular, pure API
features such as Web Socket and SQL storage are minimally intertwined
with the rest of the spec. Still, the traditional W3C and IETF
dependency rules are very impractical, and I think it would be more
useful to adjust the rules than to try to make specs fit to the rules.

For example, XHR was a split out of HTML5 and is mostly independent,
except for the serialization and parsing algorithms and the concept of
origin. Redefining these concepts solely for the purpose of making XHR
proceed to REC without normative references to documents with a lesser
status would not be a good idea, because reuse of code should match the
inter-spec references. The concept of origin, for example, permeates the
entire browser, so it is exactly as stable or unstable regardless of
what aspect pretends about its stability.

> > If the purpose of "publishing" is to send signals to people other than
> > browser implementors, to whom and why?
>
> To let authors know what is stable and to raise their expections that it
> actually works in browsers.
>
> We could use annotations in a monolithic document for these things, but
> I think it's fair to say that a separate document makes the point better.

If the purpose is to communicate to authors, why does the document at
http://people.mozilla.com/~sayrer/2009/02/15/html5.html
include the HTML5 parsing algorithm? Shouldn't authors be shown
something like the "Writing" section instead?

I think it would be useful to publish summaries of stable areas of the
open Web platform for authors from time to time. However, if the purpose
is to communicate to an audience the Web authors, I think taking a spec
with implementation algorithms and hitting backspace on parts of it is
not a very good method of communication. Summaries in the style of the
HTML5 differences from HTML 4 document could be much more effective.
Further, there is a political problem with publishing summaries of
platform stability to authors--at least from a W3C WG: If a feature is
implemented in Firefox, Safari, Opera, Chrome and IE, it is pretty
uncontroversial to summarize it as something that authors can use. If it
is only implemented in one of them, is pretty uncontroversial to
summarize it is something that authors can't safely use. However, coming
up with vendor-neutral criteria for documenting the cases in between is
harder.

rubys

unread,
Feb 19, 2009, 8:30:07 AM2/19/09
to
On Feb 18, 9:02 pm, Ian Hickson <i...@hixie.ch> wrote:
> On Wed, 18 Feb 2009, rubys wrote:
> > On Feb 18, 8:06 pm, Ian Hickson <i...@hixie.ch> wrote:
>
> > > I entirely agree with this. You'll note that HTML5 has been exactly on
> > > track to the published timetable ever since we had a timetable.
>
> > Question: what is the published timetable for test cases being complete?
>
> The URI I cited earlier in this thread, namely the aforementioned
> published timetable, details the timetable for the test suite also:
>
> http://www.whatwg.org/specs/web-apps/current-work/TIMETABLE
>
> (It has to, since without a complete test suite the spec can't exit CR.)

You've made amazing progress to date, and I very much want you to
continue. However from my perspective you have done so by cutting a
number of big corners: including the need to establish and maintain
consensus, and the need to create test suites up front.

Frankly, the first corner I mentioned will bite you in the ass when we
get to the very next milestone. I haven't reviewed the list of things
that Rob has cut from your draft to produce his draft, but I'm
confident that a number of them are things over which consensus has
not been reached. In fact, many of them appear to be outside of the
scope of the W3C Working Group. Could the charter of the working
group be changed and consensus be reached on any one of those items?
Quite possibly. Could this be done simultaneously for each and every
one of the items and on the schedule you have defined? Not a chance.

Rob's bar which I will characterize as "no worse than HTML4 and
significantly better in a select few ways" is the way forward, IMHO.
That being said, I do *not* believe that work on your draft should
slow down one bit. You are blazing a trail, and everybody would like
you to continue to do so. All we need to make sure that is that
others with more near term focuses do things which are largely
consistent and absolutely do not preclude the direction you are
taking.

- Sam Ruby

rubys

unread,
Feb 19, 2009, 8:39:37 AM2/19/09
to
On Feb 19, 5:16 am, Henri Sivonen <hsivo...@iki.fi> wrote:
> In article
> <6361100b-0d05-4f86-b3d5-87f580073...@n20g2000vba.googlegroups.com>,

>
>  sayrer <say...@gmail.com> wrote:
> > On Feb 18, 5:50 am, Henri Sivonen <hsivo...@iki.fi> wrote:
>
> > > I have trouble deciding what I think without knowing what the purpose of
> > > your document is. What's the goal you are trying to achieve and why?
>
> > To publish a document with well defined error handling and a very
> > select few new features, quickly.
>
> Publish in what way? HTML 5 as it exists on any given day is already
> published in the sense that it is public and anyone can GET in and read
> it freely.

And contains a number of things that have no consensus and others that
will change tomorrow.

You raise a number of valid points on Rob's document. Perhaps it
could be approached in a different way, and I encourage people to try
(I will say that doing so is much harder than it might appear to be).
But Rob's effort makes it much easier for people like me to pose the
following question:

If you look at the list of sections that Rob cut, do we, as a group,
have consensus that we want to include each and every last one of
those in the draft we put forward for Last Call this fall, and are we
confident that we will have zero open issues on each by that time?

- Sam Ruby

Boris Zbarsky

unread,
Feb 19, 2009, 9:10:52 AM2/19/09
to
Henri Sivonen wrote:
> But the CSS WG is free to change only those aspects of CSS3 that
> implementations have not yet converged on.

Since they're implementing with vendor prefixes, this might well not be
the case, actually... until CR, of course.

> It seems to me that if the CSS WG were to change a
> part of CSS that has been interoperably implemented, it would be going
> astray.

That depends on how that part interacted with other parts, in my opinion.

> Splitting stuff out of HTML5 in order to make it get to REC fast would
> mean that the part that got to REC would already be obsolete in the
> sense that it wouldn't accurately capture the new action in the
> development of the platform even if it were accurate for the older parts.

This might not inherently be a problem.

> If the purpose is to communicate to authors, why does the document at
> http://people.mozilla.com/~sayrer/2009/02/15/html5.html
> include the HTML5 parsing algorithm? Shouldn't authors be shown
> something like the "Writing" section instead?

Communicating to UA authors is not a bad thing either. It's good to
know when the spec editor feels they're done with gratuitous changes and
are waiting on impl feedback. Going to CR announces this, but since
HTML5 isn't planning to do this for a while...

-Boris

sayrer

unread,
Feb 19, 2009, 2:27:39 PM2/19/09
to
Henri Sivonen wrote:
> Publish in what way? HTML 5 as it exists on any given day is already
> published in the sense that it is public and anyone can GET in and read
> it freely.

Sam, Boris, and Robert O'Callahan all made the same points I would
have.

On Feb 19, 8:30 am, rubys <ru...@intertwingly.net> wrote:
> In fact, many of them appear to be outside of the
> scope of the W3C Working Group.  Could the charter of the working
> group be changed and consensus be reached on any one of those items?
> Quite possibly.  Could this be done simultaneously for each and every
> one of the items and on the schedule you have defined?  Not a chance.

I do not recommend this line of argument, if you want to iterate
rapidly. The charter of the W3C Working Group is broadly worded.

Here is a record of a resolved charter dispute:
<http://www.w3.org/html/wg/tracker/issues/15>

In my document, I treated that vote as input from the WG. It appears
there are 3 major compatible implementations, a large test suite[1],
and consensus on technical workings of the element. The current HTML
working group charter was issued on 7 March 2007. It's 2009 now, and
so canvas must go in the first deliverable in order to preserve the
WG's credibility (in my strongly held opinion).

> Rob's bar which I will characterize as "no worse than HTML4 and
> significantly better in a select few ways" is the way forward, IMHO.
> That being said, I do *not* believe that work on your draft should
> slow down one bit.

Fully agree about Ian's work.

- Rob

[1] http://philip.html5.org/tests/canvas/suite/tests/

rubys

unread,
Feb 19, 2009, 3:27:19 PM2/19/09
to
On Feb 19, 2:27 pm, sayrer <say...@gmail.com> wrote:
> On Feb 19, 8:30 am, rubys <ru...@intertwingly.net> wrote:
>
> > In fact, many of them appear to be outside of the
> > scope of the W3C Working Group.  Could the charter of the working
> > group be changed and consensus be reached on any one of those items?
> > Quite possibly.  Could this be done simultaneously for each and every
> > one of the items and on the schedule you have defined?  Not a chance.
>
> I do not recommend this line of argument, if you want to iterate
> rapidly. The charter of the W3C Working Group is broadly worded.
>
> Here is a record of a resolved charter dispute:
> <http://www.w3.org/html/wg/tracker/issues/15>
>
> In my document, I treated that vote as input from the WG. It appears
> there are 3 major compatible implementations, a large test suite[1],
> and consensus on technical workings of the element. The current HTML
> working group charter was issued on 7 March 2007. It's 2009 now, and
> so canvas must go in the first deliverable in order to preserve the
> WG's credibility (in my strongly held opinion).

s/preserve/establish/

My todo: http://www.w3.org/html/wg/tracker/actions/38

- Sam Ruby

Ian Hickson

unread,
Feb 19, 2009, 4:51:21 PM2/19/09
to rubys, www-a...@w3.org, dev-pl...@lists.mozilla.org
On Thu, 19 Feb 2009, rubys wrote:
>
> You've made amazing progress to date, and I very much want you to
> continue. However from my perspective you have done so by cutting a
> number of big corners: including the need to establish and maintain
> consensus, and the need to create test suites up front.
>
> Frankly, the first corner I mentioned will bite you in the ass when we
> get to the very next milestone. I haven't reviewed the list of things
> that Rob has cut from your draft to produce his draft, but I'm confident
> that a number of them are things over which consensus has not been
> reached. In fact, many of them appear to be outside of the scope of the
> W3C Working Group. Could the charter of the working group be changed
> and consensus be reached on any one of those items? Quite possibly.
> Could this be done simultaneously for each and every one of the items
> and on the schedule you have defined? Not a chance.

Realistically speaking, we'll never have complete consensus on everything
in HTML5. At the simplest level, there are contradictory opinions on the
very fundamentals of the work -- some people want error handling defined,
some don't; some people want a schema, some don't; some people want APIs
defined, some don't; the list is long.

So consensus -- unanimity -- isn't an interesting goal.

The next step down in terms of opinion-based progress is majority
agreement, and I am confident that with the exception of things that need
changing and will be changed in time for the next milestone, we have a
majority agreement on everything in HTML5.

Majority agreement in a self-selected community like an open working
group is worth less than it would appear, though, because there is a
selection bias: only people who are interested in both the technology and
in standards development are going to take part. In the W3C working group,
there is a further bar: we only allow people who are willing to put up
with an inordinate amount of bureacuracy (to join) and noise to be part of
the group whose opinion is measured.

Statistically, therefore, the opinions of the working group almost
certainly don't match the opinions of the whole Web community.

An alternative approach, the one which the WHATWG (and by extension the
editor's draft in the HTMLWG) has been using, is to use the "vote with
your feet" approach: things that aren't implemented or used get thrown
out, things that _are_ implemented or used get adopted. For new features
this means that browser vendors have, as a group, the ability to veto
anything, but that's true anyway, whether we admit it or not. For the
direction the Web is going in, it means that authors that write content
that gets crawled and measured in the studies we do get a vote. In this
model, users get the ultimate vote by deciding whether or not they adopt a
particular browser and whether or not they visit particular sites;
browsers without adoption end up with less ability to veto, and sites with
fewer users tend to die earlier and fall off the statistical radar.

I understand that it would be controversial to use this method in the W3C,
however.

Given the goal of publishing a Last Call draft in October, what approach
do you think we should take to achieve that goal in the W3C? Should we
start having votes to ask people which sections they won't support? Should
we start collecting "formal objection"-type comments on the list? What bar
will you be looking for when I say "ok there is no outstanding feedback,
let's publish a Last Call draft"?

sayrer

unread,
Feb 19, 2009, 5:10:27 PM2/19/09
to
On Feb 19, 4:51 pm, Ian Hickson <i...@hixie.ch> wrote:
>
> An alternative approach, the one which the WHATWG (and by extension the
> editor's draft in the HTMLWG) has been using, is to use the "vote with
> your feet" approach: things that aren't implemented or used get thrown
> out, things that _are_ implemented or used get adopted. For new features
> this means that browser vendors have, as a group, the ability to veto
> anything, but that's true anyway, whether we admit it or not.

This is not quite right. Browser vendors with sufficient market share
have an ability to effectively veto new features by themselves,
especially if those features can't be emulated with existing
technologies. HTML5's model of adding features that anyone implements
(SQL, registerContentHandler, etc) overstates the ability of that
vendor to add something to the Web. This demonstrably applies to all
WHATWG participants, but not all W3C WG participants.

- Rob

Ian Hickson

unread,
Feb 19, 2009, 5:46:32 PM2/19/09
to sayrer, dev-pl...@lists.mozilla.org

I agree that the situation is actually more subtle than my simplistic
description, but it's not quite as simple as you suggest either. For
example, <canvas> is part of the Web now, used in production code. (Yahoo!
Pipes and Dreamhost's user-facing tools are two examples of actual running
code that uses <canvas>, for instance.) Similarly for SVG. This is despite
the absence of support for these technologies in the market leader (by
installed base).

Note also that features aren't just added because someone implements it,
and features are certainly not kept just because one UA supports it. The
SQL stuff was added over my objections due to avid requests from two
vendors (Apple and Google) and the lack of any other proposals to address
the same use cases (how else do you store mail in an offline mail app? The
localStorage feature certainly doesn't cut it). Similarly, the register-
ContentHandler() feature was added because there was a clear use case and
no good alternatives.

(Not everything in HTML5 starts with implementations; <datagrid> and
<commmand> are two examples of things that had no planned or real
implementation when specced. Same applies outside HTML5, e.g. to XBL2.)

sayrer

unread,
Feb 19, 2009, 6:22:14 PM2/19/09
to
On Feb 19, 5:46 pm, Ian Hickson <i...@hixie.ch> wrote:
>
> I agree that the situation is actually more subtle than my simplistic
> description, but it's not quite as simple as you suggest either. For
> example, <canvas> is part of the Web now, used in production code. (Yahoo!
> Pipes and Dreamhost's user-facing tools are two examples of actual running
> code that uses <canvas>, for instance.) Similarly for SVG. This is despite
> the absence of support for these technologies in the market leader (by
> installed base).

This is not a good argument, we're looking for an order of magnitude
more adoption. That is sub-silverlight success.

>
> Note also that features aren't just added because someone implements it,
> and features are certainly not kept just because one UA supports it. The
> SQL stuff was added over my objections due to avid requests from two
> vendors (Apple and Google) and the lack of any other proposals to address
> the same use cases

How did they override you? You're the dictator. At any rate, but that
absence doesn't mean SQL needs to go in the HTML spec. It could be
great, give it its own document, maybe it will take off. Does that
make sense?

I am responsive to the argument that you're one the doing the work, so
I took steps to produce the approach I believe in.

- Rob

Ian Hickson

unread,
Feb 19, 2009, 7:25:00 PM2/19/09
to sayrer, dev-pl...@lists.mozilla.org
On Thu, 19 Feb 2009, sayrer wrote:
> On Feb 19, 5:46 pm, Ian Hickson <i...@hixie.ch> wrote:
> >
> > I agree that the situation is actually more subtle than my simplistic
> > description, but it's not quite as simple as you suggest either. For
> > example, <canvas> is part of the Web now, used in production code.
> > (Yahoo! Pipes and Dreamhost's user-facing tools are two examples of
> > actual running code that uses <canvas>, for instance.) Similarly for
> > SVG. This is despite the absence of support for these technologies in
> > the market leader (by installed base).
>
> This is not a good argument, we're looking for an order of magnitude
> more adoption. That is sub-silverlight success.

Sure. It's still early days.


> > Note also that features aren't just added because someone implements
> > it, and features are certainly not kept just because one UA supports
> > it. The SQL stuff was added over my objections due to avid requests
> > from two vendors (Apple and Google) and the lack of any other
> > proposals to address the same use cases
>
> How did they override you? You're the dictator.

No, I'm the editor. There are many things in HTML5 that I don't think are
good ideas, like the allowance for XML-like /> syntax, the SQL database
feature, element.innerHTML for XML nodes, document.write(), quirks mode,
etc. However, I'm not writing the spec to match my personal desires, I'm
writing it based on use cases, logical arguments, research, and reality.


> At any rate, but that absence doesn't mean SQL needs to go in the HTML
> spec. It could be great, give it its own document, maybe it will take
> off. Does that make sense?

Yes; the entire local storage section is already planned for extraction.

sayrer

unread,
Feb 19, 2009, 7:40:36 PM2/19/09
to
On Feb 19, 7:25 pm, Ian Hickson <i...@hixie.ch> wrote:
> On Thu, 19 Feb 2009, sayrer wrote:
> > On Feb 19, 5:46 pm, Ian Hickson <i...@hixie.ch> wrote:
>
> > > I agree that the situation is actually more subtle than my simplistic
> > > description, but it's not quite as simple as you suggest either. For
> > > example, <canvas> is part of the Web now, used in production code.
> > > (Yahoo! Pipes and Dreamhost's user-facing tools are two examples of
> > > actual running code that uses <canvas>, for instance.) Similarly for
> > > SVG. This is despite the absence of support for these technologies in
> > > the market leader (by installed base).
>
> > This is not a good argument, we're looking for an order of magnitude
> > more adoption. That is sub-silverlight success.
>
> Sure. It's still early days.
>
> > > Note also that features aren't just added because someone implements
> > > it, and features are certainly not kept just because one UA supports
> > > it. The SQL stuff was added over my objections due to avid requests
> > > from two vendors (Apple and Google) and the lack of any other
> > > proposals to address the same use cases
>
> > How did they override you? You're the dictator.
>
> No, I'm the editor.

You're the dictator. Am I reading the WHATWG process wrong?

> There are many things in HTML5 that I don't think are
> good ideas, like the allowance for XML-like /> syntax, the SQL database
> feature, element.innerHTML for XML nodes, document.write(), quirks mode,
> etc. However, I'm not writing the spec to match my personal desires, I'm
> writing it based on use cases, logical arguments, research, and reality.

That's not a good explanation for adding to the scope of the document.

>
> > At any rate, but that absence doesn't mean SQL needs to go in the HTML
> > spec. It could be great, give it its own document, maybe it will take
> > off. Does that make sense?
>
> Yes; the entire local storage section is already planned for extraction.

If they shouldn't be there, why did you add them? I confess I don't
actually care what the answer is, and I'm more interested in removing
the ability of anyone to unilaterally add to HTML. Nothing
personal. :)

- Rob

Ian Hickson

unread,
Feb 19, 2009, 7:57:56 PM2/19/09
to sayrer, dev-pl...@lists.mozilla.org
On Thu, 19 Feb 2009, sayrer wrote:
> > >
> > > How did they override you? You're the dictator.
> >
> > No, I'm the editor.
>
> You're the dictator. Am I reading the WHATWG process wrong?

Apparently. A dictator, by definition, has total power. I have nearly no
power; I am contrained by legacy content, by the whims of implementators,
by rational and logical argument, by the needs of authors and users, and
by research.


> > There are many things in HTML5 that I don't think are good ideas, like
> > the allowance for XML-like /> syntax, the SQL database feature,
> > element.innerHTML for XML nodes, document.write(), quirks mode, etc.
> > However, I'm not writing the spec to match my personal desires, I'm
> > writing it based on use cases, logical arguments, research, and
> > reality.
>
> That's not a good explanation for adding to the scope of the document.

It wasn't an explanation for adding to the scope of the document. I was
explaining that the spec doesn't represent my opinion.


> > > At any rate, but that absence doesn't mean SQL needs to go in the
> > > HTML spec. It could be great, give it its own document, maybe it
> > > will take off. Does that make sense?
> >
> > Yes; the entire local storage section is already planned for extraction.
>
> If they shouldn't be there, why did you add them?

I don't really think that the local storage section shouldn't be there; it
is being extracted because people like you think it shouldn't be there.
Personally I'm quite happy with a monolithic spec and would be quite happy
to absorb more specs into it, as I think it leads to higher quality spec
material. However, that's not the direction we're going in.


> I confess I don't actually care what the answer is, and I'm more
> interested in removing the ability of anyone to unilaterally add to
> HTML. Nothing personal. :)

I have no ability to add anything to HTML. Only implementors do.

I don't even have unilateral power to add anything to the HTML5
specification I edit; the WHATWG members have veto power in the WHATWG,
and the W3C working group and W3C staff have veto power in the W3C.

sayrer

unread,
Feb 19, 2009, 8:25:37 PM2/19/09
to
On Feb 19, 7:57 pm, Ian Hickson <i...@hixie.ch> wrote:
> On Thu, 19 Feb 2009, sayrer wrote:
>
> > > > How did they override you? You're the dictator.
>
> > > No, I'm the editor.
>
> > You're the dictator. Am I reading the WHATWG process wrong?
>
> Apparently. A dictator, by definition, has total power.

Incorrect by most definitions, including all of the practical ones.

>
> I don't even have unilateral power to add anything to the HTML5
> specification I edit; the WHATWG members have veto power in the WHATWG,

I don't think you'd find me participating in the W3C if I was happy
with the WHATWG or its board.

You can claim SQL "is planned for extraction" all you want, but that
doesn't change the fact Google is out there marketing "HTML5 Storage
For The iPhone". Given the shoddy rationale for inclusion,
collaboration on WebKit, the fact that your CEO sits on Apple's board,
and the editing model of HTML5, that looks horrible! It doesn't matter
how well-meaning the effort was, and it threatens to compromise the
entire document. I don't have a problem with a JavaScript SQL API, and
I don't want to stop it. It's the "HTML5" part that I'm not going to
put up with.

- Rob

Ian Hickson

unread,
Feb 19, 2009, 9:36:02 PM2/19/09
to sayrer, dev-pl...@lists.mozilla.org
On Thu, 19 Feb 2009, sayrer wrote:
> On Feb 19, 7:57 pm, Ian Hickson <i...@hixie.ch> wrote:
> > On Thu, 19 Feb 2009, sayrer wrote:
> > > > >
> > > > > How did they override you? You're the dictator.
> > > > No, I'm the editor.
> > > You're the dictator. Am I reading the WHATWG process wrong?
> > Apparently. A dictator, by definition, has total power.
>
> Incorrect by most definitions, including all of the practical ones.

Wikipedia, the New Oxford American Dictionary, and answers.com, my three
main sources of definitions, all seem to agree that the term "dictator"
refers to someone who is an absolute ruler.

I don't particularly like semantic quibbling like this, but since this
sounds to me like a personal insult and attack on my work ethic, I do
somewhat take offense here.


> You can claim SQL "is planned for extraction" all you want, but that
> doesn't change the fact Google is out there marketing "HTML5 Storage For
> The iPhone". Given the shoddy rationale for inclusion, collaboration on
> WebKit, the fact that your CEO sits on Apple's board, and the editing
> model of HTML5, that looks horrible! It doesn't matter how well-meaning
> the effort was, and it threatens to compromise the entire document. I
> don't have a problem with a JavaScript SQL API, and I don't want to stop
> it. It's the "HTML5" part that I'm not going to put up with.

o_O

sayrer

unread,
Feb 19, 2009, 9:47:30 PM2/19/09
to
On Feb 19, 9:36 pm, Ian Hickson <i...@hixie.ch> wrote:
> On Thu, 19 Feb 2009, sayrer wrote:
> > On Feb 19, 7:57 pm, Ian Hickson <i...@hixie.ch> wrote:
> > > On Thu, 19 Feb 2009, sayrer wrote:
>
> > > > > > How did they override you? You're the dictator.
> > > > > No, I'm the editor.
> > > > You're the dictator. Am I reading the WHATWG process wrong?
> > > Apparently. A dictator, by definition, has total power.
>
> > Incorrect by most definitions, including all of the practical ones.
>
> Wikipedia, the New Oxford American Dictionary, and answers.com, my three
> main sources of definitions, all seem to agree that the term "dictator"
> refers to someone who is an absolute ruler.

To use one example, the Wikipedia article reflects my opinion. The
term has more nuance than you implied, in my opinion.

<http://en.wikipedia.org/wiki/Dictator>

But beyond that, I should note that I didn't choose the term dictator.
In my conversations with WHATWG board members, that term has been used
freely. It also seems to be used by heavy WHATWG contributors

<http://krijnhoetmer.nl/irc-logs/whatwg/20090202#l-363>

> I don't particularly like semantic quibbling like this, but since this
> sounds to me like a personal insult and attack on my work ethic, I do
> somewhat take offense here.

It was not intended as insult or attack. I apologize for anything that
sounded so. Many communities refer to their "editor" as a "dictator".
Guido van Rossum is one example.

>
>  o_O

I know that message was impolitic. Let me reiterate that it's the
appearance I am concerned about, above all. The motivations of all
parties to the WHATWG seem good.

- Rob

Henri Sivonen

unread,
Feb 20, 2009, 3:25:28 AM2/20/09
to
In article <94GdnWY2L77x9QDU...@mozilla.org>,
Boris Zbarsky <bzba...@mit.edu> wrote:

> Henri Sivonen wrote:
> > But the CSS WG is free to change only those aspects of CSS3 that
> > implementations have not yet converged on.
>
> Since they're implementing with vendor prefixes, this might well not be
> the case, actually... until CR, of course

My point is that the parts of CSS3 that were also in CSS2--perhaps also
in CSS1--and have been interoperable implemented are for all practical
purposes as stable as any Web feature gets even if the CSS3 spec
expression of the features have been marked as Working Draft.

> > Splitting stuff out of HTML5 in order to make it get to REC fast would
> > mean that the part that got to REC would already be obsolete in the
> > sense that it wouldn't accurately capture the new action in the
> > development of the platform even if it were accurate for the older parts.
>
> This might not inherently be a problem.

My concern is this:

From outside the CSS WG, it seems like maintaining a CSS 2.1 spec
expression and a CSS3 spec expression of a given feature, has added
editorial overhead that slows the group down.

I see value in seeing to it that the features contained in CSS 2.1 get
interoperable implementations and have test cases. However, doing this
by maintaining a second spec in addition to CVS HEAD of the CSS3 drafts
seems to have a non-trivial cost due to the split of editorial effort
when the time of competent editors is in short supply.

My guess is that the cost would be less if there were only one spec for
each CSS feature with per-feature annotations of the level of maturity.
That is, I think tracking stability/maturity on the level of documents
instead of on the level of features is too coarse-grained.

The WHATWG copy of HTML5 tracks per-feature maturity and so far it seems
that this method of tracking has a much lower overhead than splitting
every piece that one wants to track separately into a separate spec that
needs to go through chartering, etc.

(Note that I don't think some pure JS API features intuitively belong in
HTML5, but since we don't see editors lining up for these features, I'm
willing to hold my nose if this is the way that at least keeps proposed
platform features specced and the realistic alternative is them falling
into the shady realm of unspecced features--in competing products no
less.)

I fear that splitting a separately maintained CSS 2.1-like "HTML 4.1"
out of HTML5 would lead to a split of effort that would be destructive
to the rate of progress.

However, maintaining only the tip of the spec by human work and
generating snapshot releases for the authoring public at large by using
the per-section annotations mechanically would probably not pose such
danger of split effort.

Furthermore, given the political considerations aired in the "Moving
past last call for HTML5" branch of this thread, I think it would be
premature to debate the proposed alternative take on HTML5 purely on its
technical merit before understanding its political goals.

> > If the purpose is to communicate to authors, why does the document at
> > http://people.mozilla.com/~sayrer/2009/02/15/html5.html
> > include the HTML5 parsing algorithm? Shouldn't authors be shown
> > something like the "Writing" section instead?
>
> Communicating to UA authors is not a bad thing either. It's good to
> know when the spec editor feels they're done with gratuitous changes and
> are waiting on impl feedback. Going to CR announces this, but since
> HTML5 isn't planning to do this for a while...

Don't the annotations in the WHATWG copy of HTML5 and asking on IRC when
in doubt address communication with UA developers sufficiently?

Henri Sivonen

unread,
Feb 20, 2009, 3:25:18 AM2/20/09
to
In article
<294811be-d2ef-4b6c...@v42g2000yqj.googlegroups.com>,
sayrer <say...@gmail.com> wrote:

> Henri Sivonen wrote:
> > Publish in what way? HTML 5 as it exists on any given day is already
> > published in the sense that it is public and anyone can GET in and read
> > it freely.
>
> Sam, Boris, and Robert O'Callahan all made the same points I would
> have.

Do I interpret you correctly when I interpret that to mean that you'd
like the W3C HTML WG put your cut-down draft on the REC track?

Do *you* intend what would be put on the REC track always be a
mechanically-generated subset of the WHATWG instance of HTML 5, or would
entertain the option of additive authorship?

Do *you* want to use it to send signals to implementors and/or Web
authors and/or someone else? What signals?

Henri Sivonen

unread,
Feb 20, 2009, 3:43:58 AM2/20/09
to
In article
<6d2ae224-695c-493d...@41g2000yqf.googlegroups.com>,
sayrer <say...@gmail.com> wrote:

> I don't think you'd find me participating in the W3C if I was happy
> with the WHATWG or its board.

That sentence implies you don't like W3C, either. What kind of structure
for ensuring platform coherence would you like for the open Web
platform? Do you agree that having multiple vendors supply
implementations of the platform while keeping the platform coherent is a
desirable aim?

> You can claim SQL "is planned for extraction" all you want, but that
> doesn't change the fact Google is out there marketing "HTML5 Storage
> For The iPhone". Given the shoddy rationale for inclusion,
> collaboration on WebKit, the fact that your CEO sits on Apple's board,
> and the editing model of HTML5, that looks horrible! It doesn't matter
> how well-meaning the effort was, and it threatens to compromise the
> entire document. I don't have a problem with a JavaScript SQL API, and
> I don't want to stop it. It's the "HTML5" part that I'm not going to
> put up with.

Two browser vendors want to address use case X. Do you agree that it is
Good for the Web if they address it in a uniform way such that Web
authors don't need to do different thing for different browsers when
they want use case X addressed?

If yes, do you agree that it is Good for the Web if they circulate their
design ahead of time so that other vendors who aren't planning on
addressing use case X at this time and other interested parties may
point out design bugs for mutual benefit but aren't able to block the
first-movers from addressing use case X in *some* way?

If still yes, is the problem with SQL storage that competitors are using
the brand of "HTML5" to market a feature that you don't approve of?

If this is the problem, do you see this as mirroring in any way
Mozilla's use of "HTML5" in marketing the upcoming video features of
Firefox 3.1 when seen from the point of view of Microsoft, Apple or
Nokia? Microsoft hasn't appeared too enthusiastic about <video> at all,
and Apple and Nokia have expressed disapproval of the video codec that
Mozilla chose to promote under the HTML5 brand.

How, in your opinion, should Apple and Google have proceeded on the
topic of complex client side storage?

Henri Sivonen

unread,
Feb 20, 2009, 4:29:51 AM2/20/09
to
In article
<4042e89a-4802-4170...@j39g2000yqn.googlegroups.com>,
rubys <ru...@intertwingly.net> wrote:

> On Feb 19, 5:16 am, Henri Sivonen <hsivo...@iki.fi> wrote:
> > In article
> > <6361100b-0d05-4f86-b3d5-87f580073...@n20g2000vba.googlegroups.com>,
> >
> >  sayrer <say...@gmail.com> wrote:
> > > On Feb 18, 5:50 am, Henri Sivonen <hsivo...@iki.fi> wrote:
> >
> > > > I have trouble deciding what I think without knowing what the purpose of
> > > > your document is. What's the goal you are trying to achieve and why?
> >
> > > To publish a document with well defined error handling and a very
> > > select few new features, quickly.
> >
> > Publish in what way? HTML 5 as it exists on any given day is already
> > published in the sense that it is public and anyone can GET in and read
> > it freely.
>
> And contains a number of things that have no consensus and others that
> will change tomorrow.

These are annotated, though.

> You raise a number of valid points on Rob's document. Perhaps it
> could be approached in a different way, and I encourage people to try
> (I will say that doing so is much harder than it might appear to be).

I know it's hard, which is why a have tried to avoid criticizing the way
Hixie does things too much when I haven't been able to show a realistic
better alternative.

> If you look at the list of sections that Rob cut, do we, as a group,
> have consensus that we want to include each and every last one of
> those in the draft we put forward for Last Call this fall, and are we
> confident that we will have zero open issues on each by that time?

Most likely not regardless of how you define consensus.

The lack of two interoperable implementations per feature when moving to
the later stages of the W3C spec maturity is a much more concrete razor
for cutting a feature (later than at first Last Call). (I think two
interoperable implementations of the whole spec is not a useful razor in
any timeframe that the W3C seems to be pursuing.)

sayrer

unread,
Feb 20, 2009, 12:08:07 PM2/20/09
to
On Feb 20, 3:43 am, Henri Sivonen <hsivo...@iki.fi> wrote:
>
> That sentence implies you don't like W3C, either. What kind of structure
> for ensuring platform coherence would you like for the open Web
> platform?

My opinion isn't important. I'm going to stay quiet.

Sam Ruby

unread,
Feb 20, 2009, 9:47:43 AM2/20/09
to dev-pl...@lists.mozilla.org
Ian Hickson wrote:
>
> So consensus -- unanimity -- isn't an interesting goal.

In lieu of continuing to cross-post, those that wish to follow this
particular thread can do so here:

http://lists.w3.org/Archives/Public/www-archive/2009Feb/thread.html#msg82

- Sam Ruby

Boris Zbarsky

unread,
Feb 20, 2009, 12:36:19 PM2/20/09
to
Henri Sivonen wrote:
>>> But the CSS WG is free to change only those aspects of CSS3 that
>>> implementations have not yet converged on.
>> Since they're implementing with vendor prefixes, this might well not be
>> the case, actually... until CR, of course
>
> My point is that the parts of CSS3 that were also in CSS2--perhaps also
> in CSS1--and have been interoperable implemented are for all practical
> purposes as stable as any Web feature gets even if the CSS3 spec
> expression of the features have been marked as Working Draft.

Sure. And in fact they're already covered by existing CRs or RECs.

> From outside the CSS WG, it seems like maintaining a CSS 2.1 spec
> expression and a CSS3 spec expression of a given feature, has added
> editorial overhead that slows the group down.

I'm not convinced that this is what slows the group down, honestly.

> My guess is that the cost would be less if there were only one spec for
> each CSS feature with per-feature annotations of the level of maturity.

Perhaps, though the hard parts come with feature interactions, not
features....

> That is, I think tracking stability/maturity on the level of documents
> instead of on the level of features is too coarse-grained.

While probably true, tracking on the level of features is too
fine-grained unless the features are very orthogonal.

> The WHATWG copy of HTML5 tracks per-feature maturity

It does? That's the first I've heard of it... Which means it's not
obvious from looking at the spec.

> I fear that splitting a separately maintained CSS 2.1-like "HTML 4.1"
> out of HTML5 would lead to a split of effort that would be destructive
> to the rate of progress.

That's true if we task existing editors with the work; not clear about
the situation when someone has volunteered to do it.

> Furthermore, given the political considerations aired in the "Moving
> past last call for HTML5" branch of this thread, I think it would be
> premature to debate the proposed alternative take on HTML5 purely on its
> technical merit before understanding its political goals.

I'm not sure I follow. There are no political goals I see in Robert's
proposal, other than the goal of focusing on things that are closer to
being stable and interoperably implemented or that are needed for
interoperability on existing content.

> Don't the annotations in the WHATWG copy of HTML5 and asking on IRC when
> in doubt address communication with UA developers sufficiently?

Not that I've seen. Asking on IRC is actually about as bad as it gets
if you're working in implementing something: it completely interrupts
your train of thought, requires a synchronous response at possibly
inconvenient times, needs a net connection, etc.

I've never seen any of the annotations you mention, so I can't say that
they address the issue either. I've certainly seen notes to the effect
that something is unstable, but there are plenty of things without such
notes that don't seem very stable to me either.

-Boris

fantasai

unread,
Feb 20, 2009, 3:54:20 PM2/20/09
to Henri Sivonen
Henri Sivonen wrote:
>
> Non-rhetorical question: If one works on style system or layout code,
> does it make more sense to read CSS 2.1 or to read the latest Editor's
> Draft of the relevant CSS3 spec?

Depends on which CSS3 spec. CSS2.1 + errata is always up-to-date and
accurate for the things it defines. For the things it doesn't define,
reading the CSS3 draft may or may not be helpful depending on how
mature and how outdated it is. There's a lot of stuff in CSS3 drafts
that will eventually get either thrown out or rewritten.

~fantasai

fantasai

unread,
Feb 20, 2009, 4:51:53 PM2/20/09
to Henri Sivonen
Henri Sivonen wrote:
> In article <94GdnWY2L77x9QDU...@mozilla.org>,
> Boris Zbarsky <bzba...@mit.edu> wrote:
>
>> Henri Sivonen wrote:
>>> But the CSS WG is free to change only those aspects of CSS3 that
>>> implementations have not yet converged on.
>> Since they're implementing with vendor prefixes, this might well not be
>> the case, actually... until CR, of course
>
> My point is that the parts of CSS3 that were also in CSS2--perhaps also
> in CSS1--and have been interoperable implemented are for all practical
> purposes as stable as any Web feature gets even if the CSS3 spec
> expression of the features have been marked as Working Draft.

Right. And that's why those features are expressed as CR via the CSS2.1
spec.

> From outside the CSS WG, it seems like maintaining a CSS 2.1 spec
> expression and a CSS3 spec expression of a given feature, has added
> editorial overhead that slows the group down.
>
> I see value in seeing to it that the features contained in CSS 2.1 get
> interoperable implementations and have test cases. However, doing this
> by maintaining a second spec in addition to CVS HEAD of the CSS3 drafts
> seems to have a non-trivial cost due to the split of editorial effort
> when the time of competent editors is in short supply.
>
> My guess is that the cost would be less if there were only one spec for
> each CSS feature with per-feature annotations of the level of maturity.
> That is, I think tracking stability/maturity on the level of documents
> instead of on the level of features is too coarse-grained.

Given the current level of stability for CSS2.1, I've found the cost of
keeping a CSS2.1 and CSS3 draft of the same feature in sync to be trivial.

The one area where this would not be the case would be the box model,
i.e. chapters 8-10 in CSS2.1. That section is extremely complex, has been
pretty much rewritten for CSS3, gets tons of issues, and hasn't been sync'd
up in years. But you can't really do per-feature annotations for the box
model anyway, because "features" in the box model description are hard to
separate out. (You'd have to mark stability by sentence, which would just
be absurd.)

As for splitting things into independent modules and levels, I'm very,
very glad we did it. Working with a monolithic spec might be efficient
for hixie, but I just cannot wrap my head around something like that.
I edit multiple specs, and I'm glad that they're not one file, and get
published independently, etc. There are many things that slow me down,
but editorial overhead from splitting specs isn't one of them. It makes
it easier to publish drafts, easier to gather feedback, easier to track
progress, and easier to lock down CSS3, stable subset by stable subset.

I'm not going to argue about the best way for the HTMLWG/WHATWG to work,
but I think the CSSWG has a system that works well enough for it. Our
primary struggle is locking down 2.1, and the discussions surrounding its
issues are the primary time sink for me.

~fantasai

Ian Hickson

unread,
Feb 20, 2009, 5:30:58 PM2/20/09
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On Fri, 20 Feb 2009, Boris Zbarsky wrote:
> >
> > The WHATWG copy of HTML5 tracks per-feature maturity
>
> It does? That's the first I've heard of it... Which means it's not
> obvious from looking at the spec.

Little boxes in the left margin. They also show which of the major
browsers support the features, and have boxes for links to test cases and
demos, though those are rarely used right now. Anyone can edit the boxes,
alt-double-click on them to bring up the editor.

I welcome suggestions for making them more obvious. Not sure how to do it.

Jeff Walden

unread,
Feb 20, 2009, 8:27:48 PM2/20/09
to Henri Sivonen
On 20.2.09 00:25, Henri Sivonen wrote:
> (Note that I don't think some pure JS API features intuitively belong in
> HTML5, but since we don't see editors lining up for these features, I'm
> willing to hold my nose if this is the way that at least keeps proposed
> platform features specced and the realistic alternative is them falling
> into the shady realm of unspecced features--in competing products no
> less.)

This is what most worries me about the current process (which, in most other respects, I find works well and has produced quite good results).

Just because one vendor implements something doesn't mean it automatically deserves to be specified, nor does it mean that a halfway proposal, once implemented by one vendor, need not carry its own weight in progressing toward well-definedness to remain in the HTML5 draft. For an example of the latter, consider the current database functionality: the complete absence of a definition of the syntax of the SQL string to be executed makes it a total non-starter as part of HTML5 at this point in my book.

I don't think it's right to keep something in HTML5 just because it's useful functionality that nobody else is willing to drive to completion. That produces a moral hazard of competent editors not stepping forward because it's less effort to keep such features in "holding patterns" than to actually do the legwork to make them implementable. Continuing the database example, without a SQL-subset syntax definition, or without at least a strong start on it, I don't think databasing as currently in HTML5 is implementable in a way that's even facially vendor-neutral.

If no one else is willing to edit a feature that requires little effort to extract from HTML5 and that doesn't have complex interactions with fundamental HTML5 processes or (potentially new but fundamental) concepts (parsing most obviously, callback lifetimes as one more example), it doesn't deserve the false accreditation currently being in HTML5 (or even temporarily being standardized there) gives it.

Jeff

Smaug

unread,
Feb 21, 2009, 10:19:28 AM2/21/09
to Ian Hickson, dev-pl...@lists.mozilla.org
On 2/21/09 12:30 AM, Ian Hickson wrote:
> On Fri, 20 Feb 2009, Boris Zbarsky wrote:
>>> The WHATWG copy of HTML5 tracks per-feature maturity
>> It does? That's the first I've heard of it... Which means it's not
>> obvious from looking at the spec.
>
> Little boxes in the left margin. They also show which of the major
> browsers support the features, and have boxes for links to test cases and
> demos, though those are rarely used right now. Anyone can edit the boxes,
> alt-double-click on them to bring up the editor.
>
> I welcome suggestions for making them more obvious. Not sure how to do it.
>

Just as an example, saying that some feature is "Marked for extraction"
doesn't say much about its maturity.


-Olli

Ian Hickson

unread,
Feb 22, 2009, 12:22:20 AM2/22/09
to Smaug, dev-pl...@lists.mozilla.org

Good point. Fixed. Thanks.

Henri Sivonen

unread,
Feb 22, 2009, 7:52:53 AM2/22/09
to
In article <499F5894...@mit.edu>,
Jeff Walden <jwald...@mit.edu> wrote:

> On 20.2.09 00:25, Henri Sivonen wrote:
> > (Note that I don't think some pure JS API features intuitively belong in
> > HTML5, but since we don't see editors lining up for these features, I'm
> > willing to hold my nose if this is the way that at least keeps proposed
> > platform features specced and the realistic alternative is them falling
> > into the shady realm of unspecced features--in competing products no
> > less.)
>
> This is what most worries me about the current process (which, in most other
> respects, I find works well and has produced quite good results).
>
> Just because one vendor implements something doesn't mean it automatically
> deserves to be specified,

I disagree. I think it's important for all additions to the platform to
have a spec that is precise enough and patent/copyright-wise free enough
to allow the next vendor who whatever reason wants to address the same
use case implement the same solution interoperably by reading from the
spec and without resorting to extensive reverse engineering of the
first-mover implementation.

It doesn't follow, though, that any organization in the business of
issuing de jure endorsements of features needs to endorse such a spec,
and it doesn't follow that the spec needs to be rolled into "HTML 5".

> nor does it mean that a halfway proposal, once
> implemented by one vendor, need not carry its own weight in progressing
> toward well-definedness to remain in the HTML5 draft. For an example of the
> latter, consider the current database functionality: the complete absence of
> a definition of the syntax of the SQL string to be executed makes it a total
> non-starter as part of HTML5 at this point in my book.

I see this as a point in favor for having things specced from early on
rather as a point showing that speccing single-vendor additions isn't
deserved.

I do think that it's bad that SQL storage feature lacks a definition for
the flavor of SQL used and a forward-compatibility story for evolving
the flavor.

> I don't think it's right to keep something in HTML5 just because it's useful
> functionality that nobody else is willing to drive to completion.

I don't think it is right, either.

However, not having a Hixie-quality spec even for the database API would
be worse than having the API specced. To a large extent this is an issue
of how much interim (well, hopefully interim) 'not right' one is willing
to tolerate when the realistic alternative would mean unspecced things
getting added to sides of implementations of the interoperable platform
if other competent and willing editors aren't stepping up.

> That
> produces a moral hazard of competent editors not stepping forward because
> it's less effort to keep such features in "holding patterns" than to actually
> do the legwork to make them implementable. Continuing the database example,
> without a SQL-subset syntax definition, or without at least a strong start on
> it, I don't think databasing as currently in HTML5 is implementable in a way
> that's even facially vendor-neutral.

I'm not asking you to name names here, but is there a concrete reason on
the level of knowing a potential person to believe that another editor
would have stepped up for the SQL part if the API part weren't in a
'holding pattern'?

There is precedent to successful (XHR) and unsuccessful (window object)
spec splitting in the context of HTML5 when editors have stepped up.

Also, it seems to me that while the situation is largely about editors,
it's also about the overhead of getting copyright and patent policy
sorted out if a given passage of text goes into a new deliverable
instead of going into a catch-all existing one.

> If no one else is willing to edit a feature that requires little effort to
> extract from HTML5 and that doesn't have complex interactions with
> fundamental HTML5 processes or (potentially new but fundamental) concepts
> (parsing most obviously, callback lifetimes as one more example), it doesn't
> deserve the false accreditation currently being in HTML5 (or even temporarily
> being standardized there) gives it.

This raises the question of what things *should* be accredited by HTML5.
Can we come up with criteria that isn't awfully subjective and that
doesn't generate into doing merely an HTML 4.1? I think disagreeing so
much that all that's left is roughly an HTML 4.1 would be a huge PR
blunder now that HTML5 is enjoying positive buzz to the point that HTML5
represents all the cool new things--so much so that once in a while new
features that haven't, in fact, ever been in any HTML 5 draft get
characterized as "HTML5 foo". (I tried to search for an example of
someone saying "HTML5 Selectors API", but I couldn't find it any longer.)

That said, I agree with your point on the level of principle. However,
in practice, it is a problem if vendors have more willingness to
implement and ship than to contribute editors for the features they
ship. That is, I don't think it is a satisfactory solution to leave
things unspecced when a vendor willing to ship isn't contributing an
editor also.

But yeah, such failure to contribute an editor should probably not be
rewarded by having things fall under the HTML5 brand as the *fallback*.

Now we also have a new case to study. There's a different Hixie spec
that wasn't edited under the HTML5 brand: Web Workers. It was also
driven by a couple of first-mover vendors, although in this case Mozilla
was one of them. Perhaps it would be useful to analyze what went right
and what went wrong about Workers and then use this data to develop a
better mode of working for new platform features whose dependencies are
mostly around the security model and window object general area.

I observe that the spec got the the point of implementations being
roughly ready to ship at the WHATWG before the W3C Web Apps WG managed
to perform enough of a charter dance to get the spec under the W3C
Patent Policy.

Henri Sivonen

unread,
Feb 22, 2009, 7:52:58 AM2/22/09
to
In article <dZydnXfs1q2OdwPU...@mozilla.org>,
Boris Zbarsky <bzba...@mit.edu> wrote:

> Henri Sivonen wrote:
> >>> But the CSS WG is free to change only those aspects of CSS3 that
> >>> implementations have not yet converged on.
> >> Since they're implementing with vendor prefixes, this might well not be
> >> the case, actually... until CR, of course
> >
> > My point is that the parts of CSS3 that were also in CSS2--perhaps also
> > in CSS1--and have been interoperable implemented are for all practical
> > purposes as stable as any Web feature gets even if the CSS3 spec
> > expression of the features have been marked as Working Draft.
>
> Sure. And in fact they're already covered by existing CRs or RECs.

Which leads to a situation of having multiple potentially contradictory
specs to read that cover the same feature.

> > From outside the CSS WG, it seems like maintaining a CSS 2.1 spec
> > expression and a CSS3 spec expression of a given feature, has added
> > editorial overhead that slows the group down.
>
> I'm not convinced that this is what slows the group down, honestly.

Perhaps my outside view of the group isn't perceptive enough to make CSS
a relevant example.

> > The WHATWG copy of HTML5 tracks per-feature maturity
>
> It does? That's the first I've heard of it... Which means it's not
> obvious from looking at the spec.

I think it's a problem if it's not obvious. Do you have suggestions on
how to make it more obvious?

(At least here, the delay before the annotations show up is rather
large.)

> > I fear that splitting a separately maintained CSS 2.1-like "HTML 4.1"
> > out of HTML5 would lead to a split of effort that would be destructive
> > to the rate of progress.
>
> That's true if we task existing editors with the work; not clear about
> the situation when someone has volunteered to do it.

That depends on how much attention it takes from the rest of the group.

Personally, I'm also concerned about whether publishing a HTML "4.1" or
somesuch would result in demand for more validation targets in
Validator.nu.

> > Furthermore, given the political considerations aired in the "Moving
> > past last call for HTML5" branch of this thread, I think it would be
> > premature to debate the proposed alternative take on HTML5 purely on its
> > technical merit before understanding its political goals.
>
> I'm not sure I follow. There are no political goals I see in Robert's
> proposal, other than the goal of focusing on things that are closer to
> being stable and interoperably implemented or that are needed for
> interoperability on existing content.

Perhaps "political" isn't the right word, but the concern about who gets
to use the HTML5 brand for marketing what and how executive and board
overlaps are relevant to this question doesn't seem like a technical
issue to me.
http://groups.google.com/group/mozilla.dev.platform/msg/adaf80378662ea08

> > Don't the annotations in the WHATWG copy of HTML5 and asking on IRC when
> > in doubt address communication with UA developers sufficiently?
>
> Not that I've seen. Asking on IRC is actually about as bad as it gets
> if you're working in implementing something: it completely interrupts
> your train of thought, requires a synchronous response at possibly
> inconvenient times, needs a net connection, etc.

I meant asking about stability when deciding what to implement next. I
didn't mean that IRC should be used as a preferred mode of information
transfer when implementing a given feature.

Henri Sivonen

unread,
Feb 22, 2009, 8:08:19 AM2/22/09
to
In article <499F25F9...@inkedblade.net>,
fantasai <fantasa...@inkedblade.net> wrote:

> Henri Sivonen wrote:
> > In article <94GdnWY2L77x9QDU...@mozilla.org>,
> > Boris Zbarsky <bzba...@mit.edu> wrote:
> >
> >> Henri Sivonen wrote:
> >>> But the CSS WG is free to change only those aspects of CSS3 that
> >>> implementations have not yet converged on.
> >> Since they're implementing with vendor prefixes, this might well not be
> >> the case, actually... until CR, of course
> >
> > My point is that the parts of CSS3 that were also in CSS2--perhaps also
> > in CSS1--and have been interoperable implemented are for all practical
> > purposes as stable as any Web feature gets even if the CSS3 spec
> > expression of the features have been marked as Working Draft.
>
> Right. And that's why those features are expressed as CR via the CSS2.1
> spec.

I think it at least somewhat a problem if a reader needs to cross-check
which parts of a given CSS3 module are also in CSS 2.1.

> > From outside the CSS WG, it seems like maintaining a CSS 2.1 spec
> > expression and a CSS3 spec expression of a given feature, has added
> > editorial overhead that slows the group down.
> >
> > I see value in seeing to it that the features contained in CSS 2.1 get
> > interoperable implementations and have test cases. However, doing this
> > by maintaining a second spec in addition to CVS HEAD of the CSS3 drafts
> > seems to have a non-trivial cost due to the split of editorial effort
> > when the time of competent editors is in short supply.
> >
> > My guess is that the cost would be less if there were only one spec for
> > each CSS feature with per-feature annotations of the level of maturity.
> > That is, I think tracking stability/maturity on the level of documents
> > instead of on the level of features is too coarse-grained.
>
> Given the current level of stability for CSS2.1, I've found the cost of
> keeping a CSS2.1 and CSS3 draft of the same feature in sync to be trivial.
>
> The one area where this would not be the case would be the box model,
> i.e. chapters 8-10 in CSS2.1. That section is extremely complex, has been
> pretty much rewritten for CSS3, gets tons of issues, and hasn't been sync'd
> up in years.

Having multiple separately edited releases of HTML with syncing failures
is something that I think the HTML WG should avoid.

> But you can't really do per-feature annotations for the box
> model anyway, because "features" in the box model description are hard to
> separate out. (You'd have to mark stability by sentence, which would just
> be absurd.)

Sure, there are large intertwingled areas. However, in the case of CSS,
each selector is pretty much an independently trackable feature. Also,
many properties or many smallish groups of properties are for practical
purposes independently trackable features.

In HTML5, <canvas> and <video>, for example, can very well have their
stability/maturity tracked individually.

> As for splitting things into independent modules and levels, I'm very,
> very glad we did it. Working with a monolithic spec might be efficient
> for hixie, but I just cannot wrap my head around something like that.
> I edit multiple specs, and I'm glad that they're not one file, and get
> published independently, etc. There are many things that slow me down,
> but editorial overhead from splitting specs isn't one of them. It makes
> it easier to publish drafts, easier to gather feedback, easier to track
> progress, and easier to lock down CSS3, stable subset by stable subset.
>
> I'm not going to argue about the best way for the HTMLWG/WHATWG to work,
> but I think the CSSWG has a system that works well enough for it. Our
> primary struggle is locking down 2.1, and the discussions surrounding its
> issues are the primary time sink for me.

I guess the issue of having a monolithic spec or having multiple modules
is something that doesn't have an objective right solution. As an
editor, you say that modules work better for you. Hixie says a
monolithic spec works better for him. As a reader, prefer loading the
single-page version of HTML5 into a browser window over having to open
multiple CSS3 modules or having to navigate across multiple pages of SVG
1.1 spec. (In the case of SVG 1.1, I tend to prefer the single-file PDF
over the multiple HTML files!) However, many other readers dislike the
single-page version of HTML5 and prefer the multi-page version.

sayrer

unread,
Feb 22, 2009, 3:38:39 PM2/22/09
to
On Feb 22, 8:08 am, Henri Sivonen <hsivo...@iki.fi> wrote:
>
> Having multiple separately edited releases of HTML with syncing failures
> is something that I think the HTML WG should avoid.

That is a very roundabout way of saying "stop". I'm not saying Ian
should stop.

With time, it will be clear which documents will be able to progress.

- Rob

Henri Sivonen

unread,
Feb 23, 2009, 2:27:44 AM2/23/09
to
In article
<a974f5dc-2b2a-4045...@v39g2000yqm.googlegroups.com>,
sayrer <say...@gmail.com> wrote:

> On Feb 22, 8:08 am, Henri Sivonen <hsivo...@iki.fi> wrote:
> >
> > Having multiple separately edited releases of HTML with syncing failures
> > is something that I think the HTML WG should avoid.
>
> That is a very roundabout way of saying "stop". I'm not saying Ian
> should stop.

I'm not trying to be roundabout here. Also, I'm not trying to
communicate with terms like "stop".

You haven't been very forthcoming about your intentions regarding your
draft (as opposed to referring to what others have said). Without
knowing which direction it is supposed to go and why, in the plan of the
person who produced it, it is effectively a Rorschach test that elicits
projections of feelings about how HTML5 has been developed and perhaps
even about other previous interaction with Hixie.

I explored the plausible space of where your draft might be headed, and
stated that I think one of those plausible directions should be avoided
in my opinion.

If you read this as me telling you to stop, I conclude that positioning
your draft as a separately-edited HTML WG release of HTML with potential
syncing failures is indeed a direction you are considering as a possible
way forward.

sayrer

unread,
Feb 23, 2009, 11:56:21 AM2/23/09
to
On Feb 23, 2:27 am, Henri Sivonen <hsivo...@iki.fi> wrote:
>
> If you read this as me telling you to stop, I conclude that positioning
> your draft as a separately-edited HTML WG release of HTML with potential
> syncing failures is indeed a direction you are considering as a possible
> way forward.

Oh, you mean separately edited as in separately from WHATWG. Yes, I
certainly am considering that, though anything I work on would be
available under the same license that the WHATWG document is. To me,
that makes some sense, since most of the WHATWG discussion this month
has focused on features that aren't in my document. Also, "potential
syncing failures" sounds like an accident. Those happen, but some
divergences might be intentional, on either side.

- Rob

Boris Zbarsky

unread,
Feb 23, 2009, 3:29:10 PM2/23/09
to
Ian Hickson wrote:
> Little boxes in the left margin.

Oh, that's interesting. They don't show up until the whole document has
loaded, by which point I have generally done a full-text search for
the thing I want and scrolled down to a point where the little box for
that section is above my viewport (and the one for the next section is
below it). So I had in fact never seen these. The usual "sidebar
blindness" might have contributed too, of course.

What would be best in terms of scrolling behavior is if the box for each
section "stuck" to the top of the viewport as long as the top of the
viewport is between the top and bottom of the section. Not sure how to
accomplish that, that, though without JS hiding/showing the boxes based
on vertical position in the document or something.

-Boris

Smaug

unread,
Feb 21, 2009, 10:19:28 AM2/21/09
to Ian Hickson, dev-pl...@lists.mozilla.org
On 2/21/09 12:30 AM, Ian Hickson wrote:
> On Fri, 20 Feb 2009, Boris Zbarsky wrote:
>>> The WHATWG copy of HTML5 tracks per-feature maturity
>> It does? That's the first I've heard of it... Which means it's not
>> obvious from looking at the spec.
>
> Little boxes in the left margin. They also show which of the major
> browsers support the features, and have boxes for links to test cases and
> demos, though those are rarely used right now. Anyone can edit the boxes,
> alt-double-click on them to bring up the editor.
>
> I welcome suggestions for making them more obvious. Not sure how to do it.
>

Just as an example, saying that some feature is "Marked for extraction"

doesn't say much about its maturity.


-Olli

Brad Neuberg

unread,
Feb 23, 2009, 5:12:50 PM2/23/09
to

>
> Little boxes in the left margin. They also show which of the major
> browsers support the features, and have boxes for links to test cases and
> demos, though those are rarely used right now. Anyone can edit the boxes,
> alt-double-click on them to bring up the editor.
>
> I welcome suggestions for making them more obvious. Not sure how to do it.

Small suggestion: don't just show browser support, but have an icon
that represents JavaScript or third-party shims such as Gears which
implement this feature for browsers. For example, if we ever make an
HTML 5 Video shim that uses Flash 9+ features internally to have it do
H.264 for example, it would be nice to indicate this in the spec as
implementation experience for the HTML 5 Video tag.

Boris Zbarsky

unread,
Feb 23, 2009, 10:42:17 PM2/23/09
to
Henri Sivonen wrote:
> Which leads to a situation of having multiple potentially contradictory
> specs to read that cover the same feature.

That happens no matter what. :)

It's pretty simple in practice: use the spec that's stable unless you're
trying to implement the cutting-edge version.

> I think it's a problem if it's not obvious. Do you have suggestions on
> how to make it more obvious?
>
> (At least here, the delay before the annotations show up is rather
> large.)

Yeah. I commented on this elsewhere in this thread.

> Perhaps "political" isn't the right word, but the concern about who gets
> to use the HTML5 brand for marketing what and how executive and board
> overlaps are relevant to this question doesn't seem like a technical
> issue to me.
> http://groups.google.com/group/mozilla.dev.platform/msg/adaf80378662ea08

True; it's a process issue. Though there is a technical issue in terms
of what can be called HTML5, of course...

> I meant asking about stability when deciding what to implement next.

This assumes a from-scratch implementation. The usual context in which
I need stability information is that I'm changing some code in Gecko
anyway (to fix a bug that got filed) and I want to know whether to go
ahead and make it follow the HTML5 draft as long as I'm there. Looking
for people on irc to answer that question is equivalent to a "no" answer
as far as I'm concerned: just fix the issue at hand, and push off
worrying about HTML5 to later.

-Boris

Henri Sivonen

unread,
Feb 24, 2009, 4:36:09 AM2/24/09
to
In article
<146d819b-45de-4b08...@m15g2000vbp.googlegroups.com>,
sayrer <say...@gmail.com> wrote:

> On Feb 23, 2:27 am, Henri Sivonen <hsivo...@iki.fi> wrote:
> >
> > If you read this as me telling you to stop, I conclude that positioning
> > your draft as a separately-edited HTML WG release of HTML with potential
> > syncing failures is indeed a direction you are considering as a possible
> > way forward.
>
> Oh, you mean separately edited as in separately from WHATWG.

By separately edited I mean that a person makes a copy of the document
and makes edits to it as opposed to a person writing a program that can
generate another document from one directly human-edited source document
every day.

For example, I don't consider the single-page WHATWG spec, the W3C spec
and their multipage versions separately edited, because they are all
programmatically generated from a single human-edited source file.

It wasn't clear if your draft was meant to show a human-edited fork, a
prototype of a programmatically pruned view or a wish where you'd like
the single spec to go.

> Yes, I
> certainly am considering that, though anything I work on would be
> available under the same license that the WHATWG document is. To me,
> that makes some sense, since most of the WHATWG discussion this month
> has focused on features that aren't in my document.

To give an example of a syncing failure I'd care about: There was a
subtle edit to the tree building section less than 24 hours ago. That
section is in your document. If there were two different drafts with
this section, I'd have to decide which one I'd track when implementing.

> Also, &