Re: Path to polyfilling CSS functions?

On Mon, Aug 6, 2012 at 3:02 PM, Boris Smus <smus@google.com> wrote:
> Hi folks,
>
> CSS functions like image-set(), image(), are very useful for solving the
> responsive images problem. image-set() [1] has been agreed upon and
> implemented in Safari. However, from a web developer perspective, this
> feature is DOA until more browsers implement it, which may be many years
> away. The solution is to use polyfills.
>
> Writing polyfills for this should be easy, right? Well, not really. It used
> to be the case the the CSS object model would retain unknown CSS rules as
> UnknownRules. However, this changed in 2003 as a result of this email [2].
> As far as I know, there has been an attempt to get UnknownRule back into the
> spec [3], through a CSS Editing Task Force, but nothing ever came of this.
>
> So, today, we are stuck with sub-optimal solutions to this problem, such as
> using JSCSSP, a JS CSS parser [4]. Such a workaround would never be
> acceptable for production code because using it means that all CSS gets
> parsed once by the browser, and once by JS (a much slower path).
>
> It would be great if UnknownRule was still available, since it'd allow us to
> polyfill features missing from different browsers. It seems the removal of
> UnknownRule may have been premature - perhaps it's time to re-enable it.
> Does anyone have valuable input about how we could do this easily or have a
> better suggestion?
>
> Thanks!
> - Boris (Chrome Developer Advocate)
>
> [1]: http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html
> [2]: http://lists.w3.org/Archives/Public/www-style/2003Oct/0347.html
> [3]: http://lists.w3.org/Archives/Public/www-style/2010Apr/0274.html
> [4]: http://www.glazman.org/JSCSSP/

(We had this discussion privately as well, so I'll reproduce my side
of the argument here as well.)

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.
 The CSSWG does all of its work publicly and updates continuously, so
it's very possible for an early draft of a feature to show up in an ED
many months before any implementor actually cares about it, and thus
long before any serious review of the feature happens.  We commonly do
significant rewriting once that happens.  (We have a problem with
rewriting things at all times, but at least here, it's reasonable to
do rewriting before implementations occur.)

We're already experiencing pain from this, when people write multiple
prefixes and then include the prefixed version to "future-proof" their
code, which harms our ability to change things when we actually do
unprefix.

Further problematic is people inventing their own CSS properties that
aren't drafted *anywhere* in places that implementors care about.  One
of the use-cases of Variables is to specifically enable this in a safe
way, that doesn't interfere with anything the CSSWG does in the
future.  Web Components addresses the same thing in a similar way -
you can invent your own elements, but you prefix them with "x-" to
avoid clashing with future real element names.

So, using variables as a sort of "author prefix" similar to vendor
prefixes is about the best I think we can easily hit.

~TJ

Received on Monday, 6 August 2012 22:30:12 UTC