Caring for yet-to-come media types

[Wolfgang Meier]

Hi,

I really hope I'm not hitting a frequently asked question here, because
I think almost every author must have made that decision. Anyway, here
goes:

Would it be better to write one global stylesheet, then write
specializations for media that need special treatment:

<link ... media="all">
<link ... media="print">
<link ... media="aural">

This might guarantee that a page looks "good" on all media the author
provided stylesheets for, but it might mess up the page on other media
types, possibly introduced at some later date.
Or would it be better to write no global stylesheet but only
stylesheets for supported media

<link ... media="screen">
<link ... media="print">
<link ... media="aural">

This seems safer by not trying to render fancy design on other media
types but these "unsupporte d" media would then render rather dull
pages.
What do you think?

Wolf

[Darin McGrew]

Wolfgang Meier <wo***@sofort-mail.de> wrote:

Would it be better to write one global stylesheet, then write
specializations for media that need special treatment:

<link ... media="all">
<link ... media="print">
<link ... media="aural">

This makes sense if you've got CSS rules that are appropriate (or likely to
be appropriate) for braille (both refreshable displays and embossed paper),
handheld devices, print, projection displays, screen displays, speech, tty,
tv displays, and any other media types that might come along. Those rules
could go in the media="all" style sheet.

Do you? If not, then stick to media-specific style sheets. Although you can
also specify multiple media (e.g., media="print,pr ojection") when
appropriate.
--
Darin McGrew, mc****@stanford alumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp. com, http://www.HTMLHelp.com/

"I used to do lots of dumb things, but I turned my life around 360 degrees!"

[Tim]

On 27 Jun 2005 12:47:03 -0700,
"Wolfgang Meier" <wo***@sofort-mail.de> posted:

Would it be better to write one global stylesheet, then write
specializations for media that need special treatment:

<link ... media="all">
<link ... media="print">
<link ... media="aural">

You can do the same sort of thing in the stylesheet too. Thus, all pages
that referred to a default stylesheet now, could later be styled to suit
specific media, without needing to edit the pages, just by editing the
default stylesheet, so long as you authored the pages in a sensible manner
in the first place.

e.g. In the pages just link to one style sheet.
In the CSS use @media to separate the different sections.

@media all {
some common rules...
}

@media screen, display {
some rules...
}

@media print {
some rules...
}

Of course this isn't brilliantly efficient cachewise (where browsers that
didn't support braille could avoid loading a braille stylesheet), but if
the CSS file is small enough that may be immaterial. And it's been my
experience that MSIE fetches all CSS files, even if it's not going to use
them (e.g. it fetches alternate stylesheets, but cannot use them).

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Wolfgang Meier]

Tim wrote:

You can do the same sort of thing in the stylesheet too. [...]
In the CSS use @media to separate the different sections.

True. I nearly forgot about this. Maybe I can even use this to "hide"
fancy CSS from NN4.

By the way: One big drawback of CSS, I think, is that most properties
only make sense if applied _together_, but there is no means to link
them. Consider this:

em {
font-style: normal;
font-weight: bold;
}

A browser that wouldn't support /font-weight/ would now render /em/s
just like normal text. I'd consider it a great improvement if blocks of
properties would only applied if _all_ properties were supported. This
might lead to longer styles like this:

em {
color: red;
}

em {
color: black;
font-style: normal;
font-weight: bold;
}

....but make sure you get either red, italic /em/s or black bold ones,
depending on your browser's capabilities.

Just a thought.

Wolf

[Tim]

On 28 Jun 2005 01:53:54 -0700,
"Wolfgang Meier" <wo***@sofort-mail.de> posted:

By the way: One big drawback of CSS, I think, is that most properties
only make sense if applied _together_, but there is no means to link
them. Consider this:

em {
font-style: normal;
font-weight: bold;
}

A browser that wouldn't support /font-weight/ would now render /em/s
just like normal text.

You end up with an awful lot of if/then/else programming if you're going to
pander to MSIE's foibles... <evil grin> It's usually *it* that needs
that sort of malarkey.

The problem with that approach, is that you're making a page that's reliant
on styles, when you shouldn't. That's the bigger mistake. Read your page
out aloud, top to bottom, left to right, just like a book. And if it
doesn't read out in a coherent fashion, the page needs redoing.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Wolfgang Meier]

Tim wrote:

The problem with that approach, is that you're making
a page that's reliant on styles, when you shouldn't. [...]
If [the page] doesn't read out in a coherent fashion, the page
needs redoing.

I fully aggree with you. The problem I wanted to point out was,
however, a different one:

In my opinion it is not always possible to write a page that looks not
only fine with and without applied CSS but also looks fine if only a
(seemingly) random subset of CSS properties is applied.

In my opinion that's a shame.

Wolf

[Christoph Päper]

Wolfgang Meier:

By the way: One big drawback of CSS, I think, is that most properties
only make sense if applied _together_, but there is no means to link
them. Consider this:
There have had been several suggestions to overcome this on css-style. I
think the best one with least drawbacks was a '!required' keyword. It
hasn't made it into any draft yet, though.
em {
font-style: normal;
font-weight: bold;
}
You probably rather want to use 'inherit' and 'bolder', although they
yield the same result in most (not all) situations.
I'd consider it a great improvement if blocks of
properties would only applied if _all_ properties were supported.
If this was a general rule, I would consider it a great disimprovement, ...
This might lead to longer styles like this:

.... exactly for this reason.

[Tim]

On Tue, 28 Jun 2005 16:58:46 +0200,
Christoph Päper <ch************ **@nurfuerspam. de> posted:

'!required' keyword

I always thought that was a badly named keyword. In other programming
circles, an exclamation mark in front of something means "not" (i.e. it
looks like "not required"). On the other hand, if they'd written it as
"required!" it'd be normal English, and make complete sense.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Christoph Päper]

Tim:

Christoph Päper <ch************ **@nurfuerspam. de> posted:

'!required' keyword
I always thought that was a badly named keyword.

It doesn't exist yet, of course, but follows the style of '!important',
which is in fact grammatically two items, '!' and 'important', which may
have whitespace between them.
In other programming circles, an exclamation mark in front of
something means "not" (i.e. it looks like "not required").
CSS is not a programming language, though. Nobody assumes '>' in
selectors meant "greater than", or '+' "plus".
On the other hand, if they'd written it as "required!"
it'd be normal English, and make complete sense.

If they hadn't had extensibility in mind, they could have used '!' only,
without 'important'. Then they maybe would have to introduce another
(ASCII) character, like '|', to do the job. Anyhow, nothing's specified
yet in this regard.

[Tilman Hesse]

(Christoph Päper in comp.infosystem s.www.authoring.stylesheets)

Tim:

In other programming circles, an exclamation mark in front of
something means "not" (i.e. it looks like "not required").

CSS is not a programming language, though. Nobody assumes '>' in
selectors meant "greater than", or '+' "plus".

What he means by programming is you describe something in computer
code. CSS certainly does that.
Had to beat that horse...