[whatwg] Chipset support is a good argument

On Mon, 6 Jul 2009 09:02:51 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
> > 
> > You've expressed something similar in a couple of the other threads as 
> > well, and I find it puzzling. It's true that if you spec things that 
> > will never be implemented, it harms the integrity of the spec. But on 
> > the other hand, if you allow any one vendor to determine what does or 
> > does not go into the spec [1], you're are exposing the spec to a much 
> > greater risk.
> 
> What risk?
> 

The risk I described below, where any one-man browser vendor can get a good chunk of the spec axed.

> 
> > In at least one other thread [2] you've implied that you treat all 
> > browser vendors as equal. If you put this together with the veto power 
> > it means that any browser vendor, "regardless of size" can get things 
> > axed from the spec. Am I missing something? What is stopping me from 
> > becoming a browser vendor and stating flat-out that I will not support 
> > any of the new additions in HTML5 just to kill off a good chunk of the 
> > spec? (Since I am working on a browser currently playing catch-up, this 
> > would certainly make my life easier).
> 
> Nothing is stopping you from doing that.
> 

Seriously? If I were to declare that I, as a browser vendor, will not support anything in HTML5 that wasn't in HTML4, would you actually remove all the new additions from the HTML5 spec?

> > It seems to me that you need to either take away this veto power you've 
> > given browser vendors, or you need to draw a line between the vendors 
> > that do have veto power and the ones that don't.
> 
> I haven't given browser vendors this veto power, they have it regardless. 

No, the browser vendors don't make changes to the HTML5 spec. You do, since you're the editor. I'm not talking about indirect layers of abstraction where they influence what you write. I'm talking about the person who actually makes the cvs commits because when push comes to shove, that person is the one who is actually making the changes to the spec (or not making any change, as the case may be).

> If implementors don't implement the spec, then the spec is fiction. 
> There's nothing I can do about that.
> 

Ah, but there *is* something you can do, and you're doing it. What you're doing to combat the spec from becoming fiction is saying "if a browser vendor won't implement this, I will take it out of the spec". This works to keep the spec and reality in sync, and prevents the spec from becoming fiction. It also provides browser vendors the veto power I'm talking about.

> > If you have already drawn such a line, I would like to know exactly 
> > where it is and what criteria were used to determine which vendors to 
> > allow and which ones to disallow.
> 
> In practice, a browser vendor has to have an installed base of a percent 
> or so overall before they can really affect the direction of the Web.
> 
> This isn't a decision I have made myself. It's just how the world is.

I'm not talking about the direction of the Web. I'm talking about the text that resides at http://www.whatwg.org/specs/web-apps/current-work/. The two are not the same thing. One is supposed to be a representation of the other, but that doesn't happen magically. You are that missing piece in the middle that is taking the real web and translating into the text at that URL. And as such, in the case of conflicting vendor behavior, you are the one that gets to decide which vendors you will take into account and which ones you will not. So let me re-ask my question: if a browser vendor has an installed base of greater than "a percent or so", and they flat-out state they will not implement, e.g. all the new <input> types in HTML5, will you take them out of the spec?

If the answer is yes, I would like specifics as to where that "percent or so" number comes from. There's lots of different ways people use to measure market share, which one are you using?

kats

Received on Monday, 6 July 2009 04:49:31 UTC