Re: Path to polyfilling CSS functions?

On Tue, Aug 7, 2012 at 7:25 PM, Sylvain Galineau <sylvaing@microsoft.com>wrote:

> Incidentally IE has supported a subset of your requirements in a rather
> natural way
> for many years. If you have something like:
>
> <!doctype html>
> <style>
>         #test {
>                 foo:bar;
>                 another: baz, even;
>         }
> </style>
> <div id="test"></div>
> <script>
>         var test = getComputedStyle(document.getElementById('test'));
>         alert(test.foo);
>         alert(test.another);
> </script>
>
> IE will alert 'bar' and 'baz, even'. We essentially cascade these unknown
> properties as name-value pairs. Figuring out whether the property is
> unknown
> does take a little more work e.g. instantiating a blank node and checking
> whether it's defined in the style property. There is no support for
> inheritance
> so have to roll it out yourself. But though it's simple it can be quite
> handy.
> I often wish other browsers did the same.
>

Great, didn't know IE had this behavior already! I agree with you
completely that it would be nice to have in other browsers too.

By keeping unknown properties around in the DOM, we get much closer to the
goal. This by itself would basically solve the problem for static sites:
you could iterate the DOM tree on DCL, filling in the gaps. As you mention
later, there caveats, especially for dynamic loading and cascading.


> Of course this doesn't make polyfilling functions or other extension to
> existing
> properties easy but that is a more complex problem to solve generally
> anyway:
> instead of parsing either known or unknown values we now have 'values
> unknown
> to the browser but known to the app', 'values unknown to everyone' and even
> 'values both the browser and the app want to do something with'... And we
> can't
> really tell which is which at parse-time without you somehow telling us
> before
> we load the stylesheets that use said values, even before there is a DOM.
> (I
> assume here we're not changing the CSS error handling model)
>
> You could still use the IE model to polyfill image() by prefixing the
> properties
> you're extending - e.g. xbackground - and either handle the whole value
> yourself
> or pass the 'safe' standard bits back to the 'real' property already
> exposed by
> the browser, as needed. For the reasons mentioned by Tab (among others) I
> don't
> think that's necessarily bad: you can add non-inheritable properties very
> simply
> and you could use the same mechanism to experiment with extensions to
> existing
> properties in some side namespace if you're willing to put in the work.
>

The problem with the var approach is that it's not a future-proof solution.
Once a site is deployed with var- or x- prefixed properties, it's quite
unlikely that it'll ever be updated (cf. stickiness of -webkit-transform).

Also, this approach requires section 4.2 of this spec [1] to be complete,
and for there to be implementors...

[1]: http://dev.w3.org/csswg/css-variables


> Of course there are other things to consider such as the ability to detect
> value
> changes but based on my positive experiences using this IE capability I
> wonder if
> a simple approach could still be a helpful first step, especially combined
> with
> Variables.
>

Definitely there are limitations, but this would be a great step in the
right direction.

I view polyfills as implementors of the spec and a mechanism to move
browsers forward. Especially given how easy it is to polyfill things
pertaining to JS and DOM, it seems like a no brainer to be able to do the
same for CSS.

Received on Saturday, 11 August 2012 06:17:18 UTC