Re: Alternate style sheets in CSS3.

Tantek Çelik writes:
> 
> William,
> 
> Very interesting.  You essentially came up with the same syntax for
> @alternate that I did, although I only posted my proposal to CSS & HTML
> WG-only lists:
> 
>  http://lists.w3.org/Archives/Member/w3c-css-wg/2003AprJun/0308.html
> 
>  http://lists.w3.org/Archives/Member/w3c-html-wg/2003AprJun/0453.html

There has indeed been little discussion on this list, but I know that
many people like the functionality. The exact syntax is undecided,
though.

As Bill said, if you have many documents that share a style, they
probably share the alternative styles as well, and so it would be
handy to have a single link in each document to the whole collection
of styles. Then you can add more alternatives site-wide, without
editing any documents.

Aside:

In fact, it would be even better if the documents contained no link at
all, but the link was added as an HTTP header by the server. Then you
can truly change styles centrally, without touching any of the
documents.

This would be ideal for cases where you can't have a style link in the
XML or HTML, because it is used in different contexts. The server can
add a link or not, based on the kind of request. I use that on my own
site, where I have RDF sometimes served as XMP inside JPEG files and
sometimes on its own. The RDF is the same, the server only adds a
style link if the request is for RDF or XML, not if the request is for
JPEG. Unfortunately, no browser supports it :-(

HTTP allows such a link header, but it took so long to convince
browser makers that this was useful, that by the time they started
considering it, the HTTP WG had already removed the recommendation for
it from the HTTP spec, for lack of sufficient implementations...

(End of aside)

There are many ways of introducing the notion of a collection of
alternatives, each with its advantages and disadvantages. Here are
some:

1) Use a hub document. The idea is that the link points to a document
that contains no styles, but only links to styles, grouped by title.

1a) Such a document could be of a new type, in a new XML-based format
or not, with its own MIME type.

1b) Or is could simply be an HTML document with lots of LINK elements,
that is interpreted as a hub document rather than displayed normally,
because the link to it was typed (REL=stylesheet or some other
keyword).

The latter is a form of "delegation": once you have an HTML document
with all the styles and alternatives you want, all other documents,
HTML and XML, can simply point to this prototype document, and inherit
all its styles. But it requires the UA to parse HTML, which an
XML-only UA may not want to do.

2) A hub document may well be the most efficient and easiest to
maintain in some cases (large collections of styles, low bandwidth,
low latency), but in others it may be easier to put all alternatives
in one file, hence to extend CSS itself.

That has the advantage, assuming we do it well, that the choice
(single large file vs indirection to many small files) is left to the
author: he can still use @import to split his file if it gets too
large.


There is some elegance to the idea of a hub document. E.g., it would
work for other things than CSS as well. You can build a generic
"alternatives processor," that parses the hub document and puts up a
menu. It need not know CSS. The alternatives could be alternative HTML
files, alternative scripts, alternative software licences, or
anything.

On the other hand, it seems convenient to not have to learn a new
format, not to need an extra file and not to have to care about more
links that can break.

So let's assume for a moment we do this inside CSS.

The @alternate keyword is the obvious first idea, but I have some
reservations about it:

  - It introduces an extra level of nesting. No problem for
    programmers, used to 3rd generation programming languages, but I
    think one of the good things of CSS is that it is a flat list of
    rules, understandable to many more people. The order matters a
    little, but often you don't even have to care about that. It
    limits advanced users a bit (maybe), but makes a lot of things
    easier: GUI-based editors, simple Perl scripts, search and
    replace...

  - There is already @media. Defining how @alternate and @media
    interact is going to be complex. It will lead to bugs and
    confusing results. There is also @import: would we allow @import
    inside @alternate? Keeping track of which rules apply would be a
    nightmare if @import is no longer restricted to the start of the
    file.

So I've been thinking about two alternative :-) solutions:

2a) Just don't put the alternatives in the same file. Allow a style
sheet only to _link_ to the preferred and alternative styles, using an
extension to the @import rule:

    @import url(blues.css) "Memphis blue";
    @import url(classic.css) "Classic book style";
    @import url(bl-pr.css) print "Memphis blue";
    @import url(proj.css) projection "Standard slides";
    @import "blues1.css" "Memphis blue"; /* alt. syntax */

    /* Persistent styles here */
    ...

Maybe the syntax is clearer with some punctuation (delimiters) before
the title. E.g.

    @import url(blues.css) -> "Memphis blue";

or a keyword:

    @import url(blues.css) as "Memphis blue";

There is no explicit mark that distinguishes the preferred style from
the alternatives. The preferred one is simply the first one that is
mentioned by name. (And UAs should probably "persist" the user's
choice: when going to another document or returning to this one, keep
on using the style with the title that the user selected last.)

If you import an alternative style sheet from a style sheet that
itself already has a title, the import is ignored, unless the titles
are the same. Otherwise a UA would have to load all alternatives
recusively, to see if they define more alternatives; which defeats the
purpose of putting them in separate files.

2b) The above has minimal impact on the CSS syntax, but doesn't allow
all alternatives in a single file. So I've been thinking that, since
@media already exists and provides a nesting level, maybe @media can
serve to define alternatives as well.

In a way, it already does. Switching media is very close to switching
style sheets. Most of the effect you see when you switch to another
mode (print preview, slide projection, tty view, handheld PDA
emulation) is achieved by swapping style sheets.

So why not add a title to @media as well?

    @media all "Memphis blue"
    {
        ...
    }
    @media all "Classic book style"
    {
        ...
    }
    @media print "Memphis blue"
    {
        ...
    }
    @media projection "Standard slides"
    {
        ...
    }
    @media all "Memphis blue"
    {
        ...
    }

    /* Persistent styles here */
    ...

Like for @import above, it may be useful to add a delimiter or keyword
before the title, depending on whether we expect to add anything else
later or what we think is the most readable and easiest to remember:

    @media all -> "Memphis blue"

or:

    @media all as "Memphis blue";

The combination of 2a and 2b seems to provide all we need, with
minimal impact on the syntax and the readability of style sheets.


We already have Media Queries, that extend @import and @media with
extra conditions:

    @media print and (color)
    @media screen and (max-width: 400px)

The title can be seen as simply another such conditon, not on the
media, but on the user's choice:

    @media print and (color) as "Yellow and red"
    @media screen and (max-width: 400px) as "No columns"

In fact, the title could be cast as a Media Query itself:

    @media print and (color) and (title: "Yellow and red")
    @media screen and (max-width: 400px) and (title: "No columns")

but that somehow seems a bit geeky...



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Sunday, 22 February 2004 10:42:35 UTC