Re: [parser] Scope question

On 08/02/2015 19:37, Brian Kardell wrote:

> div:--math-lessthan(score, 100) { color: blue; }

Let me go back to my original idea of opening up the parser and what
it means for me... And to do that, let me first list things I am heavily
relying on in my editor BlueGriffon and I can't have access to as of
today:

   - preserve unrecognized stuff (rules, properties, values, ...) in the
     OM
   - preserve comments in the OM
   - call the CSS parser to parse tokens contained
     in a string, to either return a structure or a chain of tokens,
     from a context point (expect a rule, a selector, a block, a value,
     etc.)

I also miss a lot of things on the Serializer's side but that's another
story.

To implement your user-defined selector above, there are two main
different strategies. The minimal one requires, as you said, an access
to the stylesheet's contents, either in text format or in a structure
preserving unrecognized pseudos in some way. I think preserving
unrecognized stuff will be extremely difficult if not impossible. So
you're stuck with reparsing the stylesheet's contents OR extend the
parser so it does recognize your user-defined pseudo, that's the
second strategy and the one that I think should be our goal.

Tab has some thoughts in a document about a declarative way of extending
the CSS parser. I find them quite complicated from a web author's
POV but they're an excellent start for the discussion. FWIW, I still
think a subset of JS restricted to getters would be a way better option
that would trigger an immense response from the web authors community.
It's not only technical here, we want authors to switch to our new ways
of writing polyfills and the solutions we provide them with have to be
simple to learn and use.

But let's go back to my original requirements above and let's focus on
the last one, the one I think we can all agree on. I envision a
parser object with a parse() method taking 2 or 3 arguments. First,
a string... Then a second argument specifying what to expect
(stylesheet, rule, selector, declaration block, value,
anything else?). That method would return an OM object. A third argument
would be a boolean declaring if unrecognized (but parseable) data are
preserved or not; this is doable and only depends on our capacity to
have a better OM generic enough to handle that. We need OM extensions
any way for that.

We also need something I call the getTokenIterator() method returning a
token iterator and accepting a single string argument. If parse() can
be in a Level 2, I think we absolutely need that one in a L1.

In my dreams, I want your selector above to be usable in any browser
just adding in a stylesheet a CSS Parser extension declaring
"math-lessthan" as a user-defined pseudo, listing its arguments and
specifying the magic it does to return a boolean.

You problem of stylesheet access is IMHO out of scope here and not in
our hands...

</Daniel>

Received on Thursday, 19 February 2015 09:17:53 UTC