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

Re: Path to polyfilling CSS functions?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 7 Aug 2012 08:31:58 -0700
Message-ID: <CAAWBYDBYQUfSo81hGi5PPAyGkKnT4oXHyorG+MY0oNeEmwDfbw@mail.gmail.com>
To: Nicholas Shanks <nickshanks@nickshanks.com>
Cc: www-style@w3.org
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.

Received on Tuesday, 7 August 2012 15:32:50 UTC

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