RE: [parser] Scope question

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

I would prefer to do these in easy bite size chunks so that we can get the least contentious items (from political and technical standpoints) into the platform as soon as possible, rather than haggle over technically complicex or Houdini dependent (IE: Custom layouts will greatly benefit from the read only box tree) items. I think Tab's 1 and 2 above should be L1 and L2 for the parser spec. We all already have L1 in our engines, just define the API for L1 and commit it and we can start lighting that up in the platform in the next year or so.

Please don't take this as downplaying your need for custom access to additional hooks, I just would prefer to light up what we can sooner rather than later and keep adding to the backlog where necessary (and technically feasible).

If I've misunderstood you somehow, please let me know.

Thanks,
Greg

Received on Wednesday, 18 February 2015 19:27:56 UTC