How did I miss that?!? I have always been a strong supporter (and most certainly the first one) of the presence of selectors on the right hand side of CSS declarations (a CSS declaration is made of a property name followed by a colon followed itself by argument(s) and an optional semi-colon being the separator with the next declaration; of course, whitespace is allowed almost everywhere). I have myself used selectors there in my STTS language. And I only discover now that selectors on the right hand side of CSS declaration absolutely need, for parsing reasons, to be contained into a functional notation (like url(...) or attr(...)) unless the selector is the sole argument of the property. If this is not the case, you can't make the difference between "a b", "selector(a) b", "a selector(b)" and "selector(a) selector(b)" if both a and b are IDENTs. So it means that we need a general functional notation to encapsulate selectors on the right hand side of declarations in all cases, including the proposed new attr() notation.

I therefore propose two new functional notations. I don't think they can be gathered.

  1. condition(selector), represents a condition on the elements or pseudo-elements of a tree, exactly like the current usage of selectors in CSS
  2. fragment(selector), represents the complete flat description of a tree fragment, exactly like in STTS

PS: you win my deep consideration if you are not a former or present W3C Working Group member and if you can guess right what means the title...