- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 31 Jul 2008 21:01:08 +0000 (UTC)
- To: Sam Ruby <rubys@us.ibm.com>
- Cc: 'HTML WG' <public-html@w3.org>
On Thu, 31 Jul 2008, Sam Ruby wrote: > > This list is but one of a variety of sources of inputs that you accept. > Even if a person attempts to follow all of the insane number of lists > that you follow, they won't be getting the entire input stream as you > undoubtedly meet with people F2F. It is even possible that some of the > input you receive F2F isn't public. There are indeed several places I get input from that aren't public, e.g. I've been accepted as an observer on the "security" lists of various browser vendors (and if any other browser vendors would be willing to accept me to their list, please let me know), so that I can get ready to plug security holes in HTML5 when browsers come across problems, even before they mention them in public. I also sometimes receive candid input in secret from people and groups who, for political reasons, don't wish to be seen publicly holding particular opinions. Obviously, I try to keep such private input to a minimum, and I try to keep as much of it public as possible, but I'm not going to ignore such private feedback either. The more information I have, the better decisions I can make in the spec. > So decisions are inevitably made elsewhere. At times on other lists. > At times even, as you recently put it, in your shower. Indeed. For that matter, there are many decisions that are made that I don't really even realise are decisions. For example, consider checkin r1302, "Make addCueRange() have an identifier so that people don't have to use currying". I decided what order to put the arguments in, what to call them, what to call the new callback interface. I decided to not require the ID to be unique, I decided not to limit the values to valid XML IDs. I decided not to include the current time in the event, nor the start nor end times. I decided to not use DOM Events but to use callbacks. I decided not to change the way cue ranges are removed. I based all these decisions on my experience and all the input I received on the matter. > > > Therefore, any decisions made before the formation of a public > > > group, were not "open". > > > > Actually even before we had an actual mailing list to archive the > > discussions, everything was already being written in public. We soon > > set up a list, though, I mean, everything's been done really in public > > since 2004 already. > > Everything? You have a shower-cam? You've never met privately with > people from Google, Mozilla, Microsoft, IBM? And if you did, you have > never considered any of their inputs unless it was previously made in > public? Everything has been edited in the public, if you prefer. > > As I said to Sam, nothing is set in stone. Decisions are regularly > > changed in the face of new suggestions, evidence, etc. > > IMO, that's actually your strongest point; particularly if you > deemphasize the word new. And this point is not just words, but there > is abundant evidence supporting this claim. Thank you. > But one thing that will always remain true is that it will never be the > case that everybody agrees with every decision you make. There will > always be cases where somebody believes that they made a strong case > with clear evidence and that you decided to go a different path. Absolutely. Sometimes, I myself am that person, e.g. with the solidus thing. :-) > My opinion is that there one change that would make this process > stronger is if there were a clear escallation path for cases such as > these. One that rarely overturned your decisions, but does do so with > just barely enough regularity to inspire confidence that the process > works. And if the changes were rare enough, and the people who were > responsible for handling the escallation actually offloaded work from > you, this would be a net plus. (Note: this is typically a role that WG > Chairs fulfill). The WHATWG has such a mechanism (the "members", as defined by the charter, have the authority and responsibility to overrule me if I make bad decisions), but I've so far managed to never make a decision that has required them to exercise this power. The W3C has such a mechanism too, known as "formal objections", with Tim making the final call after hearing the arguments from both sides. In my experience, Tim's decisions can be somewhat arbitrary since he doesn't have the same level of experience with the relevant technical details as the people who disagree on the decision. (This isn't in any way meant to be a slight on Tim. I imagine I would be equally unable to make well- informed judgement calls if I was asked to arbitrate an RDF or XML Schema decision, for instance.) I would be happy for the working to have an additional, working-group- specific, well-defined process for overruling me, so long as the people with the authority to do so are people who really understand the issues, e.g. people who have written browser code and who keep a close enough eye on the development of HTML5 to really have an informed opinion. (Maciej comes to mind as someone with this level of experience.) > > Just saying "reconsider this decision" doesn't cause the decision to > > be reconsidered. It doesn't matter when the decision was made. What > > matters is whether new information has come to light. > > "new" is relative and (given the lack of documenation) undefined in this > context. Additionally, if this group wants to be truly inclusive, it > needs to be able to find a way to accomodate people who weren't present > at the time provisional decisions were made. How should such accomodation happen? I agree entirely that people by and large won't know what has been considered and what hasn't. I mean, at the extreme, there are things -- many, many things -- that I've come up with, considered, and rejected, without ever mentioning them anywhere. How can anyone know? So it's fine for people to raise issues. The point is just that if their proposal _has_ already been considered, I don't have the bandwidth to go through and rehash the sometimes week-long discussions that such proposals deserve to get. So sometimes I (and others) say "we've already considered that, but rejected it because..." with some brief description of a problem, usually the main problem, rarely the only problem, that affects the proposal. Is that unreasonable? (Ideally, someone would then document this on a wiki page of "rejected ideas" or something, but nobody has volunteered to do that so far.) To give the specific example of the namespace parsing mechanism that IE implements which you have put forward several times: I read the whitepaper that Microsoft put forward on the day they announced it, and considered it carefully as I was reading it. I also had already considered IE7's parsing behaviour, and considered IE8's parsing behaviour as soon as I had IE8 installed and had gotten the workaround for their attribute DOM handling bug sorted out (thanks Philip`). You've since brought it up at least half a dozen times, both here and on your blog, and gotten a response each time (almost certainly a progressively shorter and shorter response), saying that those ideas had already been considered. You have never introduced new information, indeed as far as I can tell you haven't actually seriously considered what the proposal is and have never shown an actual example demonstrating that you truly understand Microsoft's proposal. What could I change in the way I respond to issues to make you feel like your suggestion has been seriously considered, as it indeed has? > > Nothing is immutable. Any decision can be reversed in the face of > > strong reasons and arguments and evidence. > > It doesn't always feel that way. Changes like this happen all the time. Just yesterday we reversed the decision on the issue of the <a> element's content model, an issue so big it has its own FAQ entry in the WHATWG FAQ. How can we make it more obvious? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 31 July 2008 21:01:45 UTC