Re: [parser] Scope question

On Sun, Feb 8, 2015 at 10:37 AM, Brian Kardell <bkardell@gmail.com> wrote:
> We have decided to describe a parser which, I think, implies that we'll have
> a method (somewhere) that can take a string and give you back something more
> useful. This would *appear* to be a major boon for things that want to
> polyfill at the high level because as long as they conform to the forward
> compatible aspects of CSS they should be able to get -something- whereas
> today those values are dropped from the CSSOM.  I stress the word appear
> because its usefulness is actually limited unless you can actually get at
> the text in the first place and one of the major problems with anything
> doing polyfills (or prollyfills) today in CSS is that it requires you to
> refetch the stylesheets and sometimes you just can't because the link tag
> has special privileges... It doesn't require CORs so, for example, if
> bootstrap had something that included polyfilled rules (which you can
> definitely imagine it could) and you used it via a cdn or some basic asset
> server without CORs you just might not be able to access that.
>
> I think that an important part of this exercise has to be explaining the
> system and exposing hooks you can plug into so I'm wondering if that is in
> scope:  What I'd like to know is can we explain parser in terms of its
> calling by the underlying system as well such that, for example, you could
> get at the stuff thats being sent to the parser.
>
> In terms of my project, for example, we transform a custom pseudo class into
> a hash for a regular class and then manage the regular class.  This means
> that you have something like
>
> div:--math-lessthan(score, 100) { color: blue; }
>
> which will make divs blue if a div's score attribute is a numeric value less
> than 100 simply gets rewritten in the stylesheet to something like
>
> div.-some-magic-hash-code { color: blue; }
>
> and then we watch div[score] for changes and attach or detach the hash
> class... So, it's just normal CSS at that point and it's important that it
> maintain its place in the stylesheet and so on.  Ideally for this and a lot
> of cases like it then, you'd like to see some callback that gives me the
> opportunity to intercept the raw text and rewrite some unknown thing into
> something known (in fact, that is at some level how all p(r)olyfills work).
>
> So, my question is - are we considering that in scope or not and is that
> part of the parser effort or not?

My plan so far is:

1. Expose the parser directly, so you can feed whatever custom stuff
you want into it and get it parsed the same way CSS would (rather than
using a bag of regex hacks, or having to include a standards compliant
parser like the one I wrote).

2. Expose a number of specialized hooks for the things CSS already
knows about, like pseudo-elements, media queries, etc., so you can
extend those in specialized ways.

I don't think it's that useful to expose general hooks into the middle
of the parsing system for normal CSS.  Either you're hooking something
CSS already knows about, in which case we can offer a better API than
a generic parsing hook, or you're doing something brand-new that just
uses CSS-ish syntax, in which case we need to hand you the whole thing
anyway.

~TJ

Received on Wednesday, 18 February 2015 18:27:09 UTC