Re: [parser] Scope question

On Wed, Feb 18, 2015 at 1:26 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

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

The problem, again, is more like that you can't get at the custom stuff to
send it to the parser in the first place because link is special.

-- 
Brian Kardell :: @briankardell :: hitchjs.com