Re: Path to polyfilling CSS functions?

Le 07/08/12 00:02, Boris Smus a écrit :

> 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)

Being the craziest polyfiller around with my JSCSSP, I know the
feeling... But UnknownRule is not enough since it adresses invalid
_rules_ and not invalid _declarations_.
Invalid declarations are of two kinds:

1. invalid because unparsable as a declaration
2. invalid because the property is unrecognized by the local parser
    or because the set of the properties has an invalid value
    (unrecognized unit, new functional notation, etc...) but the set
    of tokens representing the declarations remains parsable as a
    property, a colon, and a set of values.

The second case seems easier to solve than the first one because it
only requires to store couples (property, value string). But from a
browser perspective, that's a footprint issue. Why do you want a browser
based on Gecko to store "-webkit-foo: blah" if there is nothing it can
do with it? Polyfilling based on the browser's parser would be
extremely expensive in memory.

The first case is probably harder to deal with since it requires
preservation of data that cannot be stored in the current CSS OM.
It requires an extension of CSSStyleDeclaration.

I have always advocated for a change of the OM to be able to deal with
invalid/dropped CSS stuff. It is extremely important for content
editors. Whitespaces, comments, unparsed stuff. Let's continue this
discussion, please.

</Daniel>

Received on Tuesday, 7 August 2012 05:47:17 UTC