W3C home > Mailing lists > Public > www-style@w3.org > August 2001

Re: At-rules (@-rules) in @media blocks

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sun, 12 Aug 2001 04:49:30 +0200
To: "Tantek Celik" <tantek@cs.stanford.edu>
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <cbpbnt4t8cn2vf692qv8b7fhlcn7uk2qc3@4ax.com>
* Tantek Celik wrote:
>Not quite.  It is much more difficult to give those arbitrary brace depths
>some meaning (e.g. nested @media blocks), than to keep track of a depth
>counter and just throw stuff away while parsing.

I think we don't argue, that nested at-rules won't be a problem for the
parser, it's just syntactic sugar and handled already fine by conforming
parsers due to forward-compatibility parsing rules, it's merly what is
attached to it to sort out, store, apply and whatever else the
information got from the parser.

I can hardly think of some design that would cause problems. For example
take the implicite nested @media rules, e.g.

  <link media='tty, tv, screen, print' href='1' ... />
  /* 1 */
  @import url(2) tv, screen;
  @media tty, tv { /* ... */ }
  /* 2 */
  @media tv { /* ... */ }
  @media screen { /* ... */ }

This tends to be the same as

  @media tty, tv, screen, print
    @media tv, screen
      @media tv { }
      @media screen { }
    @media tty, tv { }

If you are able to handle the complex link/import relationships, you
should be also able to handle the nesting directly in a stylesheet. A
possible implementation could be some hash structure as

  %media = ( tv => { }, tty => { }, screen => { } ... )

but your applications needs proper design, of course. I may however miss

>All this being said, I can see some utility for having @page inside @media,
>or even @media inside @media, but I'm not sure how often I'd use it.  If you
>really think it would be that useful, I invite you to make a proposal for

Media is currently the only at-rule where nesting would make sense;
@font-face could gain some inheritance features but that is unlikely to
be used. Nesting @media is harmful; I have still some problems to
understand how this should work correctly, but in general you have twice
a chance to define media, external linking information and @media rules.
You cannot override external linking information from within the style
sheet and what stays is the same situation as with W3C selectors, e.g.

  h1, h2 { color: blue       }
  h1     { font-size: 2.33em }
  h2     { font-size: 1.66em }

If you have styles that apply to several media

  @media screen, print { /* ... */ }

and then use separate media declarations for special styles as

  @media screen { }
  @media print { }

this works quite well, I don't see what you gain by nesting @media rules
within each other, but if that was possible, i'd request

  h1, h2 { h1 { } h2 { } color: blue }


So we stay at @page. I come to the conclusion, that @page is broken as
designed, it's actually a selector for some abstract box so it should
be a selector, but I don't think I have a big chance to get @page
deprecated and a new selector added to the W3C selectors. There are ways
to achieve whatever you want to do with @page, we don't need nesting.

What could be done is to restrict CSS Level 3 Syntax to forbid nested
at-rules, that would actually ease implementations.
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/
Received on Saturday, 11 August 2001 22:50:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:58 UTC