Re: Path to polyfilling CSS functions?

That isn't exacly wild speculation, if history is any indication at all,
they will.

Today we have developers regularly start using prefixed properties for all
the major browsers and an unprefixed after they land in the  first browser
thinking that this makes it long term future proof.  In reality though,
those early ones are often changed a whole lot before they ever make it and
those sites are then just wrong - there is no way for the developer to
prognosticate what might happen or might not happen there...

This model is less than ideal, and polyfilling in the sense of allowing
devlopers to make a native property work where it currently does not
doesn't really make the problem better, in fact, it kind of makes it worse.

However, allowing them to do things in an author reserved space could make
things better.   Authors could include author prefixed versions which allow
for emulation of _some_ early api and then whether it matches what
ultimately gets decided upon is irrelevant from the standpoint that their
website will not break...it may be suboptimal once a native version is
universal, but it won't break. It also allows good ideas to come
before/decoupled with browser implementations which has all kinds of
potential practical benefits, not the least of which is that we can get
some ideas on what people really want/use and what is just too esoteric for
the average dev before browsers commit to implementing which on more than
one occasion has been cited as a problem:  it is difficult to set dev
expectations about early features unless they are behind a flag...thus,
once something gets out there, it actually can take some political will to
change it.
On Aug 6, 2012 7:11 PM, "Marat Tanalin | tanalin.com" <mtanalin@yandex.ru>
wrote:

> 07.08.2012, 02:29, "Tab Atkins Jr." <jackalmage@gmail.com>:
> > The problem with this, and the reason why we've resisted re-adding
> > something like this, is that the functionality will also be used to
> > polyfill things *ahead* of any implementations, based on early drafts.
>
> May, not will. It's just your assumption. Let's not confuse reality with
> some imaginary future.
>
> Fear of improper use of an important useful feature cannot at all be a
> reason to abandon that feature.
>
>
> > using variables as a sort of "author prefix" similar to vendor
> > prefixes is about the best I think we can easily hit.
>
> JavaScript access to unsupported CSS properties/values for the purpose of
> polyfilling has nothing to do with variables or "author-prefixes".
>
>