Brendan Eich: Standards often are made by insiders, established players, vendors with something to sell and so something to lose. Web standards bodies organized as pay-to-play consortia thus leave out developers and users, although vendors of course claim to represent everyone fully and fairly. I’ve worked within such bodies and continue to try to make progress in them, but I’ve come to the conclusion that open standards need radically open standardization processes.
The W3C HTML Working Group needs a CarterPhone. Clearly, Brendan is talking about ES4, but the issues he brings up are general.
Brendan Eich: Standards often are made by insiders, established players, vendors with something to sell and so something to lose. Web standards bodies organized as pay-to-play consortia thus leave out developers and users, although vendors of course claim to represent everyone fully and fairly. I’ve worked within such bodies and continue to try to make progress in them, but I’ve come to the conclusion that open standards need radically open standardization processes.
The W3C HTML Working Group needs a CarterPhone. Clearly, Brendan is talking about ES4, but the issues he brings up are general.
When I was growing up, all phones I ever used were the property of AT&T. It takes a totally unified system to make it all work. One system. AT&T. Yes, that gave us Princess Phones, but not answering machines, fax machines, cordless phones, or computer modems.
What are the four format freedoms that correspond to the four net freedoms?
In the summer of 2000, the notion of defining RSS as a monolithic entity was put forth. “Interesting ideas” once defined in namespaces apparently included rdf:about (now guid) and dc:date (now pubDate). Meanwhile, some barnacles like skipDays and cloud got included. 27 months later, RSS 2.0 got namespaces, and data like dc:creator, content:encoded, and slash:comments (all which already had long histories with RSS 1.0) could now flow through that format.
Dan Connolly: Of course, it would be easier to publish the spec right away if the spec took a much more conservative position on issues such as videoaudio, immediate-mode-graphics, and offline-applications-sql.
Apparently reasonable people disagree about whether these things are included in the charter. That doesn’t mean that there aren’t good arguments to be made on both sides — in fact, that’s exactly what you would expect in a situation where reasonable people disagree.
One way to address this would be to fix the charter, though many have argued against that, fearing rats the size of lions. Oh my. Another way to address this would be to jettison for the moment features which don’t yet enjoy consensus — in the interest of enabling forward progress now. Predictably that hasn’t gotten much traction yet either.
And yet talk about distributed extensibility goes nowhere. Nearly four months later it is still on my list of things to look at; when I have time.
Why do I get the feeling like I am faced with an attitude of “It takes a totally unified system to make it all work. One system. HTML5”?
Like Brendan believes is true for ES4, I believe that what we really need here is a radically open standardization process. The two standards are quite different, so different solutions may be in order. In the case of HTML5, I believe that a smaller spec which focuses on two things: fixing HTML4 (includings things like well defined error recovery), and setting the basis for separate (often overlapping) groups to work on things like canvas
. No, I’m not suggesting that canvas
needs to be in a namespace, but just that the rules for extending HTML be written down.
In such an organization, things could always be flowing.
One aspect of the problem, I suspect, is that getting features such as <canvas> into the ‘next version of HTML’ is seen as pressure for Microsoft to implement it.
Whether it would work or not and whether it’s a valid factor is debatable, but their support for external w3c graphics standards isn’t spectacular. The most obvious interpretation, to me, of the desire to change the name of ES4 is that if it wasn’t ‘the new ecmascript/javascript’ then it would be easy to justify not supporting the new language.
If <canvas> is most appropriate as an extension or module, but that might keep it off 75% of the web for another few years, what do you do?
Well, to be blunt; Microsoft can put off implementation of the whole HTML5 specification if they chose to. They can rationalize it with whatever they want, with any knee-jerk reaction thinkable. They can do it on the sole reason that canvas
is specified as it is, with no further explanation. They can say they don’t like the current specification and say they are working on an alternative specification within Microsoft.
If stuff is included in the HTML5 specification for the soul purpose of “forcing” Microsoft to implement it, I believe something is out of whack. That includes canvas
today, but might as well include SVG and CSS3. Microsoft has said that they want to play ball, so either we have to trust them to do so and make HTML5 the best specification it possibly can be (and with that, imo, moving canvas
into its own specification) or don’t believe it at all, and put in all sorts of dependencies to force Microsoft’s hand into implementing all of it.
Either way, Microsoft may or may not implement everything from 1% to 100% of HTML5 and there’s absolutely nothing we can do about it. A key to getting as close to 100% as possible, though, would be to keep the specification as simple and clean as possible and not abuse it as a crowbar for other technologies.
If it isn’t clear; Sam, I completely agree with you.
Oh, I got the following error while posting now:
CGI Failure traceback:Traceback (most recent call last): File "gateway.cgi", line 39, in <module> post(url) File "/home/rubys/mombo/post.py", line 452, in post file = writeComment(entry, title, body, decache=False) File "/home/rubys/mombo/post.py", line 241, in writeComment if spamthrottle.spammer(body): File "/home/rubys/mombo/spamthrottle.py", line 231, in spammer if spamrank(baseip, baseurl, basetext) > 2: File "/home/rubys/mombo/spamthrottle.py", line 104, in spamrank credits, debits = spamtally(baseip, baseurl, basetext, rateonly) File "/home/rubys/mombo/spamthrottle.py", line 162, in spamtally debits += int(math.sqrt((time()-mtime)/240))*['content-rate'] TypeError: 'float' object is not callable
The reason to have <canvas> in the spec isn’t to “force” Microsoft to implement it. Web standards aren’t laws. The reasons are that the web needs better graphics, that the de facto solution needs better interoperability, and that it’s already in the spec, and excising it to stand alone would be a large amount of work that no one has volunteered to do.
Microsoft’s reason for objecting to it, on the other hand, is that they don’t want to feel more pressured to implement it by web developers, and want to hold the rest of the web back while pushing their own proprietary solutions for rich web applications. While it would be nice to have their cooperation on HTML5, I do not believe that cutting this one feature will result in a happy compromise on the rest. Chris Wilson has already telegraphed that audio/video (explicitly in the charter), offline support (explicitly in the charter), session history and much more are next on his chopping block. In the past he has objected to specifying parsing and error handling as well. It’s pretty clear to me that giving in on this issue will not lead to reasonable compromise but rather to cut after cut, holding back progress on the web while proprietary technologies deliver the very same features.
As for extensibility, I agree it is an important area to address. But Sam, all I saw from you on this is one roughly sketched proposal, and when you got feedback on some details of it, you seemed to feel attacked and dropped the ball. And all this was before the HTML Working Group even started. If this feature is really your top priority, you should be championing it, refining the technical approach, and persuading vendors and web developers. I fail to see how it furthers your feature request to argue against other features (in this case already specced and widely implemented).
canvas
to its own specification, then? Who can do it? Can anyone just pick up the pieces, write it up and publish it, then W3C will embrace it somehow (automagically)? Is there a described procedure for how to accomplish this? How can, for instance I, do what you propose? How do I get hold of the necessary tools to produce a W3C specification?As for extensibility, I agree it is an important area to address. But Sam, all I saw from you on this is one roughly sketched proposal, and when you got feedback on some details of it, you seemed to feel attacked and dropped the ball. And all this was before the HTML Working Group even started. If this feature is really your top priority, you should be championing it, refining the technical approach, and persuading vendors and web developers. I fail to see how it furthers your feature request to argue against other features (in this case already specced and widely implemented).
I had extensive discussions on this, both on the whatwg mailing list and privately with Ian. I don’t believe anybody can say that I haven’t been trying. Consistently. For over a year. Heck, even with the TAG behind my proposal, all I got was foot dragging.
I fail to see how you can say that this proposal was before the HTML Working Group even started.
Can you cite one place where I argued against other features? For those who missed my vote on the subject, I thought I was pretty clear: “an immediate mode graphics API and canvas element would clearly be a good thing; my only issue is the scope question”. I personally would love to see canvas
be touted as a success story for extensibility.
If there is agreement that the spec should be split up, but the existing editors do not have the necessary time to do so, I am handy with vi and can help out.
Note that it is not just splitting out the text. The specification also needs to be maintained and the editor needs to actively address new issues that arise and reply to comments on the mailing list.
As for the question Asbjørn raises, W3C Working Drafts are published in HTML. There are some tools that can help you to generate the table of contents automatically, etc. The one I’m personally using (and the HTML5 drafts too) is unfortunately hidden behind a Member-only URI but I’m sure that someone else can generate the specification for you if you’ve done the editing. (You would need to join the appropriate Working Group and be willing to do what I said in the first paragraph.)
Not sure anyone had seen this yet.... Crockford on html5
Sam Ruby wrote:
Can you cite one place where I argued against other features?
Above, Sam Ruby wrote:
Another way to address this would be to jettison for the moment features which don’t yet enjoy consensus — in the interest of enabling forward progress now.
and
In the case of HTML5, I believe that a smaller spec which focuses on two things: fixing HTML4 (includings things like well defined error recovery), and setting the basis for separate (often overlapping) groups to work on things like canvas.
Perhaps I misunderstood, but the latter two quotes seem to suggest removing features from HTML5, with an extensibility mechanism therefore required to let someone else to put them back. Which looks kind of like the way Mark Pilgrim called it.
Perhaps I misunderstood, but the latter two quotes seem to suggest removing features from HTML5, with an extensibility mechanism therefore required to let someone else to put them back.
Someone else?
Microsoft and others have questioned whether three things are in scope. Given that state, it makes sense to me to either clarify the scope or pursue these as extensions. I guess that makes me evil.
I hope the following (that I recently posted to the W3C mailing list) clarifies my position:
Now, before the above paragraph is misconstrued as me being “against” a 3D Canvas API, as has recently has occurred, let me make two things clear: it seems plainly obvious to me that there is considerable support for a 3D Canvas API, enough so that it would surprise me greatly if nobody stepped forward to help out. And secondly, I believe that creating a viable ecosystem for extensions doesn’t curtail innovation, it enables it. “Centrally designed protocols start out strong and improve logarithmically. Evolvable protocols start out weak and improve exponentially. It’s dinosaurs vs. mammals, and the mammals win every time.” — [link]
Sam, I don’t think anyone’s moralizing ("I guess that makes me evil"). I hope no one is among the WHAT-WG regulars.
There’s explicit concern (from Hixie at least) that dividing the spec means the split-off “non-HTML5” pieces will languish. To address this, you’ve volunteered. Great — I think a response is due, unless you weren’t heard to offer this on the WHAT-WG list.
I have another concern, not sure who else shares it, that divide and conquer is still a favorite of the enemy’s tools. (Ok, enemy definition without good vs. evil: Microsoft IMHO has no intention of evolving HTML to compete with WPF/Silverlight except by extending HTML with features that require WPF/Silverlight — that makes them “the enemy” here). “Delay is the deadliest form of denial” also comes to mind (corrollary to Parkinson’s Law, IIRC).
In an ideal world, we could separate concerns (as in modular programming, where the programming language allows cyclic dependencies among modules) and have N > 1 specs, all normative in short order by agreement among web developers and with-it browsers. In the real world (and this is also a concern for ES4), integrated specification can have lower overhead and less risk of disruption or disintegration.
/be
I don’t think anyone’s moralizing
“Petty” and “bullshit” are direct quotes. No, not here, but not hard to find either.
“Delay is the deadliest form of denial” also comes to mind
I will point out that scope creep ends up at basically the same place.
In the real world (and this is also a concern for ES4), integrated specification can have lower overhead and less risk of disruption or disintegration.
I would much prefer that level of honesty. Instead, what we have is overblown references to non-existent or minor circular references.
In the real world [...], integrated specification can have lower overhead and less risk of disruption or disintegration.
Integrated specifications also suffer from bloat and lack of QA in a way that separate, focused specifications do not. I see Ian’s concerns, but I agree with Sam in that the circularity of the different parts in HTML5 that are reap for exclusion isn’t at all as prevalent as one would like to think and that they safely could be split out to their own specifications without breaking HTML5.
That way, both HTML5 and the different external parts in question can evolve asymmetrically and flourish in a way that just isn’t possible with an integrated and bloated specification. What if canvas
is an interesting drawings API outside the browser window? What if someone wants to implement it, with the DOM bindings, but nothing else? Wouldn’t that be much easier and make much more sense if it had its own, independent specification?
Asbjørn: experimentation is welcome and ought to be allowed by the spec(s). The issue I raised is unity of effect for developers: can they count on the normative minimal support (2D, 3D OpenGL-ES) at some next-generation browsers-in-field check-point, or not? These are separable concerns, for sure. The bigness of HTML5 may be justified, IMHO, based on the latter concern, as I wrote in my last comment. That doesn’t take away from your point, but your point does not decisively rule out a big standard, either.
Bigness aside, if there is no end in sight (mission or scope creep, or jump) then we have a problem. ES4 has shut down new proposals and those of us working on it have a self-imposed (not market-driven) schedule. Should the WHAT-WG have a common aspirational/fuzzy schedule, too?
/be
The issue I raised is unity of effect for developers: can they count on the normative minimal support (2D, 3D OpenGL-ES) at some next-generation browsers-in-field check-point, or not?
CSS-3 did not effectively provide such a checkpoint. Nor, effectively did CSS-2.
Having everybody parse the video
tag the same way is only 10% of the battle... unless there is agreement on a common set of codecs, there is no interoperability.
CSS provides many example of what not to do. But (I hope) ES4 shows integrated design benefits, including QA (our testable RI). Bootstrapping the JS standard library alone has been beneficial, as opposed to taking shorter-path hops through a standards process that would inevitably be less parallel, and which would (based on ES1-3 experience, among others) lead to enshrining mistakes that would have been fixed in a more holistic design cycle.
I’ve spoken in the past of how Python’s open and virtuous standard library and language evolution have fed into each other, but that took many years and involved some mistakes to back away from incompatibly. Not easy on the web.
I’m not sure what to say about the video tag. Is someone arguing for standardizing syntax without a default format which all browsers must decode? I’m not, and I’m pretty sure all the other players aren’t. Isn’t the battle there between Ogg and H.264?
Indeed, distributed extensibility without a rich-enough normative core will result in lack of interop, as you suggest. Whether the risk of that bad outcome rises or falls if we reduce HTML5 scope and write more related specs, I don’t know for sure. My comments here try to argue that it isn’t always a clean win, in the real world of politicized standards bodies and heavyweight browser innovation cycles (even the open source browsers take too long to cycle through significant changes to their mostly-C++ core code), to break things up.
/be
I’m not sure what to say about the video tag. Is someone arguing for standardizing syntax without a default format which all browsers must decode? I’m not, and I’m pretty sure all the other players aren’t. Isn’t the battle there between Ogg and H.264?
Must? The current draft only includes a SHOULD, and (correctly) notes that some user agents will support no codecs at all.
Furthermore, some believe that SHOULD is too high of a bar. See ISSUE-24 ogg-delete. Dave Singer provided an excellent summary of the issues.
It is a tangled issue. One where some invention is required. And the outcome isn’t certain. And, as you say, “Delay is the deadliest form of denial”.
Meanwhile the experimentation is welcome and ought to be allowed by the spec meme that I have been known to bring up from time to time has made the transition from design principle to disputed design principle to dropped from the list and now is referred to as a pet issue.
Sam, my apologies for engaging in overblown rhetoric, even by indirect reference. That was uncalled for, and I was wrong to do it.
Summary of my position:
- I think supporting actions that have some likelihood of causing features to be dropped from the core spec is harmful to their implementation and deployment, even if one is in principle in favor of specifying them elsewhere.
- Did you indeed volunteer to help with editing something? Brendan cites this but I didn’t see you volunteer on the list (even when Hixie posted a list of possibly useful breakout specs). If you are, then I think that’s great. I’m much more in favor of proposals to break something out that come with a capable volunteer to edit.
- I believe HTML5 should have some reasonable extensibility mechanism (and that at the very least SVG integration should be covered). I do not believe this should take priority over all other improvements to the language.
- I think we should find a way to give extensibility more priority without hurting progress on other things.
I think we should find a way to give extensibility more priority without hurting progress on other things.
I completely agree. Which is why I think it’s a bit sad to watch how Sam has tried to make a case (which imho is both very valid and just) and being shot down and basically mocked at for doing it. Those kinds of reactions aren’t exactly encouraging.
Did you indeed volunteer to help with editing something?
Yes, Sam wrote:
If there is agreement that the spec should be split up, but the existing editors do not have the necessary time to do so, I am handy with vi and can help out.
I believe HTML5 should have some reasonable extensibility mechanism (and that at the very least SVG integration should be covered). I do not believe this should take priority over all other improvements to the language.
Maciej, I believe that we have the basis for common ground. A few comments.
class
attribute” or “you can do what you want — in XHTML”. The use case needs to be something more along the lines of somebody wants to create the next canvas
tag or to add support for offline SQL storage, how do they go about doing so?Maciej, if you are willing, I’d like to contact you offline to see if there is some way that we can iterate on these ideas in a higher bandwidth fashion. Perhaps editing would be the best use of my time, but it is equally possible that prototyping may be better.
It’s worth making he distinction between adding SVG and MathML support to text/html and adding a generic extensibility mechanism. In the two things don’t necessarily depend on each other; for example recognising the <svg>
and <math>
elements as special, invoking a XMLish parse mode can happen without needing to solve the more generic extensibility problem. I spoke with some of the MathML and SVG guys at the TPAC and they seem keen to get their languages working in text/html, and we started exploring this as a possible way forward. See some notes on SVG in text/html, for example.
This is no to say that a generic extensibility mechanism is a bad idea or that SVG+MathML should not be embedded through such a mechanism. Just that I would hate to see difficulties in finding a solution that works in the general case prevent us solving the large class of problems that require support for specific, extant, vocabularies.
See some notes on SVG in text/html, for example.
An example of the types of questions that need to be explored is what existing parsers will do when faced with the following:
<svg xmlns="http://www.w3.org/2000/svg"> <title>foo</title> </svg>
To further discussion, I’ve added a few links to that page.
Having everybody parse the video tag the same way is only 10% of the battle... unless there is agreement on a common set of codecs, there is no interoperability.
Maybe 10% more with Content negociation, my video being at [link] without extension. And then authors put multiple versions (video.mpeg, video.ogg, video.mov, or whatever format of your choice). This is a big burden for the authors, but it is a step further.