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]

Re: Caring for yet-to-come media types

Wolfgang Meier <womei@sofort-mail.de> wrote:[color=blue]
> 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">[/color]

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, mcgrew@stanford alumni.org, http://www.rahul.net/mcgrew/
Web Design Group, darin@htmlhelp. com, http://www.HTMLHelp.com/

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

[Tim]

Re: Caring for yet-to-come media types

On 27 Jun 2005 12:47:03 -0700,
"Wolfgang Meier" <womei@sofort-mail.de> posted:
[color=blue]
> 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">[/color]

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]

Re: Caring for yet-to-come media types

Tim wrote:[color=blue]
> You can do the same sort of thing in the stylesheet too. [...]
> In the CSS use @media to separate the different sections.[/color]

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]

Re: Caring for yet-to-come media types

On 28 Jun 2005 01:53:54 -0700,
"Wolfgang Meier" <womei@sofort-mail.de> posted:
[color=blue]
> 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.[/color]

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]

Re: Caring for yet-to-come media types

Tim wrote:[color=blue]
> 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.[/color]

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]

Re: Caring for yet-to-come media types

Wolfgang Meier:[color=blue]
> 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:[/color]

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.
[color=blue]
> em {
> font-style: normal;
> font-weight: bold;
> }[/color]

You probably rather want to use 'inherit' and 'bolder', although they
yield the same result in most (not all) situations.
[color=blue]
> I'd consider it a great improvement if blocks of
> properties would only applied if _all_ properties were supported.[/color]

If this was a general rule, I would consider it a great disimprovement, ...
[color=blue]
> This might lead to longer styles like this:[/color]

.... exactly for this reason.

[Tim]

Re: Caring for yet-to-come media types

On Tue, 28 Jun 2005 16:58:46 +0200,
Christoph Päper <christoph.paep er@nurfuerspam. de> posted:
[color=blue]
> '!required' keyword[/color]

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]

Re: Caring for yet-to-come media types

Tim:[color=blue]
> Christoph Päper <christoph.paep er@nurfuerspam. de> posted:
>[color=green]
>> '!required' keyword[/color]
>
> I always thought that was a badly named keyword.[/color]

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.
[color=blue]
> In other programming circles, an exclamation mark in front of
> something means "not" (i.e. it looks like "not required").[/color]

CSS is not a programming language, though. Nobody assumes '>' in
selectors meant "greater than", or '+' "plus".
[color=blue]
> On the other hand, if they'd written it as "required!"
> it'd be normal English, and make complete sense.[/color]

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]

Re: Caring for yet-to-come media types

(Christoph Päper in comp.infosystem s.www.authoring.stylesheets)
[color=blue]
>Tim:[/color]
[color=blue][color=green]
>> In other programming circles, an exclamation mark in front of
>> something means "not" (i.e. it looks like "not required").[/color]
>
>CSS is not a programming language, though. Nobody assumes '>' in
>selectors meant "greater than", or '+' "plus".[/color]

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


Had to beat that horse...

[Tim]

Re: Caring for yet-to-come media types

Christoph Päper:
[color=blue][color=green][color=darkred]
>>> '!required' keyword[/color][/color][/color]

Tim:
[color=blue][color=green]
>> I always thought that was a badly named keyword.[/color][/color]

Christoph Päper
[color=blue]
> 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.[/color]

What doesn't exist? "!important " does exist in CSS.
[color=blue][color=green]
>> In other programming circles, an exclamation mark in front of something
>> means "not" (i.e. it looks like "not required").[/color][/color]
[color=blue]
> CSS is not a programming language, though. Nobody assumes '>' in selectors
> meant "greater than", or '+' "plus".[/color]

I did say in *other* programming *circles*. It really doesn't make for
coherent authoring in computers when one language works one way, and
another in the complete opposite.

And while poor ASCII re-use of > as some indication of "this follows that"
is different than use of it as the greater-than sign, but fairly easily
understood in other contects, the plus symbol is another of those
maltreated symbols with multiple conflicting uses.

e.g. 12 + 15 = 27 (twelve plus/and fourteen equals twenty-seven)
IF A + B ... (a function dependent on A OR B)
div + table {} (a rule for a div AND a table)

Sheesh! I wish computer language designers had put just a bit more
thought into what they did...

--
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]

Re: Caring for yet-to-come media types

Tim:[color=blue]
> Christoph Päper:[color=green]
>> Tim:[color=darkred]
>>> Christoph Päper[/color][/color]
>[color=green][color=darkred]
>>>> '!required' keyword
>>>
>>> I always thought that was a badly named keyword.[/color]
>>
>> It doesn't exist yet, (...), but follows the style of '!important',[/color]
>
> What doesn't exist? "!important " does exist in CSS.[/color]

I wrote about a proposed keyword '!required' and you said you thought of
it as badly named. Your remark can equally applied to '!important',
which does exist, though, but I brought it up only after your reply.
[color=blue][color=green][color=darkred]
>>> In other programming circles, an exclamation mark in front of something
>>> means "not" (i.e. it looks like "not required").[/color]
>>
>> CSS is not a programming language, though. Nobody assumes '>' in selectors
>> meant "greater than", or '+' "plus".[/color]
>
> I did say in *other* programming *circles*.[/color]

And I did say that CSS was not a programming language, therefore does
not belong to a certain "programmin g circle" and thus your "other" makes
no sense. Nevermind.
[color=blue]
> It really doesn't make for coherent authoring in computers when one
> language works one way, and another in the complete opposite.[/color]

Speech has worked like that forever (or since the tower of Babylon, if
you believe in that stuff). Diversity is often good, it gives you
choices for nothing fits all. I hope you do not want CSS to be written

BEGIN RULESET
DIM color ...
END RULESET

to look more like BASIC?

CSS does not have negation yet (not even "[foo!=bar]") and neither
comparison and addition, so '!', '>' and '+' are unambiguous in it. OTOH
I must admit that '!' in selectors would have looked neater than the
proposed (and likely to come) pseudo-class ':not()'.---Wait! I forgot,
there is comparison including NOT in CSS3 MQ, which is done with plain
English words for better embeddability in XML and certain (wannabe)
applications of SGML.

<http://www.w3.org/TR/css3-selectors/>
<http://www.w3.org/TR/css3-mediaqueries/>
[color=blue]
> div + table {} (a rule for a div AND a table)[/color]

It is, in CSS, a ruleset for a 'table' that immediately follows a 'div'.
The grouping (OR) mark in CSS selectors is the comma, AND is done by
concatenation, as in "foo.bar#ba z[quuz]" (no element instance can be of
two element types).
[color=blue]
> Sheesh! I wish computer language designers had put just a bit more
> thought into what they did...[/color]

APL inventors did. ;)

I guess by now everyone has already read the "true story" about the
invention of C and UNIX.