Clearly there are areas of disagreement. Not just between Roy and Ian, but between many of the participants in the working group. Many are focusing on such details as to what should be normative, and how such specifications should be arranged. My opinion is that this discussion is premature and can’t be settled without first establishing a common understanding of the context and goals of the effort.
Meanwhile, it is important to note the Mike’s document does not attempt to be inconsistent with the ongoing HTML5 work, it merely attempts to capture a subset of this information, and present it from a different perspective.
The bigger problem is that HTML5 will be finished in 2022. Or in 2010.
The first thing that needs to be recognized is that the WHATWG’s goals (are these documented?) won’t be met in 2010. The second thing is that neither will the W3C’s.
There are many ways to address this. One that I would not be in favor of is adjusting the W3C’s date significantly.
IMHO, what’s needed is a chair that will take consensus whenever he (or she) can find it, and graciously accept defeat when that’s not possible. Again, not all of the goals are achievable by 2010. Whether they ever could have been or not is irrelevant, at this point it clearly is not the case.
And it is worth repeating that the intent is that Mike’s document and Ian’s document aren’t in conflict. One way to resolve any apparent conflicts is to relabel the document which is intended to be later. Picking some dates out of the air, how about HTML5=2010; HTML6=2013; HTML7=2016; HTML8=2019; and HTML9=2022? Meanwhile...
Question: Do we need to resolve whether ping is in HTML9?
Answer: Not today.
Question: Do we need to resolve whether the DOM bindings are in HTML9 or are in a separate document?
Answer: Not today.
I could go on, but the basic point is that if HTML5 were redefined to be the set of things over which we can come to rough consensus over the next 18 months or so, it would in all likelihood be (a) delivered on time, (b) be significantly smaller than the current working draft, and (c) as consistent as we collectively know how to make it with the full “2022” vision.
Repeat that process ever three or so years, and I’m confident that we will eventually converge on full consensus. Possibly even by 2022.
The 2022 date refers to the date at which Hixie estimates that HTML 5 will have two complete interoperable implementations. At this stage, the only realistic way to make that date 2010 would be to label the set of features that have already shipped “HTML5” and hope that the bugs can be worked out over the next two years. Since you are talking about consensus I assume that is not the date that you have in mind, nor approach that you are interested in taking.
With that in mind, the date that the working group have most control over seems to be the date to go to LC, which Hixie estimated could happen in late 2009 and the W3C estimates will happen in March. I have no idea if either of those parties would revise the estimates in light of the current rate of progress, but I, personally, will be astonished if we make either date. I don’t think radical cutting of features in order to make an arbitrary date estimate is a valuable exercise, neither do I think basing decisions on consensus amongst a group of people who are by-and-large not making implementations is going to result in the kind of high-quality spec that has been achieved so far.
However all of this is, as far as I can tell a red herring. The only date that actually matters is the date on which browsers have adopted the new spec to the extent that authors feel confident using it on their site. If the set of features that are interoperably implemented on some date is a superset of the set for which we have theoretical consensus then the only effect will be to make the W3C appear out of touch.
On the other hand I fully agree that we should not block the work based on meta-issues like the most desirable number of independent documents. If people want to split the spec along some lines, they should do so in parallel to the main development to demonstrate that it represents a desirable change. After that, it can be folded into the contemporary revision of HTML. Blocking progress for this kind of thing seems counter-productive in the extreme. Sadly many people seem convinced that solving their pet meta-issue immediately is more important than making actual technical progress.
Sam Ruby is always worth reading; today his Half Full took me on a (rare) visit to HTML5-land. Among the many things I feel guilty about, not having the strength to follow HTML5 is prominent. Ian Hickson and his posse have repeatedly proved that...
The 2022 date, as James said, is for two complete bug-free implementations. Consider that so far, we still don’t have two complete bug-free implementations of HTML4 or DOM2 HTML, both of which came out in the mid to late 90s, around a decade ago.
The date I expect HTML5 to reach the level that HTML4 reached in the 90s is October 2009. I expect the spec to be frequently errata’ed (the stage HTML4 should have been in now, but its working group abandoned it) until about 2012, and then infrequently updated after that. These dates are based on experience with how much feedback CSS2.1 got. (CSS2.1 is to CSS1 what HTML5 is to HTML4.)
I have no idea if either of those parties would revise the estimates in light of the current rate of progress, but I, personally, will be astonished if we make either date.
The date I expect HTML5 to reach the level that HTML4 reached in the 90s is October 2009
I respectfully disagree. The biggest problem I see is not that the spec is lacking something yet to be done, but that the spec contains a lot of material over which there is no consensus. This is compounded by the fact that there has been little or no attempt to map out the boundaries between the areas over which there is consensus and areas where this is consensus. Given that there is essentially no progress towards addressing the latter, I don’t see meeting a 2009 date unless there is a radical change in the way decision making is done in the working group.
My suspicion is that the author cares more about browser implementor consensus than WG consensus — thus, if these features get implemented in multiple browsers, it will become very hard to get them out of the spec again.
The HTML5 work isn’t using the traditional W3C approach, and will never use a consensus approach so long as I am editor. Consensus simply isn’t a good way to get technically solid specifications, and is in any case basically impossible to achieve in a group with hundreds of participants such as this one.
Having said that, I’m not aware of any decision that has yet been made that didn’t have a majority agreement, and the implementations are following the spec as it evolves (i.e. we do have "rough consensus and running code").
Consensus simply isn’t a good way to get technically solid specifications, and is in any case basically impossible to achieve in a group with hundreds of participants such as this one.
Ian, you have a history of making overly broad statements that are mostly, but not completely, true; this is one of them. Repeating such statements don’t make them any more true.
A proper subset of the current specification by removing, say, the ping attribute would result in a specification that is both technically solid and would enjoy greater consensus than the current draft.
I will therefore assert that it is possible to simultaneously improve the amount of consensus, the “technical solidity”, and the schedule by identifying and deferring such controversial items. Furthermore, such deferrals would in no way preclude such features in subsequent iterations.
The way that table headers work, and the precise definition of the alt attribute are also controversial issues within the spec and I do not think we have achieved real consensus on either. However neither of these features can be removed from the spec in order to achieve consensus.
I would suggest that the number of features that can simply be dropped in order to improve consensus is small compared to the number of known or likely points of conflict.
jgraham, I assert that part of the apparent conflict in those issues is a consequence of the assumption that HTML5 is a monolithic and multi-decade activity. Permit me to explain...
If one were to draw a straight line (conceptually) between the way the alt attribute is specified to work in HTML4 and the way that HTML5 currently proposes to have it work we can recontextualize the question as follows: how far along that line we are comfortable “moving” that point from the HTML4 starting point in 2009. This may not end up being as far along as people might want it to be, at least not all at once, but if it is moving in the right direction and doesn’t preclude further improvements in the next iteration, that might be enough to improve the amount of consensus the HTML5 draft enjoys.
Removing ping="" wouldn’t increase the level of consensus, it would just move the unhappiness from some people (who are concerned that it can’t track users well enough and think that it violates HTTP rules) to other people (who want it so that they can help user privacy awareness). Our “priority of constituencies” principle means I have to put users ahead of implementors and spec purity, so in this case the group that wants to help users gets to “win”.
Like Roy Fielding, I feel compelled to state: I made no such claim.
You’ve objected to my referring to 2022, so this time I will make a direct quote: W3C Candidate Recommendation stage during 2012. On the W3C page, it says, and again a direct quote: 2009-06 HTML5 Candidate Recommendation.
I am of the belief that the best way to get to a solid recommendation in 2012 is make two releases, the first with all of the low hanging fruit, and repeat the process every few years.
I happen to feel that the 2012 date for everything that the WHATWG intends to include in HTML5 (again, is there a list?) is somewhat optimistic, but fortunately there is no need to determine that now.
Ian: “Removing ping="” wouldn’t increase the level of consensus, it would just move the unhappiness from some people (who are concerned that it can’t track users well enough and think that it violates HTTP rules) to other people (who want it so that they can help user privacy awareness)."
I think that’s an inaccurate description of what’s going on.
For instance, when saying “...who are concerned that it can’t track users well enough...”, are you referring to Roy? That makes it sound as if his single concern is that it’s not good enough for tracking. My understanding however is that he simply says that to be used in practice, it would need to be more reliable, and thus it shouldn’t be introduced at all.
Phil, from my perspective this is a creative bit of selective quoting. But despite the fact that this page is relatively short and has the main thesis has been repeated several times in several different ways on it, I’m going to assume instead that I haven’t explained my suggestion clearly enough. So undaunted, let me try again.
For starters, I will assert that HTML 4.01 specification has no ping attribute defined. I assume that that fact is not in question.
The WHATWG page suggests that the editor considers that their work will be ready for consideration as a potential W3C Candidate recommendation in 2012. At the moment, the presumption on the part of that same editor is that that draft will contain a ping attribute. Do we need to settle that question today? I will assert not.
Meanwhile, the W3C page suggests that the chairs of that working group are working towards a potential W3C Candidate recommendation in 2009. Ignoring for the fact that I and apparently a few others consider both dates to be rather aggressive and optimistic, there is a very real difference in expectations.
One way to proceed is for the potentially controversial bits to be commented out or removed entirely from the current draft (given what modern version control systems are capable of these days, I’m not sure that such details matter much), and make quick progress on the areas on which there is wide agreement, clearing the way for more focused discussions on the remainder. Another way to proceed if the current editor feels like that is too much work is to look for another editor to proceed in parallel with a smaller proposal.
If anybody finds the above proposal difficult to understand, feel free to ask questions.
Ignoring for the fact that I and apparently a few others consider both dates to be rather aggressive and optimistic
In case I am one of the “several others” referenced here, I should note that I think that the date for Last Call is rather optimistic. At this stage I have no way of judging whether the WHATWG date for CR is plausible or not, although I think the W3C estimate that the feedback from LC to CR will be gathered and dealt with in merely three months is highly implausible.
I happen to feel that the 2012 date for everything that the WHATWG intends to include in HTML5 (again, is there a list?)
I believe the spec is now considered to be in feature freeze (although some sections have not been written yet) so the table of contents is the list of WHATWG goals for the spec (insofar as the WHATWG has a collective voice). Many features have already been postponed for future versions of HTML.
Sam, I agree with your main thesis, but I believe my “selective quoting” to be an accurate portrayal of one part of this conversation. If you’d like to point out which claim about ping that you did not make, I’ll gladly withdraw.
In the same vein, Ian says “I have to put users ahead of implementors and spec purity, so in this case the group that wants to help users gets to “win”.”
and “HTML5 ... will never use a consensus approach so long as I am editor”
which means that in fact neither group has to “win”. From my observer-only role what should “win” is the timetable.
Phil, I’m not trying to be dense, but I’m simply not following. Perhaps the key is understanding what you mean by what should “win” is the timetable? Which timetable are you referring to?
Based on the WHATWG webpages, there exist some people who would like ping as spec’ed, and are comfortable waiting for a candidate recommendation containing this in 2012.
Based on the W3C webpages, there exists some people who would like to see a candidate recommendation considerably earlier, ideally in 2009.
So, as I see it, the question is: can you identify at least one person who would be quite happy waiting until 2012 for a candidate recommendation containing a ping attribute as spec’ed, but only if there is no preceding candidate recommendations which contain a proper subset of the 2012 spec that does not include the ping attribute? If so, can we get their input as to why this is a less than desirable situation?
That’s the only scenario I can see “remove from current draft without prejudice and with the expectation that there will be a series of follow-on drafts” as creating a situation in which there are non-winners.
Consensus is a sin The HTML5 work isn’t using the traditional W3C approach, and will never use a consensus approach so long as I am editor . Consensus simply isn’t a good way to get technically solid specifications, and is in any case basically...
As far as the timetable goes, I am confident that we will make the 2009 (LC) date and the 2012 (CR) date. We have so far been very much on track for this timetable ever since I first proposed it in 2006. You can track progress using the issues chart ([link]).
I agree that the W3C version of this timetable is ludicrous.
Like climbing an Icy Pole There were a couple other new features added this week, which I’m also kind of mystified by. I did ask on IRC , but I don’t think Ian’s response was very direct. It seems the only requirement to qualify for addition after...
Sam Ruby has just been appointed co-chair of the HTML5 Working Group. In addition to being an early adopter of HTML5, Sam has been a loud proponent of distributed extensibility within HTML and a vocal critic of the entire HTML5 process in general....
Googles Ian “hixie” hickson to step down as editor of W3C HTML5 specification . With the appointment of Sam Ruby as co-chair of the W3C HTML WG and the expectedly more proactive stance he will take on issues: IMHO, what’s needed is a chair that...
Yesterday’s HTML WG meeting marked the change in the working group leadership. Sam Ruby attended as Co-chair. Smells like HTML5 development via group consensus. Issue 54 was discussed [link] , by the members of...
Warning: this post falls into diatribe territory. I strongly feel that important technologies should be determined by consensus and not closed circles, and I’m not convinced that this is currently the case of HTML5. I seriously doubt that Ian...