Re: Path to polyfilling CSS functions?

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.

Received on Tuesday, 7 August 2012 15:40:18 UTC