W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [CSSOM] Searching/Navigating stylesheets

From: Alan Gresley <alan@css-class.com>
Date: Wed, 13 Apr 2011 20:39:04 +1000
Message-ID: <4DA57D48.6030806@css-class.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
On 12/04/2011 8:25 AM, Tab Atkins Jr. wrote:
> On Mon, Apr 11, 2011 at 2:44 PM, Boris Zbarsky<bzbarsky@mit.edu>  wrote:
>> On 4/11/11 12:57 PM, Tab Atkins Jr. wrote:

>>> the error-handling implicitly looks for things that look like property
>>> names and values so it can skip over them properly.
>>
>> No, the error-handling just looks for ';' not inside
>> parens/brackets/quotes/etc.  It's pretty easy to create things that look
>> nothing like allowed property/value pairs and that current CSS parsers skip
>> over just fine; you'd need to define new CSS parsing rules to make this work
>> at all.


It this is what scares me. Talk of 'new CSS parsing rules'.


> Ah, kk.  Webkit's Inspector does indeed attempt to parse invalid CSS
> as an unknown property/value pair, and displays it.


You would be very surprised in what can be parsed and how this is 
different from engine to engine. I thought the days of parsing garbage 
was over.


> For example, if I
> create a document with<div style="foo:bar;"></div>  and inspect the
> element, I'll see a "foo:bar" property there flagged as invalid.
> The additional parsing rules should be relatively trivial


Have I received any reply to this list message [1]. This is not trivial. 
It get wilder with other tokens.


> - just split
> the invalid content at the first ':'.  If the content preceding the
> colon matches the property-name production, trim the whitespace off
> both pieces and expose it as an invalid property.  Values are only
> exposed as strings in current CSSOM


For my own knowledge, what does this string look like? Should we use the 
term CSSOM strings so this is not confused with CSS2.1 strings in CSS?


> , and we can decide whether to try
> and be smarter about things when we decide on a more advanced CSSOM
> interface.
>
> (This could also be expanded to allow exposing custom @-rules inside
> of blocks, once we allow that sort of thing.)
>
> ~TJ


Have you tested custom @-rules inside of blocks? Are there many test of 
custom @-rules outside of blocks? You have been proposing syntax that 
breaks current parsing rules where this doesn't have to be done.

Just one test which relates to my reply to you on this list [2].


http://css-class.com/test/css21testsuite/at-rule-026.xht


To allow this,

   @trait bar(foo) { ... }


we must consider what happens with this.

   @media all and(min-width: 1px) {
     body p { background: orange }
   }


Inside blocks we can have this,

   IDENT {
     property: value
   }


where you have proposed this.

   IDENT {
     @at-rule: value
   }


This is after I have said that any '@at-rule: value's followed by a 
semicolon ';' are dangerous if not inside a string. The strings I 
talking about are between ''......'' or '"....."'


  @at-rule: ".....";



[1] http://lists.w3.org/Archives/Public/www-style/2011Apr/0279.html
[2] http://lists.w3.org/Archives/Public/www-style/2011Apr/0005.html



-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Wednesday, 13 April 2011 10:39:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:39 GMT