Re: Path to polyfilling CSS functions?

On Tue, Aug 7, 2012 at 8:39 AM, Brian Kardell <bkardell@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 11:31 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Tue, Aug 7, 2012 at 8:00 AM, Nicholas Shanks
>> <nickshanks@nickshanks.com> wrote:
>>> On 6 August 2012 23:29, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>> This is stated as enabling polyfilling, with the implication being
>>>> that it's only used for things that are already supported in some or
>>>> all modern browsers, and you want to reproduce it in legacy browsers
>>>> or those that just haven't caught up to the spec yet.
>>>>
>>>> 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.
>>>
>>> You should consider such a polyfill developer as the first implementer
>>> of the ideas in the spec, and possibly one unconstrained by corporate
>>> structure, which may speed up communications.
>>>
>>> The polyfill developer can provide feedback that will help the spec
>>> progress to a state where it interests user agent developers, and I'd
>>> wager that website authors who are willing to use such an alpha-level
>>> polyfill will also be willing to update it through versions 0.2, 0.3
>>> and so on, changing their CSS along the way as the spec matures in
>>> step with the polyfill.
>>>
>>> You can't get the feedback you want for a spec without developers
>>> trying to implement it and authors trying to use it. As with any QA
>>> process, you want to start with a small group of testers, and expand
>>> as bugs are fixed. A polyfill implementation provides a much more
>>> limited testing ground than, say, a vendor prefixed implementation
>>> appearing in a public Chrome release, where the deployed base will
>>> suddenly balloon from zero to hundreds of millions, and website
>>> authors across the globe will begin using the feature regardless of
>>> vendor prefix.
>>
>> I completely agree with the sentiment, just not with the additional
>> consequences of the particular way that Boris is recommending we
>> accommodate this.
>>
>> I think that using variables as an "author prefix" to allow
>> polyfillers an easy way to see and manipulate the property in the OM
>> is a sufficiently good answer.
>>
>> ~TJ
>>
>
> For posterity and for the benefit of anyone on the list who might not
> understand what you mean by this Tab, maybe you could include some
> pseudo-code of a simple case to show how you would use variables to
> address the issue.

Sure.

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 stylesheet:

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

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 15:50:28 UTC