Caring for yet-to-come media types
|
|
Thread rating:  |
Wolfgang Meier - 27 Jun 2005 20:47 GMT 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 "unsupported" media would then render rather dull pages.
What do you think?
Wolf
Darin McGrew - 27 Jun 2005 21:03 GMT > 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,projection") when appropriate.
 Signature Darin McGrew, mcgrew@stanfordalumni.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 - 28 Jun 2005 08:16 GMT > 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).
 Signature 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 - 28 Jun 2005 09:53 GMT > 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 - 28 Jun 2005 13:26 GMT > 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 [quoted text clipped - 7 lines] > 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.
 Signature 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 - 28 Jun 2005 13:42 GMT > 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 - 28 Jun 2005 15:58 GMT 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 - 29 Jun 2005 12:06 GMT > '!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.
 Signature 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 - 29 Jun 2005 21:20 GMT Tim:
> Christoph Päper <christoph.paeper@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 - 29 Jun 2005 23:40 GMT (Christoph Päper in comp.infosystems.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...
Tim - 30 Jun 2005 02:40 GMT Christoph Päper:
>>> '!required' keyword Tim:
>> I always thought that was a badly named keyword. Christoph Päper
> 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. What doesn't exist? "!important" does exist in CSS.
>> 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". 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...
 Signature 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 - 30 Jun 2005 06:19 GMT Tim:
> Christoph Päper: >> Tim: [quoted text clipped - 7 lines] > > What doesn't exist? "!important" does exist in CSS. 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.
>>> In other programming circles, an exclamation mark in front of something >>> means "not" (i.e. it looks like "not required"). [quoted text clipped - 3 lines] > > I did say in *other* programming *circles*. And I did say that CSS was not a programming language, therefore does not belong to a certain "programming circle" and thus your "other" makes no sense. Nevermind.
> It really doesn't make for coherent authoring in computers when one > language works one way, and another in the complete opposite. 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/>
> div + table {} (a rule for a div AND a table) 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#baz[quuz]" (no element instance can be of two element types).
> Sheesh! I wish computer language designers had put just a bit more > thought into what they did... APL inventors did. ;)
I guess by now everyone has already read the "true story" about the invention of C and UNIX.
|
|
|