RE: [cssom] unrecognized rules and properties

Anne van Kesteren wrote:
> On Sun, 22 Nov 2009 13:14:58 -0200, Mike Wilson wrote:
> > What case has been made for removing this support? IMO
> > there are strong arguments for having it.
> 
> This was decided long ago based on that implementations did 
> not have to keep the rules around. 

@implementors
Would you please speak up and tell what specific problems you
were having with retaining this data?

> If we want to change this I'm not sure a grammar-based
> approach for the defining the CSS parser is appropriate  
> anymore since we'd need to define exactly which strings end 
> up in the DOM for any kind of input.

I've been assuming that any unrecognized entity still need to
conform to the basic CSS syntax, so that unrecognized 
statements don't throw the parser off-route. 
To me the intent with CSSUnknownRule seems to be mainly to 
support rules formated according to normal syntax, but with
an unrecognized identifier after the @-sign. This seems
trivial to include in the parser, but you mention that the
grammar-based approach may have a problem with that. 

One may choose to apply grammars at different levels of 
detail, so I'm not entirely sure what is the specific problem. 
Have there been changes in these areas since the last CSSOM 
spec? (sorry if this is obvious, haven't been following)

When it comes to unrecognized properties, I don't see any 
parsing problems really. Of course, the CSSOM cannot do any
processing of property values as the type is unknown, and 
should return them literally, but apart from that I see no 
big impact. Or am I missing something?

Finally, I'd like to mention a few reasons why unrecognized
CSS should be retained:

1) It is the nature of the web to be permissive and let 
   unrecognized data be dealt with downstream.

2) The DOM retains unrecognized elements and attributes (I
   don't think anybody is suggesting to throw them out?),
   which for the sake of discussion map well to CSS rules
   and properties, respectively.

3) CSS not recognized by a certain browser may very well be
   inspected by a client-side library emulating the
   feature instead. This very mail thread sprung from a 
   discussion about being able to implement CSS transitions 
   for older browsers, by examining the CSSOM and running 
   client code for browsers without transition support.
   IMO weighing in the ability to use client-side libraries
   for compatibility support is a major point for CSS 
   forwards compatibility, and is something that should be 
   taken into account for any new standard.

4) IE does it.

--
Mike

Received on Tuesday, 24 November 2009 08:44:01 UTC