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
Ian Hickson
> 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
> 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
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
<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
<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
<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
>
> 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
>
> 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
>>> 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
>
> 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
> 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
> >
> > 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
> (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
> 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
Good point. Fixed. Thanks.
Henri Sivonen
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
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
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
>
> 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
<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
>
> 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
> 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
>>> 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
>
> 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
> 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
<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, "potential syncing failures" sounds like an accident. Those happen,
It would be highly unlikely if they didn't happen in the
human-maintained fork case.
Then the question is what to do about the cost of remedying these
accidents. As far as I can tell, the only way to avoid the cost from
spreading onto the WG, other reviewers and implementors is to treat all
but one of the competing documents the way XHTML 1.2 is treated (i.e.
not reading it carefully and not implementing it).
The process of seeing which documents take roles similar to XHTML 1.2
could be damaging to the group.
> but some divergences might be intentional, on either side.
How would you suggest Mozilla contributors choose which intentionally
divergent fork to honor in code?
You have previously mentioned 'moral hazard' in the context of HTML5
blessing things instead of them carrying their own weight. How would you
avoid a similar 'hazard' regarding the choice of which intentionally
divergent fork of HTML5 Mozilla contributors should implement if one of
the forks is affiliated with Mozilla?
In article <NqqdnU9Go8sE8T7U...@mozilla.org>,
Boris Zbarsky <bzba...@mit.edu> wrote:
> 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. :)
I think making it happen more is something to be avoided.
Ian Hickson
I've tried to implement this, let me know if there's anything else I can
do to help.
Simon Pieters also went through today and added a bunch of annotations to
sections that weren't previously filled in, which should help make this
more useful too.
Ian Hickson
I added a Shims icon for this purpose.
sayrer
>
> > but some divergences might be intentional, on either side.
>
> How would you suggest Mozilla contributors choose which intentionally
> divergent fork to honor in code?
I don't think it is healthy to shut down a proposal by decrying its
existence.
- Rob
Henri Sivonen
<7562ab2a-b1d6-4063...@17g2000vbf.googlegroups.com>,
sayrer <say...@gmail.com> wrote:
I think the part you quoted isn't decrying the existence of your
proposal. It's a very relevant question *given* the existence. I think
it's particularly relevant considering the stated purpose of this
thread. ("I want to know what the Mozilla community thinks.")
(I still don't know what kind of trajectory is being proposed
exactly--all I can see is a point on a trajectory and then I can imagine
various possible trajectories that share the point.)
However, the point I made about the cost on the HTML WG might be fairly
characterized as decrying the existence of your proposal provided that
it is offered as a HTML WG deliverable and provided that it might
intentionally diverge from the current main deliverable of the HTML WG.
I think it's not healthy to fork HTML5 at this point. I think forking is
a last-resort remedy to a very big annoyance, and I think we aren't even
near the kind of annoyance level or near the exhaustion of other
available remedies to smaller annoyances that forking would be the right
step to take.
sayrer
>
> I think the part you quoted isn't decrying the existence of your
> proposal. It's a very relevant question *given* the existence. I think
> it's particularly relevant considering the stated purpose of this
> thread. ("I want to know what the Mozilla community thinks.")
You're assuming both specs will reach a stable state. I don't think
that will be the case. In fact, my bet is on Hixie. That said, I'm
quite content to use my document as a staging ground for edits that
elide the rampant editorializing you'll find in the WHATWG document.
http://html5.org/tools/web-apps-tracker?from=2857&to=2858
>
> (I still don't know what kind of trajectory is being proposed
> exactly--all I can see is a point on a trajectory and then I can imagine
> various possible trajectories that share the point.)
Same here.
> I think it's not healthy to fork HTML5 at this point. I think forking is
> a last-resort remedy to a very big annoyance, and I think we aren't even
> near the kind of annoyance level or near the exhaustion of other
> available remedies to smaller annoyances that forking would be the right
> step to take.
Forking is very unpleasant. Forking pressure is normal. For dictators,
it's part of the job.
- Rob
Ian Hickson
>
> You're assuming both specs will reach a stable state. I don't think that
> will be the case. In fact, my bet is on Hixie. That said, I'm quite
> content to use my document as a staging ground for edits that elide the
> rampant editorializing you'll find in the WHATWG document.
>
> http://html5.org/tools/web-apps-tracker?from=2857&to=2858
While I am a supporter of "4.1" or whatever we end up calling your
document, I should clarify that the above edit wasn't a result of that
document. I actually hadn't realised you'd removed that section (it would
be helpful to have a copy of your document that's gone through the
postprocessor so that we can look at the table of contents). The section
was removed because Sam suggested that removing it would be a significant
aid in helping him get consensus on the draft for Last Call, and because
the value of the section did not justify the effort it would take to
phrase it in a way that would address the complaints while still conveying
the original message.
In short: I just didn't care enough. :-)
sayrer
>
> While I am a supporter of "4.1" or whatever we end up calling your
> document, I should clarify that the above edit wasn't a result of that
> document. I actually hadn't realised you'd removed that section
Sam's message on the matter pointed out that I did... guess you didn't
read that part.
>
> In short: I just didn't care enough. :-)
Thanks for clearing that up.
While I appreciate the contributions you and Henri make to Mozilla, I
was hoping this thread wouldn't be dominated by people who hang out in
the #whatwg irc channel.
- Rob
Jonas Sicking
> 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.
My feelings are this:
If you want to spend time on this then I'm all for it. As long as
everyone realizes that if this thing doesn't pan out, for example it
doesn't progress faster than HTML5, we might end up dropping it.
I think that the fact that HTML5 adds new features is adding relatively
little to the total time it will take to complete. For example I think
much more time is spent on defining Window than defining <video>. Hixie
would know better for sure.
My experience from XMLHttpRequest Level 1 was that it was basically
impossible to create a spec that was small enough that it contained no
controversial stuff. There's always controversial stuff since
implementations are so different. For example HTML parsing is going to
have to change significantly in all (possibly all but one) browser.
So while I think you'll be able to not have to worry about some issues,
such as <video> or the existence of @summary, I think it'll take
significant time still to create a useful HTMLX.Y spec.
/ Jonas
Ian Hickson
>
> I think that the fact that HTML5 adds new features is adding relatively
> little to the total time it will take to complete. For example I think
> much more time is spent on defining Window than defining <video>. Hixie
> would know better for sure.
Most of the time on any particular feature is spent waiting for feedback.
HTML5 today has roughly the scope that allows me to fill in the downtime
waiting for feedback on any particular feature with time spent editing
another feature. I don't think any one feature would progress much faster
than any other feature. There might be some variance, but not much. Case
in point: XHR used to be in HTML5, and even after being taken out and
having its own editor, it's been progressing at more or less the same
speed (give or take a year or so) as the rest of HTML5. Even the Selectors
API, which used to be just an issue marker in HTML5, and which is
theoretically a really simple and uncontroversial component, took several
years to get to where it is now, and it's not done yet (almost, though!).
Martijn
> On Wed, 25 Feb 2009, Jonas Sicking wrote:
>>
>> little to the total time it will take to complete. For example I think
>> much more time is spent on defining Window than defining <video>. Hixie
>> would know better for sure.
>
Well, the last times I commented about this or that on the html5
mailing list, I got an answer in something like 7 months or so.
Also, it was sometimes mangled within other responses.
> HTML5 today has roughly the scope that allows me to fill in the downtime
> waiting for feedback on any particular feature with time spent editing
> another feature. I don't think any one feature would progress much faster
> than any other feature. There might be some variance, but not much. Case
> in point: XHR used to be in HTML5, and even after being taken out and
> having its own editor, it's been progressing at more or less the same
> speed (give or take a year or so) as the rest of HTML5. Even the Selectors
> API, which used to be just an issue marker in HTML5, and which is
> theoretically a really simple and uncontroversial component, took several
> years to get to where it is now, and it's not done yet (almost, though!).
Any chance the name could be changed?
Regards,
Martijn
> --
> Ian Hickson U+1047E )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Robert O'Callahan
> While I appreciate the contributions you and Henri make to Mozilla, I
> was hoping this thread wouldn't be dominated by people who hang out in
> the #whatwg irc channel.
Perhaps not surprising, since people who care about HTML5 tend to hang
out in the #whatwg channel.
Rob
sayrer
Initially, the WHATWG folks developed a good response to an out of
touch standards body:
"Real browser vendors, who have to deal with the ugly web as it is,
know better."
<http://weblogs.mozillazine.org/roadmap/archives/005632.html>
Dealing with that problem is not a prescriptivist task.
Sometime since 2004, the mission has creeped in several directions.
During the same time period, it became impossible to discuss material
changes to the approach without being shouted down by the same 5 or 10
people. Maybe shouting is a bad word for it. But the approach of
drowning people in minutiae while (unintentionally?) ignoring the
point they were making is well known. I don't need to start a thread
in this group to hear that stuff. It is available from several web
sites.
I was interested in hearing from people outside that group.
- Rob
Ian Hickson
>
The mission from 2003 hasn't changed that much. The name of the spec has,
but that's about it. The mission has always been to provide new
technologies for Web applications, starting with forms and then covering
APIs and extensions to HTML, while defining what we can of the vagueness
of the earlier specs. If anything, the scope creep has been in the
opposite direction (towards defining the old stuff in more detail); for
example initially I laughed at the idea of defining HTML parsing, and IIRC
I didn't seriously consider actually doing that until late 2006.
> During the same time period, it became impossible to discuss material
> changes to the approach without being shouted down by the same 5 or 10
> people. Maybe shouting is a bad word for it. But the approach of
> drowning people in minutiae while (unintentionally?) ignoring the point
> they were making is well known.
Please don't confuse disagreement with ignoring. The WHATWG was explicitly
set up with a promise that all feedback would be replied to, and I've been
sticking to that promise religiously, and I've worked hard to try to
understand all feedback (including yours), as have many others.
To reiterate, though, I am a supporter of your "HTML 4.1" effort (or
whatever we call it). I just wanted to clarify some points of historical
interest, so that we don't have any misunderstandings.
sayrer
>
> The mission from 2003 hasn't changed that much.
I just read
<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/
000005.html>
I can find lots that has changed. ymmv.
>
> > During the same time period, it became impossible to discuss material
> > changes to the approach without being shouted down by the same 5 or 10
> > people. Maybe shouting is a bad word for it. But the approach of
> > drowning people in minutiae while (unintentionally?) ignoring the point
> > they were making is well known.
>
> Please don't confuse disagreement with ignoring.
My statement does not confuse the two concepts. Read more closely.
But now we're back to answering longish emails from on person
belonging to that set of 5 or 10 people. :/
- Rob
Robert O'Callahan
> During the same time period, it became impossible to discuss material
> changes to the approach without being shouted down by the same 5 or 10
> people. Maybe shouting is a bad word for it. But the approach of
> drowning people in minutiae while (unintentionally?) ignoring the
> point they were making is well known.
In this thread, people have mainly agreed that releasing a subset of the
spec as HTML 4.1 would be a reasonable thing to do. That sounds like a
material change. Is that not the point you were making?
> I was interested in hearing from people outside that group.
Nothing is stopping anyone from replying.
If you want feedback from specific people, I suggest emailing them and
encouraging them to speak up.
Rob
Sam Ruby
> On 26/2/09 8:51 PM, sayrer wrote:
>
> > I was interested in hearing from people outside that group.
It is not clear to me what feedback you are looking for.
Permission? I've found that it is easier to get forgiveness, YMMV.
Features, as in did you cut too much or too little? I've seen two
specific suggestions to date.
Mechanics? That stuff can be worked out later.
> Nothing is stopping anyone from replying.
>
> If you want feedback from specific people, I suggest emailing them and
> encouraging them to speak up.
I've asked Chris Wilson (co-chair + Microsoft) and Doug Schepers
(WebApps + W3C) to comment on the features list, but I'm not sure that
mozilla.dev.platform is the best place for that discussion.
As for me, what I would most like to see in the next draft is a RFC
2119 compatible definition for table summaries, either in terms of a
HTML 4 compatible attribute or in terms of a suitable replacement.
Note that I am specifically saying "in a draft". What I am *not*
looking for is a reply to this email on how such a topic might be
approached.
> Rob
- Sam Ruby
Martijn
> Please don't confuse disagreement with ignoring. The WHATWG was explicitly
> set up with a promise that all feedback would be replied to, and I've been
> sticking to that promise religiously, and I've worked hard to try to
> understand all feedback (including yours), as have many others.
Well, the last times I commented about this or that on the html5
mailing list, I got an answer in something like 7 months or so.
Also, it was sometimes mangled within other responses.
Isn't that basically the same as ignoring?
Regards,
Martijn
> To reiterate, though, I am a supporter of your "HTML 4.1" effort (or
> whatever we call it). I just wanted to clarify some points of historical
> interest, so that we don't have any misunderstandings.
>
> --
> Ian Hickson U+1047E )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Dan Mosedale
> On Wed, Feb 25, 2009 at 12:45 PM, sayrer<say...@gmail.com> wrote:
>>> In short: I just didn't care enough. :-)
>> Thanks for clearing that up.
>>
>> While I appreciate the contributions you and Henri make to Mozilla, I
>> was hoping this thread wouldn't be dominated by people who hang out in
>> the #whatwg irc channel.
>
> what to think of this thread.
I would hazard a guess that there is a decent-sized set of Mozilla
contributors who find this thread both interesting and worthwhile, but
who don't have sufficent context to provide useful input, nor available
bandwidth to go get that amount of context.
Dan
Christopher Blizzard
On Feb 26, 2009, at 1:02 PM, Dan Mosedale wrote:
> I would hazard a guess that there is a decent-sized set of Mozilla
> contributors who find this thread both interesting and worthwhile,
> but who don't have sufficent context to provide useful input, nor
> available bandwidth to go get that amount of context.
Yes, said much better than I did. Thank you.
--Chris
Robert O'Callahan
> On Feb 26, 5:37 am, Robert O'Callahan<rob...@ocallahan.org> wrote:
>> If you want feedback from specific people, I suggest emailing them and
>> encouraging them to speak up.
>
> I've asked Chris Wilson (co-chair + Microsoft) and Doug Schepers
> (WebApps + W3C) to comment on the features list, but I'm not sure that
> mozilla.dev.platform is the best place for that discussion.
I think Rob meant "Mozilla people" in this context.
Rob
Ian Hickson
> On Thu, Feb 26, 2009 at 9:23 AM, Ian Hickson <i...@hixie.ch> wrote:
> > Please don't confuse disagreement with ignoring. The WHATWG was explicitly
> > set up with a promise that all feedback would be replied to, and I've been
> > sticking to that promise religiously, and I've worked hard to try to
> > understand all feedback (including yours), as have many others.
>
> Well, the last times I commented about this or that on the html5 mailing
> list, I got an answer in something like 7 months or so. Also, it was
> sometimes mangled within other responses. Isn't that basically the same
> as ignoring?
If you feel like that was ignoring, then I apologise. Please feel free to
indicate that you would like a quicker, and direct, response, next time
you send feedback; I will prioritise feedback from people who need
quicker relies (e.g. because they are implementing things).
Sam Ruby
*double take*
Rob who? Plural indefinite pronoun antecedents. :-)
More seriously, while I realize that what I'm about to say is at odds
with how the W3C operates, I don't think it is healthy, appropriate,
or constructive for a diverse group of people such as exists at
Mozilla to attempt to formulate a unified position or present a
unified front. First, who are "Mozilla people"? Arguably, I'm one.
Doug may be too, or may simply not be one... yet. I wouldn't rule
out Chris someday being a Mozilla person. Second, while there clearly
are common values at Mozilla, such as a desire for an open web,
reasonable people may disagree on how best to achieve that goal.
> Rob
- Sam Ruby
sayrer
>
> More seriously, while I realize that what I'm about to say is at odds
> with how the W3C operates, I don't think it is healthy, appropriate,
> or constructive for a diverse group of people such as exists at
> Mozilla to attempt to formulate a unified position or present a
> unified front. First, who are "Mozilla people"?
There's an operational definition implied by the m.d.platform group.
Developers that contribute to Mozilla's core code.
I wasn't attempting to attempting to arrive at a unified position. But
I also wouldn't want to surprise other people in the Mozilla project
with a proposal they had no idea was coming. I also figured they might
have something to say about evolving the core standards of our
product. Positive, negative, orthogonal--I thought I might be able to
gather some data.
- Rob
Jonas Sicking
> 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".
An alternative approach is for vendors to deploy experimental
implementations under a vendor namespace. This is something that has
been done in the CSS world a lot with great success.
This reduces the need to specify something immediately, while at the
same time allows gathering of experience that is invaluable during spec
development.
Specification work shouldn't generally happen as part of research. When
significant research happens first the spec tends to be of higher quality.
/ Jonas
Ted Mielczarek
> An alternative approach is for vendors to deploy experimental
> implementations under a vendor namespace. This is something that has
> been done in the CSS world a lot with great success.
I wholeheartedly concur. I'm not sure why there's a race to
standardize experimental technologies. Get them out with vendor
prefixes, let people play with them, and then work towards a standard
with the implementation experience. If a vendor wants to publish a
draft spec of what they implemented, that's great, as long as it's
clearly indicated that it's from the vendor, and not a standards body.
-Ted
Robert O'Callahan
> An alternative approach is for vendors to deploy experimental
> implementations under a vendor namespace. This is something that has
> been done in the CSS world a lot with great success.
The majority of our vendor-prefix CSS features are just implementations
of pre-CR draft specifications of the CSS WG (-moz-box-shadow,
-moz-border-radius, -moz-opacity, -moz-column, etc).
When a new feature is promulgated under a vendor prefix, we generally
hope and expect that the eventual spec will match our ideas fairly
closely. When that expectation fails, there is pain. So I don't think we
can just look at CSS and say the problem is solved there.
Also, vendor prefixes work better for CSS properties than for DOM APIs
and especially DOM events, since CSS fallback is fairly straightforward
but there is no easy way to know whether a DOM event is going to be fired.
> Specification work shouldn't generally happen as part of research. When
> significant research happens first the spec tends to be of higher quality.
Sure, but there are many ways to do research. One great way is to look
at other platforms' APIs, implementations and deployed code. Another is
to study use cases and the workaround people are using. Another is
academic research (although that is much less helpful than it could or
should be).
Shipping experimental implementations in released products from multiple
vendors, gathering feedback, and then reconciling the differences in a
spec is perilous IMHO.
1) There are substantial engineering costs in reimplementation
2) The old API may need to be supported indefinitely if some authors
come to rely on it (even more engineering costs)
3) Authors have to learn API multiple times
4) Development of the spec is difficult because vendors fight to protect
their investment in their implementation; they have a strong(er)
interest in gaming the process
5) A de facto standard may become entrenched (bugs and all) and make the
spec irrelevant
IMHO there is nothing to lose, and much to gain, by bringing vendors
together as early as possible to attempt to reconcile their API
proposals. Where agreement can't be reached, by all means roll out
vendor-prefixed extensions and gather data. (But it seems to me that
agreement almost always *can* be reached if there's goodwill and good
sense on all sides.)
Rob
Henri Sivonen
Robert O'Callahan <rob...@ocallahan.org> wrote:
> On 28/2/09 2:50 PM, Jonas Sicking wrote:
> > An alternative approach is for vendors to deploy experimental
> > implementations under a vendor namespace. This is something that has
> > been done in the CSS world a lot with great success.
>
> The majority of our vendor-prefix CSS features are just implementations
> of pre-CR draft specifications of the CSS WG (-moz-box-shadow,
> -moz-border-radius, -moz-opacity, -moz-column, etc).
>
> When a new feature is promulgated under a vendor prefix, we generally
> hope and expect that the eventual spec will match our ideas fairly
> closely. When that expectation fails, there is pain. So I don't think we
> can just look at CSS and say the problem is solved there.
Isn't the pain scenario the expected success scenario for vendor
prefixes, though? That is, a vendor prefix protects the unprefixed space
of CSS property names from ill-conceived experiments eating up obvious
names, but when the experimental design is good as-is, the prefix
becomes a hindrance, since everyone would have been better off having
the unprefixed thing from get-go.
http://www.w3.org/StyleSheets/Mail/message.css has this:
pre {
white-space: pre-wrap; /* css-3 */
white-space: -moz-pre-wrap; /* Mozilla, since 1999 */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap; /* Opera 7 */
word-wrap: break-word; /* Internet Explorer 5.5+; makes the CSS
invalid :( */
}
Having the same thing implemented under multiple names doesn't look
all-round great.
Also, the developer feeling that it's OK to keep tweaking the property
name until it's "official" is annoying. At least I was annoyed as an
author when I had to troubleshoot an issue of a style sheet not working
and the reason was that a vendor-prefixed property name had changed
gratuitously between Prince builds (IIRC, prince-hyphenate changed to
prince-hyphens). Once something has shipped, people start using it.
> > Specification work shouldn't generally happen as part of research. When
> > significant research happens first the spec tends to be of higher quality.
>
> Sure, but there are many ways to do research. One great way is to look
> at other platforms' APIs, implementations and deployed code. Another is
> to study use cases and the workaround people are using. Another is
> academic research (although that is much less helpful than it could or
> should be).
>
> Shipping experimental implementations in released products from multiple
> vendors, gathering feedback, and then reconciling the differences in a
> spec is perilous IMHO.
> 1) There are substantial engineering costs in reimplementation
> 2) The old API may need to be supported indefinitely if some authors
> come to rely on it (even more engineering costs)
> 3) Authors have to learn API multiple times
> 4) Development of the spec is difficult because vendors fight to protect
> their investment in their implementation; they have a strong(er)
> interest in gaming the process
> 5) A de facto standard may become entrenched (bugs and all) and make the
> spec irrelevant
Also, there are also smart people working elsewhere and circulating a
design first could gather feedback that would make the feature better.
> IMHO there is nothing to lose, and much to gain, by bringing vendors
> together as early as possible to attempt to reconcile their API
> proposals. Where agreement can't be reached, by all means roll out
> vendor-prefixed extensions and gather data. (But it seems to me that
> agreement almost always *can* be reached if there's goodwill and good
> sense on all sides.)
Having documentation for what's being implemented and circulating
designs ahead of implementation and shipping is probably good for
inter-vendor relations. I noticed that when Mozilla implemented a
vendor-prefixed canvas text API, the initial reactions from an Opera
employee were that 1) it lacked documentation and 2) hadn't been
proposed on the WHATWG list.
http://krijnhoetmer.nl/irc-logs/html-wg/20070802#l-107
Robert O'Callahan
> In article<Cumdneqpv8WPmDbU...@mozilla.org>,
> Robert O'Callahan<rob...@ocallahan.org> wrote:
>> When a new feature is promulgated under a vendor prefix, we generally
>> hope and expect that the eventual spec will match our ideas fairly
>> closely. When that expectation fails, there is pain. So I don't think we
>> can just look at CSS and say the problem is solved there.
>
> Isn't the pain scenario the expected success scenario for vendor
> prefixes, though?
Vendor prefixes are like insurance. It might be accurate to say that the
"success scenario" for insurance is that your house burns down, but that
doesn't make insurance a bad thing.
Vendor prefixes can be annoying, but on balance vendor they seem like a
good thing in CSS, IMHO, by preventing worst-case scenarios where
deployed implementations lock down the spec prematurely.
Rob
Jonas Sicking
Yeah. Maybe a combination of solutions is the best way to go (it often
is). Circulating ideals and trying to standardize before starting to
write code is always a good idea, I agree. But if you're wanting to ship
and the standard isn't locked down yet, maybe shipping with a vendor
prefix even for DOM APIs is a good idea.
I do agree that there are difference between vendor prefixes for CSS and
DOM APIs. Event names is a good example, though you can always register
listeners for multiple events just like you can write CSS for multiple
properties.
And for features exposed as properties it would be great with stuff like
mozilla.futureDOMStorage or webkit.coolNewTimer. These can easily be
tested for and worked around when they don't exist.
/ Jonas