Re: Path to polyfilling CSS functions?

On Sat, Aug 11, 2012 at 1:42 AM, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
> On Sat, Aug 11, 2012 at 7:16 AM, Boris Smus <smus@google.com> wrote:
>> The problem with the var approach is that it's not a future-proof solution.
>> Once a site is deployed with var- or x- prefixed properties, it's quite
>> unlikely that it'll ever be updated (cf. stickiness of -webkit-transform).
>
> If these properties are implemented by author polyfill rather than
> browsers, it wouldn't need to be updated, since other/future browsers
> would be able to execute the polyfill?

Yes, I'm much less concerned about "author prefixes" sticking around
forever, because they'll just *work* in the future, without producing
weird incentives for browsers (other than "keep supporting CSS
Variables").

It means that a page may run JS that it doesn't strictly need to, but
that's okay.  Well-written polyfills check for the real version of
wahtever they're mimicking already, and with the addition of the
supports() function, this will be trivial.  (The only problem case is
if the polyfill was written against a particular version of the
grammar, and we changed the meaning of the grammar without changing
its form.  We already have to deal with this, though, and I don't
think it's a big deal.)

~TJ

Received on Saturday, 11 August 2012 16:42:23 UTC