Re: [cssom] Unrecognized - request for more information

I think this basically gets into what such a proposal would have to say...
We can work that out.   I'm merely looking for a really basic subset parse
that gives us something more akin to a syntax tree or some nice intermediate
meta structure based on "well formed" data.

Since I can think of no parallel in CSS for the later case, I would think it
was not well formed and would just fall out as it does now.  Are you saying
that it shouldn't Daniel?


On Tue, Jul 26, 2011 at 1:05 PM, Daniel Glazman <
daniel.glazman@disruptive-innovations.com> wrote:

> Preserving "unrecognized rules" is only a subset of the errors
> that can happen in a CSS stylesheet. For example, an error inside
> a declaration block could still be parsed as a property name, colon
> and value(s) OR be totally different. Look at the following two
> examples:
>
>  #foo {
>    color: red;
>    -my-own-property: "these are my" "values";
>    margin: 1em;
>  }
>
> and
>
>  #foo {
>    color: red;
>    hello world;
>    margin: 1em;
>  }
>
> In the former case, things _could_ be reachable as a couple (property,
> value) but offering support for the latter case implies we have only one
> string...
>
> Same issue for @rules or style rules with unrecognized selectors.
>
> We can all live with strings only, but of course it means parsing is
> handled in the client code.
>
> Another important unpreserved case is comments. I don't see any simple
> solution here because CSS explicitely says comments can happen anywhere
> between tokens... In my own parser JSCSSP, I'm currently dropping
> comments happening between non-related tokens. I preserve comments
> between rules and between declarations. Better than nothing.
>
> Preservation of CSS comments is a *major* feedback from CSS authors for
> all web-based content editors. At this point, I do believe the next
> level of CSS should switch the policy for comments and allow them only
> between constructs (rules, declarations) , not anywhere between tokens.
>
> </Daniel>
>
>