W3C home > Mailing lists > Public > public-houdini@w3.org > April 2015

[parser-api] Polyfilling CSS

From: Paul Irish <paul.irish@gmail.com>
Date: Thu, 2 Apr 2015 11:10:22 -0700
Message-ID: <CAHSVx=_36iCfsV+h+Dh4hJqGJh7YA83PbZsVLrguMuY8ae+YkQ@mail.gmail.com>
To: "public-houdini@w3.org" <public-houdini@w3.org>
If you look at most of the polyfills listed in the CSS section here:

… you'll find that nearly all of them ship with their own CSS parser,
written in JS. (Typically using either glazman's or Tab's). Naturally, they
also have to XHR in current stylesheets and deal with CORS and all that. :)

You've probably heard of most popular
<http://trends.builtwith.com/javascript/Respond> of these: Respond.js

This stuff is so common Philip Walton wrote a single library to automate
this stuff: http://philipwalton.github.io/polyfill/
But obviously, the total filesize and execution overhead for all this work
is considerable.

So houdini has an opportunity to address this.   Brian Kardell pointed me
to the Sydney discussions on a CSS Parser API
<https://lists.w3.org/Archives/Public/public-houdini/2015Mar/0008.html> which
has me quite excited. Much of the discussion was around tooling needs from
the parser, but I wanted to share this developer-driven need.

Primary usecase:

   - I want to keep all my style information in the stylesheet, even things
   not consistently supported across all browsers. I want to drop in a JS
   polyfill for those ones.
   - I need a hook for unrecognized items like rulesets, @at-rules and
   - For rulesets, I want a mechanism to address matching elements.

Received on Thursday, 2 April 2015 18:11:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:23 UTC