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

Re: Path to polyfilling CSS functions?

From: Brian Kardell <bkardell@gmail.com>
Date: Tue, 7 Aug 2012 12:06:30 -0400
Message-ID: <CADC=+jebT37-r-=h0-_qXd5Ry2MWMk+uwpSyw48rHaTz-b+C6w@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style@w3.org, Nicholas Shanks <nickshanks@nickshanks.com>
On Aug 7, 2012 11:49 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> Say we introduce a brand-new property, like 'image-rendering' from the
> Images 4 draft <http://dev.w3.org/csswg/css4-images/#the-image-rendering>.
>  You'd like to polyfill it by doing your own drawing in <canvas>.
> You can use vars as an author prefix here, putting this in your
> "var-image-rendering: pixelated;"
> The polyfill can then scan through the DOM looking for this property,
> and do its polyfill magic wherever it finds the property set.
> This is basically identical in usefulness (and pain) to a vendor
> prefix, and has the same issues with forward compatibility.  Authors
> may or may not include the unprefixed variant alongside it, and the
> same arguments over whether to do so or not apply.

Not exactly, right?  I suppose to some extent this remains to be seen and
we have very limited data on this particular case, but it seems an entirely
different case to me.  If, as you say, someone took your rev 1 released
yesterday and created an implementation based on it - first thing would be
not to call it a polyfill I think since there is no definitive thing
implemented in numerous browsers that you are backfilling... The difference
then would be that an author would opt-in to a specific API and have a
single way of doing so rather than a prefix for every browser. You could
adjust API, fix bugs, etc in the standard way that you would with any JS
library - you make the choice, it isn't automatically pushed out underneath
you.  It seems to me that the expectations are potentially very different
and the outcomes are more positive - anyone (including W3C folks) could
push out implemenations that could serve to work out the kinks before
anyone worried about doing anything natively (for a lot of stuff at least).
 The path to getting from vendor prefixed/flagged to native could
potentially be much shorter as a result too.

> The same basic thing applies to new values - rather than prefixing the
> value, you just again prefix the property and use the value directly.
> ~TJ
Received on Tuesday, 7 August 2012 16:06:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:20 UTC