Re: [CSSWG] Minutes Telecon 2012-10-17

On Wed, Oct 17, 2012 at 3:50 PM, fantasai <> wrote:
> CSS3 Conditional Rules
> ----------------------
>   ...
>   fantasai: If we're treating unknown things as false, we should treat
>             more things that are unknown as false
>   fantasai: e.g. right now anything that doesn't parse as a declaration
>             inside parens will make the whole rule invalid
>   fantasai: Would be more consistent to make that false also.
>   dbaron: I think that's fine, why would we want anything else in there
>   dbaron: We are making functional notation the way for future extensibility
>   fantasai: Are we sure that's how we want to do it? Did we have that
>             discussion.
>   dbaron: Yes, that was why we're doing it this way.
>   [...]
>   fantasai: So, the bare parentheses is in effect a functional notation
>             (without a name) that accepts property declarations
>   fantasai: If the contents are not a property declaration, the entire
>             rule is invalid
>   fantasai: Whereas for other functions right now, regardless of what
>             they contain, they're as false, and do not make the entire
>             thing invalid
>   fantasai: However, suppose we introduced a function in the future that
>             took xyz production.
>   fantasai: If a stylesheet contained that function with invalid contents
>   fantasai: If we followed the same pattern of making the entire rule
>             invalid because the contents don't parse correctly
>   fantasai: That would mean that old UAs would treat it as false, but
>             new UAs would make the entire rule invalid.
>   <SimonSapin> fantasai: good point
>   TabAtkins: Functional notation is false no matter what it contains
>   fantasai: My point is, either you are getting the different behavior
>             between old/new UAs that I explained OR you are treating the
>             invalidation rules of bare parens different from functional
>             notations, which is inconsistent.
>   dbaron: It's a bit complicated, because the contents of a parentheses
>           could either be property declaration or be a logical clause
>   dbaron: I'm okay either way
>   TabAtkins: I'd like to think about this a bit
>   dbaron: But it would require redoing a bit of our implementation.
>           But if we decide it's the right thing, we'll do it.

After discussing this with fantasai, I'm fine with her preferred
solution - treating parenthesized groups the same as a function, where
if the grammar isn't recognized, it's treated as false rather than a
syntax error.

I'm not 100% sure how best to represent this in the spec, though.  I
think we need two levels of grammar - one for the rule itself that's
extremely loose, and then a tighter grammar for what we actually
recognize as a supports condition.

I think this would mean replacing the grammar for 'supports_condition'
with just 'any' (from the Chapter 4 grammar), and then moving the
current grammar into defining the grammar of parenthesized groups.


Received on Tuesday, 23 October 2012 20:27:26 UTC