- From: Brian Kardell <bkardell@gmail.com>
- Date: Tue, 7 Aug 2012 15:23:08 -0400
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Cc: www-style@w3.org
On Tue, Aug 7, 2012 at 3:06 PM, Daniel Glazman <daniel.glazman@disruptive-innovations.com> wrote: > Le 07/08/12 20:52, Brian Kardell a écrit : > >> I love that this is available in JS, a few of us have been proposing >> that this is an excellent way to get things rolling, etc... >> >> However, even in another thread today we were discussing prefixing, >> forward compatibility, etc. and I feel like suggesting that this would >> be even better if it did not try to literally polyfill something in >> the native space which may or may not be implemented in the future >> with similar/partial APIs or differences. Does anyone else think that >> it might be better to prefix the experimental pseudos? > > > Experimental pseudos are prefixed by all browser vendors. Adobe's > JS code is a more a proof of concept than code that should be used > in production environments, and that code is, to the best extent, > browser-agnostic. That's why the prototype has no prefixes for the > proposed new pseudos. > > </Daniel> > My comment had nothing to do with browser agnosticism, I completely get that. My own project is the same way - I love this model (POC in JS way before browser impls). I have brought up related questions on this before last year and again earlier this year... It doesn't seem to me to be the first time that someone has suggested that anything author-defined should be prefixed... I see no real reason why this should be different. This is masquerading in the native space as if it were native, so if it ever were implemented there might well be API differences. Why shouldn't there be a single simple logic that applies in all cases? Again, maybe I am alone in that, but it seems weird that proof of concept requires no prefix, but then browsers do and then later it doesn't. Those seem like three different potential phases that shouldn't interfere - as long as they don't use a -moz- prefix or something there is no danger that they could interfere (or conflict) with a browser implementation, but native they could.
Received on Tuesday, 7 August 2012 19:23:36 UTC