W3C home > Mailing lists > Public > www-style@w3.org > August 2012

Re: Pseudo-element proposal

From: Brian Kardell <bkardell@gmail.com>
Date: Tue, 7 Aug 2012 15:23:08 -0400
Message-ID: <CADC=+jfQGMnjWjbv2XTU8bSev7xZyc6K7u2befMLZcZexLbn7g@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:02 UTC