[css-parser] (my) requirements

Hi there,

Here's a strawman proposal for css-parser, based on the following
requirements. I am deriving those requirements from my dogfooding of
JSCSSP in BlueGriffon, a few polyfills and my old STTS work:

  R1. access to the CSS scanner, so anyone can parse strings containing
      CSS constructs or even CSS-like constructs and get in return
      token objects. Think iterator or promise.

  R2. have, for version 1, a limited access to the CSS parser,
      but designing it nicely so it could be extended in the future if
      we wish:

      R2.1. parsing of a property value, made of one or more values,
            space- or comma-separated, returning object(s) representing
            a completely parsed representation of the value(s).
            "completely parsed" means here all data in the objects are
            atomic wrt the CSS Scanner. Cf. Typed OM ?

      R2.2. these value objects should offer a serialization API.
            Cf. Typed OM?

      R2.3. have an API to parse a selector, reporting CSS errors or
            not. If it does not report errors, it would still follow the
            Selectors' grammar and reply for "a:foo"
            as if |:foo| was a valid pseudo-class. All data in the reply
            should be atomic wrt the CSS scanner

      R2.4. have an API to compute the specificity of a string
            containing a Selector or of a parsed Selector, reporting
            CSS errors or not.

  R3. have an API to climb up the Cascade. All browsers now offer this
      in developer tools, but based on proprietary APIs. This is needed
      for polyfills.

  R4. an API to get the initial value of a given property. This is
      needed because CSS.supports() requires two values to work. So
      to test if "minimal" support for a given property is implemented
      or not, you need at least to know the initial value of the
      property... This could also be achieved extending CSS.supports()

  R5. have a trivial API replying the rendering engine's prefix. It's
      currently done by browser detection, a weak process that is borked
      by user-agent tweakers

Unfortunately, I won't be able to attend the meeting in Australia. I
will be able to call in, though.

</Daniel>

Received on Tuesday, 12 January 2016 08:09:07 UTC