- From: Paul Irish <paul.irish@gmail.com>
- Date: Thu, 2 Apr 2015 11:10:22 -0700
- To: "public-houdini@w3.org" <public-houdini@w3.org>
- Message-ID: <CAHSVx=_36iCfsV+h+Dh4hJqGJh7YA83PbZsVLrguMuY8ae+YkQ@mail.gmail.com>
If you look at most of the polyfills listed in the CSS section here: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills#css-core-modules … 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 <https://github.com/scottjehl/Respond>. 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 selectors. - For rulesets, I want a mechanism to address matching elements. Thanks!
Received on Thursday, 2 April 2015 18:11:23 UTC