Re: [parser] Scope question

On Wed, Feb 18, 2015 at 2:27 PM, Greg Whitworth <gwhit@microsoft.com> wrote:

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

Yeah, please don't misunderstand my comments as a demand that we do all of
it or do all of it at once, it's more about two things: 1) figure out
specifically what we want in which levels, iteratively 2) think about the
larger plan so we don't paint ourselves into a corner.

It seems clear to me that the parser in the browser itself is of very
limited use (not worthless by any means, just severely limited) if we can't
actually get at the same kinds of things the parser is parsing - I would
just like us to consider that and maybe think about how we plan to 'get
there' to answer those sorts of questions without creating lots of
intertwined dependencies.

I'm entirely fine with leaving it out for now, just think it's worth some
thought and discussion to keep refining the overall trajectory.

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