Re: Pseudo-element proposal

On 8/7/12 12:23 PM, "Brian Kardell" <bkardell@gmail.com> wrote:

>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.

While the pseudo-element rules in the prototype are not prefixed, they all
are quarantined in an "experimental" style block. So we're not *quite*
operating in the native space as if we're native.

I'm not opposed to adding prefixes, but one of the points of developing
the prototype was determining whether the proposed syntax is usable as
specified. This prototype is certainly not meant as a literal polyfill,
and I'd hope that its limitations (requires a separate style block, a
separate CSS parser in JS, and fakes the pseudo-elements with spans) would
keep it from being used as such.

Thanks,

Alan

Received on Tuesday, 7 August 2012 19:47:26 UTC