- From: Chris Wilson <Chris.Wilson@microsoft.com>
- Date: Mon, 27 Apr 2009 09:29:48 -0700
- To: Ian Hickson <ian@hixie.ch>
- CC: Larry Masinter <masinter@adobe.com>, "www-tag@w3.org WG" <www-tag@w3.org>
Ian Hickson [mailto:ian@hixie.ch] wrote: >On Fri, 24 Apr 2009, Chris Wilson wrote: >> The only way out of this would be for EVERY browser to very carefully >> only ship "proprietary-marked" (a la CSS' vendor extensions) versions of >> APIs/elements until the standard moves OUT of CR, and then add support >> for the standard naming and deprecate their proprietary-marked versions >> over time. > >Or at least, to do so with features that don't have obvious ways to be >updated without needing version syntax. Why is that a problem? I didn't say it was - but aside from CSS, that's not what is happening. Actually, there is the problem that web developers would have to abstract their code to point to the mostly-interoperable implementations of a feature, until that feature moved out of CR - you shouldn't use <canvas> today, then, you should use <webkit-canvas>, <moz-canvas>, etc. We've had this question internally - e.g. for rounded border corners, should IE bother doing -ms-border-radius, or just skip straight to border-radius? I'm not against the above as a process, you understand - I'm just pointing out that this isn't the way that vendors are doing things today, outside of CSS. >In the case of the spec changing while there is already an implementation, >it's not like the spec is going to have BOTH versions defined, and it's >not like other browsers are going to want to impement BOTH versions. It sort of depends what third-party applications are built on that browser-specific implementation, I expect. Sort of like if GMail is built on Safari's SQL store support, and the spec changes to abstract that more. What should the spec do, in this case? -Chris
Received on Monday, 27 April 2009 16:28:24 UTC