An alternate take on HTML5
sayrer
<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
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
<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
>
> 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
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
> 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
> 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
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
>
> 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?
>
> 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
> 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
> 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
> > 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
>
> 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
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
<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
> 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
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
> 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
> 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
> 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
> 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
rubys
> 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
> - Rob
>
> [1]http://philip.html5.org/tests/canvas/suite/tests/
- Sam Ruby
Ian Hickson
>
> 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
>
> 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
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
>
> 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
> >
> > 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
> 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
> > >
> > > 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
> 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