- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 19 Feb 2015 07:47:40 -0800
- To: Greg Whitworth <gwhit@microsoft.com>
- Cc: Brian Kardell <bkardell@gmail.com>, "public-houdini@w3.org" <public-houdini@w3.org>
On Wed, Feb 18, 2015 at 11:27 AM, 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. It's not even Parsing Level 2, it's just the CSS Extensions spec, already approved for ED. When I have enough meat to be worth it, I'll ask for FPWD on it. ~TJ
Received on Thursday, 19 February 2015 15:48:28 UTC