Grammar for @media versus general block parsing

Web Development Archives Sponsor:

June 24th, 2008, 12:10 PM

Justin Rogers

Guest

Posts: n/a
Time spent in forums:
Reputation Power:

Grammar for @media versus general block parsing

An @media block in the grammar is defined as a MEDIA_SYM followed by an LBRACE followed by optional rule-sets followed by an RBRACE. Because @media is a known at-block with pre-defined semantics we treat the grammar piece as absolute and I think other browsers do as well, but there is one discrepancy. Here is the test case and the results.

<!Doctype HTML>
<style>
@media all
{
@import url(foo.css);
DIV { color: red; }
}
</style>

<DIV>Hello</DIV>

IE 8 - Black
9.5 - Black
Safari 3.1 - Black
Firefox 3 - Red

What I believe to be happening is that Firefox treats the @media block as if it were a general block and so it detects the @import as an at-rule and follows at rule semantics and therefore throws it out cleanly. It can then process the following selector. In IE 8 we try immediately to parse a rule-set, which fails at the @ token, and so we go into rule-set recovery which eats the following block. If you add a second DIV rule, both IE and will pick that one up. Safari fails to pick it up (not sure why). Firefox will definitely pick it up because it picked up the first one, so the second is simply normal parsing.

So the question is, should the grammar in this case be read strictly since it clearly points out a semantic for the @media block, and thus only allow rule-sets making the /IE 8 behavior correct? should the parsers allow any statement within the block including the at-rule?

Justin Rogers [MSFT]

June 24th, 2008, 11:50 PM

Boris Zbarsky

Guest

Posts: n/a
Time spent in forums:
Reputation Power:

Grammar for @media versus general block parsing

Bjoern Hoehrmann wrote:
* Justin Rogers wrote:
>So the question is, should the grammar in this case be read strictly
>since it clearly points out a semantic for the @media block, and thus
>only allow rule-sets making the /IE 8 behavior correct? should
>the parsers allow any statement within the block including the at-rule?

CSS Level 3 allows using e.g. @page as child of @media, so you will end
up implementing the latter behavior either way.

I think the real question is what CSS2.1 should say, or CSS3 should say
for UAs that don't support @page to make @page usable inside @media

Sounds like the Gecko behavior is what will be needed to make the rule
following the @page not disappear in UAs not supporting @page.

-Boris

July 2nd, 2008, 05:30 PM

fantasai

Guest

Posts: n/a
Time spent in forums:
Reputation Power:

Grammar for @media versus general block parsing

Bert Bos wrote:

The grammar in Paged Media confirms CSS 2.1 in that respect, because it
requires semicolons to separate the margin boxes. Adding some
semicolons to fix the examples is easy. But those examples show how
tempting it is to write them without semicolons

Is it too late for a different syntax for margin boxes? E.g., rewriting
example V in 3.5.1:

@page ::top-left { }
@page ::bottom-center { }

@page :left ::left-middle { }
@page :right ::right-middle { }

@page :left ::bottom-left-corner { }
@page :right ::bottom-right-corner { }
@page :first ::bottom-left-corner { }
@page :first ::bottom-right-corner { }

The double colons are not nice, but they do remind one of
pseudo-elements (just like the single colon in ':first' reminds one of
pseudo-classes). And they actually avoid a pair of curly braces, which
is worth something, too.

Unfortunately @margin-boxes are already implemented in at least three
implementations.

~fantasai

July 2nd, 2008, 08:50 PM

Grant, Melinda

Guest

Posts: n/a
Time spent in forums:
Reputation Power:

Grammar for @media versus general block parsing

I said:
There are at least three shipping implementations that
support @page inside @media. They do not require a
separating semi-colon, although every version of the spec
since it included a grammar has indicated they should. So it
seems that either the spec or implementations must change

It's also worth considering that there have been erroneous examples in the specification since 2003 (omitting the separating semi-colon), so we've inadvertently encouraged this interpretation. It would therefore seem to be preferable to 'legalize' the absence of a semi, if possible.

Best wishes,

Melinda

July 3rd, 2008, 10:50 AM

fantasai

Guest

Posts: n/a
Time spent in forums:
Reputation Power:

Grammar for @media versus general block parsing

Bert Bos wrote:

So, if we can't pull margin boxes outside of the @page block anymore,
then we'll unfortunately have to accept semicolons.

The only way to avoid the semicolons, I think, is to require instead
that all margin boxes must come *after* all declaration. Thus this is
wrong:

@page {
@top-left {content: "Chapter 1"} /* WRNG! */
margin: 0
}

and this is correct:

@page {
margin: 0;
@top-left {content: "Chapter 1"}
}

I was thinking that, too, myself. Unfortunately we already have
at least two shipping implementations (Prince and HP) that accept
both of the above. We could require it for authors and have the
validator flag the first example as invalid, but implementations
would still need to support both syntaxes.

~fantasai

July 3rd, 2008, 06:30 PM

fantasai

Guest

Posts: n/a
Time spent in forums:
Reputation Power:

Grammar for @media versus general block parsing

Bjoern Hoehrmann wrote:
* fantasai wrote:
>Proposal:
>Change 'ruleset' to 'stylesheet' in the @media grammar.
>State in 7.2.1 that "At-rules inside @media are invalid in CSS2.1
>and must be ignored per 4.2 Rules for handling parsing errors."

That would allow CD and CDC in @media which is probably not intended. I
tested this when the issue came up, I think only IE6 had interesting be-
havior for this case.

So would only making the change in 7.2.1 and not changing
the grammar be adequate?

~fantasai

July 8th, 2008, 08:00 PM

Grant, Melinda

Guest

Posts: n/a
Time spent in forums:
Reputation Power:

Grammar for @media versus general block parsing

Justin said:
Grammar wise adding at-rule will force me to put in code to
process at-rule's within the media block. Spec wise saying
that at-rules are to be ignored if present (and consequently
that at-rule error recovery should be used on a syntax error
and not rule-set error recovery) will make the forward
compatible stuff work as expected.

Specing that at-rules inside @media are to be ignored in CSS 2.1 and understood in CSS3 will I think lead to some undesirable outcomes. (For instance, we will or should create a test for 2.1 that must fail as a CSS3 test.) It's not clear to me, since CSS doesn't do versions, how a browser will know it is processing a 2.1 stylesheet, and therefore must ignore embedded at-rules, as opposed to processing a CSS3 stylesheet, in which case it must process the embedded at-rules.

It seems to me preferable to just add at-rules to the 2.1 grammar. Implementations will need to be incorporating that behavior as they move to CSS3 anyway.

Best wishes,

Melinda

July 30th, 2008, 05:00 PM

fantasai

Guest

Posts: n/a
Time spent in forums:
Reputation Power:

Grammar for @media versus general block parsing

Bert Bos wrote:

>Revised proposal:
>State in 7.2.1 that "At-rules inside @media are invalid in
>CSS2.1. Invalid at-rules inside @media blocks must be ignored
>per 4.2 Rules for handling parsing errors."

The "must ignore" part makes CSS3 UAs non-conformant with CSS 2.1. If
all UAs implement Paged Media tomorrow (as we want them to do) then
we can never make a Rec for CSS 2.1 anymore, because there will be no
UA that ignores @page inside @media, as required by this proposal.

Actually, that's not the case. The "must ignore" part requires ignoring
invalid at-rules inside @media blocks. It doesn't require ignoring @page
inside @media specifically. That's indirectly required because *in CSS2.1*
such rules are invalid. If a later specification says they are valid, then
the "must ignore" sentence no longer applies.

So here is my cleaned-up version of Fantasai's proposal. Change in
7.2.1:

a set of rules (delimited by curly braces).
to
a set of statements (delimited by curly braces). CSS 2.1 UAs may
ignore at-rules inside @media blocks. Invalid at-rules must be
ignored per 4.2 Rules for handling parsing errors.

"Statements" may be hyperlinked to section 4.1.1, for extra clarity.

I like the change from "rules" to "statements". But I'm not as
happy with the "may ignore". What does it mean to not ignore? Are
@page inside @media and nested @media valid CSS2.1 then?

~fantasai

Thread Tools	Search this Thread
Email this Page	Search this Thread: Advanced Search
Display Modes	Rate This Thread
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode	Rate This Thread: