W3C home > Mailing lists > Public > www-style@w3.org > May 2013

Re: [css-syntax] Comments on Parsing and following sections

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 29 May 2013 13:28:32 -0700
Message-ID: <CAAWBYDDQEMfvRrHQ-0JFMsbaY9QyQN063GdN7vmHjgcVL4ksFA@mail.gmail.com>
To: Simon Sapin <simon.sapin@exyr.org>
Cc: www-style list <www-style@w3.org>
On Tue, May 28, 2013 at 8:54 PM, Simon Sapin <simon.sapin@exyr.org> wrote:
>>> Also, css-conditional already has a concept of "nested statements".
>>
>> I'm not sure what this has to do with this section.
>
> My point is that Syntax 3’s <stylesheet> seems to be the same as Conditional
> Rules’s "list of nested statements". By definition, it seems that
> <stylesheet> would only be used by conditional rules, and so might be
> redundant.

Maybe, I dunno.  Possibly we'll need it for more things later on.  The
intention, though, is that all at-rules should convert over to being
defined by this syntax, *including conditional rules*.

>>>      For example, the ‘@font-face’ rule is defined to have no prelude […]
>>>
>>> I think a definition of @font-face in Syntax 3 terms would still have to
>>> be
>>> a bit more formal. Its prelude must either be empty or contain only
>>> whitespace tokens. (All at-rules have a prelude.)
>>
>> Whitespace is always ignored; a prelude containing only whitespace is
>> identical to a prelude containing nothing, as far as the grammar is
>> concerned.  (I've added a sentence about how whitespace is never
>> indicated in the grammar explicitly.)
>
> Saying "always" or "never" here is a problem. Page selectors in the prelude
> of @page rules *are* sensitive to whitespace. I wouldn’t be surprised if we
> add Selectors (and thus more whitespace-sensitivity) in other contexts in
> the future.

Ah, you're right.  Preludes may be whitespace-sensitive.  I'll fix.

~TJ
Received on Wednesday, 29 May 2013 20:29:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 29 May 2013 20:29:23 UTC