Comments on Designing for Context with CSS

by Joshua Porter

52 Reader Comments

Back to the Article
  1. this is one of those things thats so bloody obvious you feel silly for not having realized it before.  good write up!

    Copy & paste the code below to embed this comment.
  2. This sounds like a fantastic idea—something I can implement with the website of the nonprofit I work for.

    Do you know of any good resources for CSS for print?  I tried making up a print stylesheet a couple of times, but some things (pagebreaks, for example) eluded me.

    Copy & paste the code below to embed this comment.
  3. Brilliant idea!

    I suppose that you could hide an extra message in there that no-one sees unless the css is off,  so that users of non-css capable user-agents don’t ‘get confused’...

    Copy & paste the code below to embed this comment.
  4. Embedding what amounts to, say, three different documents (one skewed to a mobile phone, one to a web browser, and one to a printed page) into one document and then hiding the context-specific content when outside that context will fall down seriously when that document is viewed with a non-CSS-aware user agent: they’ll see all three “documents” merged together, with notes about being on a mobile phone and references to printed material even if in a web browser. This is no good thing!

    Copy & paste the code below to embed this comment.
  5. I can see it now… in Google. Fantastic description for the site eh?

    Copy & paste the code below to embed this comment.
  6. Many users with screen readers will have to endure all of the context-aware content. Screen readers should ignore “display: none;”, but some, including Jaws,  don’t.

    See Joe Clark’s “Facts and Opinion About Fahrner Image Replacement” (http://www.alistapart.com/articles/fir/).

    Copy & paste the code below to embed this comment.
  7. Like anything this will come down to ‘tradeoffs’ and balances => Three different documents is a bit extreme, imo; use this new ‘tool’ wisely, like any other.

    For non-css capable user-agents, and the Jaws situation mentioned, why not just provide short messages and skip links for problematic situations?

    Copy & paste the code below to embed this comment.
  8. That is absolutely right: people designing for non-CSS aware user agents should think twice before using this idea (or anything else that is dependent upon CSS, for that matter).

    Thanks for making that clear.

    I view that comment as part of a larger, more important point that has been discussed at length by Joe Clark and others: Accessibility is a spectrum, not a point to reach. A tradeoff must be made at some level. Define the level. Design accordingly.

    Copy & paste the code below to embed this comment.
  9. Can similar techniques be used to create pdfs for download?

    Copy & paste the code below to embed this comment.
  10. ... for future reference, and also to see if there would be any hidden text included in the printout. Obviously, I was slightly disappointed to find that there was none.

    Copy & paste the code below to embed this comment.
  11. Good article Joshua.

    I’m doing something similar at work for tutorials/usage guides.  We know some people will print out the pages rather than hit our Intranet. So, I essentially used this same technique to embed the screenshots in the print version (they are links in the online version).

    Since I’ve got an audience that is 100% IE6, I can do it safely AFAIK.  But, I have a bad feeling in the pit of my stomach as I do it.  It sure is useful and works in my closed environment, but I’m not sure if I know all the possible pitfalls.

    Copy & paste the code below to embed this comment.
  12. I don’t like the idea of “Embedding what amounts to, say, three different documents” either, but I do like your primary motive of providing different content to the print version.  Well a very simple idea that does not break non-CSS-aware browsers or screen readers, and one that also is a widely used convention across the web is ... Use a printer friendly link or button.  Very easy to do.  Can work on all browsers, saves bandwidth for people who don’t want to print it, etc.

    Copy & paste the code below to embed this comment.
  13. Uh, this might be heresy, but why not use a quick javascript to control what is seen depending on the media type for the stylesheet?

    Have the script pull in a print related include if the media type is “print”.  Or don’t load any includes if the browser is *ahem* antiquated.

    I don’t suppose it would do much good when using a screen reader, or Lynx et al, but I do see some possibility for increased control. 

    I suppose this gets away from keeping everything in the context of the page, but you ‘re just not going to be able to satisfy everyone all the time.  *sigh*

    Copy & paste the code below to embed this comment.
  14. Great article on how to take CSS one step further.  Just think what can be done when mobile devices support the media property “handheld”. I think the media print property is just the start on server up different styles for different mediums.

    Copy & paste the code below to embed this comment.
  15. Though the idea has merit, the implementation could lead a non-CSS visitor to think the author of a page using this method were not paying attention to what they were presenting. Not to mention, it could lead to confusion in elderly folks ;)

    I wonder if a solution for CSS2-capable user agents would be using the :before and :after pseudoclasses along with contextual selectors (in some fashion) to add such content in dynamically in a context-sensitive stylesheet :)

    This sort of trick would reach a fairly large audience, no? It would gracefully degrade by being left out altogether by non-CSS-capable and ye olde CSS1-only user agents.

    <sig>
    Jest My Two Cents or: How I Learned To Stop Worrying and Love the Bomb
    </sig>

    Copy & paste the code below to embed this comment.
  16. some nice idea and good usability possibility.

    Copy & paste the code below to embed this comment.
  17. Great article pointing out some obvious info. 

    An alternative (if you’d rather not add print-only tags to your html) would be to add something like this to your print stylesheet:

    h1:before {
    display: block;
    font-size: 10pt;
    content: "You are viewing a printed version of an article that came from…";
    }

    Of course the downfall to this method, as usual, is that Internet Explorer will not render this at all, as it doesn’t yet recognize the :before pseudo-class.

    Copy & paste the code below to embed this comment.
  18. Shouldn’t that be
    div#offer4print { display: none; }
    and not
    div.offer4print { display: none; } ?

    Copy & paste the code below to embed this comment.
  19. Although exploiting css for purposes of marketing makes me feel dirty.  =)

    Anyone got a link to somewhere with up to date info as to what browsers and handheld devices support which various media types?  I don’t own any handheld devices that are web capable, but I assume web phones don’t run IE 6.  How do these (presumed) alternate browsers complicate things?

    Copy & paste the code below to embed this comment.
  20. I would have to agree to sticking with just two style sheets. The more style sheets we add to any large scale site will just create more work, which in turn is more dollars spent (this is what we are trying to avoid with standards).  Creating one main style sheet and a second (perhaps without any positioning) for multiple media types is the way I go.  I am exited about the handheld media type!

    Copy & paste the code below to embed this comment.
  21. Does anyone know what mobile browsers support the handheld media type?

    Copy & paste the code below to embed this comment.
  22. Recent versions of Opera support Handheld
    http://www.opera.com/nokia/changelogs/610/

    Copy & paste the code below to embed this comment.
  23. I’m so tired of the same old people posting the same stuff after every single article on every single site and blog whenever there’s a tip or tutorial.

    “Well hey, what if they are a paraplegic with javascript turned off and a screen reader and missing one eye and both arms and color blind with no access to a mouse and only half a computer screen on really really low voltage in a really bad part of town and their default text is set ot extra large because we just don’t know what thier screen resolutio is”..

    My God. If hellen Keller were alive tody she’d have never gotten off the internet.

    Copy & paste the code below to embed this comment.
  24. Any web developer says anything written by Eric Myer is “influential”. Just an observation.
    Anyway why waste time on obscure UAs? Go to the CSS Zen Garden to see what I mean.

    Copy & paste the code below to embed this comment.
  25. in your, for example, print CCS, hide things like menu bars which aren’t very helpful in a printed copy that just add clutter. It’s the same as hiding something your browser CCS and putting a style in the print CSS, but in reverse. Good stuff.

    Perhaps another idea would be to replace submit forms for newsletters, etc with text on where and how to subscribe.

    All and all a very nice, consice and easily digestable article.

    *****

     

    Copy & paste the code below to embed this comment.
  26. Recently I have opportunity to test some pages with Nokia 6220. Well, I was surprised—it did supported CSS styling, not at best though (had problems with CSS bakcgrounds, link colours, but positioning of elements was pretty OK). So some of my created websites were not readable. Zeldman’s site was not very readable too, because on mobile screen text was cut. What was bad that Nokia didn’t recognize media=“handheld”. It just took the first CSS file found in head section—whether it is media=“handheld” or media=“screen”.

    The quick solution is to created separate CSS file with media=“handheld” and place it above all other CSS files.

    Copy & paste the code below to embed this comment.
  27. In response to comments before on using ::before and ::after, those are _pseudo-elements_. In CSS3 those are distinquised from pseudo-elements using the ‘::’ syntax (which is already supported by Opera and Mozilla).

    This is a quite important difference imo.

    Copy & paste the code below to embed this comment.
  28. In principle, shouldn’t we be using an ‘all’ media type first, followed by more specifc media types? Styles that apply across the board are only then entered once. (also using ‘all’ didn’t fail in the pre-fix Validator)

    zeldman.com currently uses ‘all’ yet ala uses screen and projection (and 2? print entries). Why the difference in approach? I’m probably missing something obvious.

    (I understand that in the Nokia 6220 case using ‘handheld’ first is required as a ‘fix’)

    Copy & paste the code below to embed this comment.
  29. First of all, I only tested sites with Nokia 6220. Wouldn’t it be nice to do an extensive study about how web sites render on Mobile devices and write an article for ALA? :)

    Nokia understood media=“all” on Zeldman’s site and tried to render page as we see it on our browsers. Now just narrow browser window and you’ll see that text gets cut there.

    So if there more mobile phones that render page like this Nokia model, one CSS file for all is not enough, unless page has 100% liquid layout without absolute positioning and fixed sizes. (Sometimes text doesn’t get cut, but appears horizontal scroll.)

    Nokia in this case grabed CSS file with whatever media “Handheld”, “screen” or “all” if file was ahead of other CSS files. And it also understood CSS through @import.

    So my thought was to put CSS “handheld” above all. Computer browsers don’t touch it—understand that it is not for them :). Then this may be followed by CSS “screen” file.

    Copy & paste the code below to embed this comment.
  30. >>In principle, shouldn’t we be using an ‘all’ media type first, followed by more specific media types?

    No, because if you do that, the styles for more specific media types will try to include and parse the rules from the screen style sheet.

    Media=“all” is the right media type to use when you *haven’t* created specific styles for secondary media. For instance, if you *haven’t* created a print style sheet or a projection style sheet (for Opera’s kiosk mode), and if you want printers and kiosk mode to see the same visual presentation a web browser sees, you’d use media=“all”.

    If you’ve created a print style sheet that *differs* from your main style sheet, it would be wrong to use media=“all” for the main style sheet, because doing so would force the print style sheet to also include all the CSS rules shown in the main style sheet.

    It is easy for browsers to become confused as they try to merge screen rules with print rules.

    In most cases, you don’t want them to merge those rules. You want the screen to use screen rules, and the printer to use print rules.

    ALA uses the same style sheet for screen and projection. We link to the sheet twice, using two media attributes:

    <style type=“text/css” media=“screen”>
    @import “/c/ala.css”;</style>

    <style type=“text/css” media=“projection”>
    @import “/c/ala.css”;</style>

    ALA’s print style sheet turns off needless sidebars and other paraphenalia:

    <link rel=“stylesheet” type=“text/css”
    media=“print” href=”/c/print.css” />

    If we used media=“all” as the media attribute for the default imported style sheet (ala.css), the print style sheet would try to incorporate the screen sheet’s rules, and bedlam would ensue. We know because we tried it.  :D

    http://www.zeldman.com/ uses media=“all” because, for now, there is only one style sheet.

    Copy & paste the code below to embed this comment.
  31. Mozilla have just released a pda browser with the baby version 0.1! Don’t know how cute it is. Its available via http://www.mozillazine.org/talkback.html?article=4353 I am not staisfied by media=”” support in css, nor am I happy about embedding 3x the bytes in a page to serve all. I’m still out on whats best. Thanks for the thoughts though Joshua.

    Copy & paste the code below to embed this comment.
  32. This amounts to hidden text and search engines will simply ban you. Hiding text in hidden layers should be prevented at all costs to stop the SE cheats.

    Copy & paste the code below to embed this comment.
  33. I don’t think so. Back in the day, some companies engaged in cheesy keyword spamming practices that became known to search engines and would, I agree, cause the search engine to lower the ranking of the offending site.

    For instance, on a site about history, a company might write ...

    <font color=“FFFFFF”>history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history history </font>

    Search engines and directories got wise to this behavior and took appropriate action to penalize those who engaged in it.

    But hiding text via CSS does not automatically lead to search engine banishment, particularly when it is clearly done for a good reason.

    For instance, certain accessibility features may be wrapped in containing elements that are hidden from ordinary browser users (but revealed in non-CSS environments).

    Then too, there is the increasingly widespread practice of CSS-based image replacement, to which ALA has devoted several articles.

    Neither of these practices, to my knowledge, in any way affects page rank in search engines or directories. My knowledge is anecdotal—I haven’t asked anyone at Google about it. But I run several sites that rank very highly, yet use image replacement and “hidden” accessibility features.

    These features are not used to deceive anyone (and neither is the method discussed in the article). Rather, they are used so that one document can serve all. Either the search engines realize this, or else, even more likely, they don’t even look for it—they simply read text.

    Copy & paste the code below to embed this comment.
  34. <quote>
    In response to comments before on using ::before and ::after, those are _pseudo-elements_. In CSS3 those are distinquised from pseudo-elements using the ‘::’ syntax (which is already supported by Opera and Mozilla).
    </quote>

    They are also pseudo-supported by current UAs ;)

    No, but really, we can’t even get MSIE to digest CSS2 yet! What would be the point in alienating those few UAs that *barely* completed support for the major CSS2 features (ala Konqueror, etc.) by jumping headlong into CSS3? I mean, eventually our pages would be so far ahead of support that visitors will need a time-travel-capable browser to visit them ;)

    In a perfect world, all of the relevant UAs would get their bleeding-edge support at the same time. But for now, we need to support ‘extra features’ for the range of good-guy CSS2 browsers out there and degrade (usually by ommision) for most visitors using some form of MSIE.

    Cheers

    Copy & paste the code below to embed this comment.
  35. >>No, because if you do that, the styles for more specific media types will try to include and parse the rules from the screen style sheet.

    It depends on what you put in your ‘all’ file.  If it only includes rules that apply to all media types then that is fine. All screen rules then follow in the ‘screen’ file.

    For example you may wish to sytle all Hn to be uppercase in all media (where feasible). By including this once in the first CSS linked ‘all’ file ensures it doesn’t have to be repeated in any subsequent files such as screen and print.

    Copy & paste the code below to embed this comment.
  36. You’re right, Ted! For instance, if your initial screen file mainly describes font families, colors, and overall margins, that data could work for “all” media in some cases. Like you said, it depends.

    Copy & paste the code below to embed this comment.
  37. I’m not trolling, but Anne please stop talking about CSS. Looking at the JIR article comments it seems you do not take browser incompatibilities into account. Either stop complaining about MSIE’s bugs are do something about them.

    Copy & paste the code below to embed this comment.
  38. I seem to have discovered what may be the biggest CSS hack ever.
    <style media=“print”>
    * {
    display: none;
    }
    </style>
    This is a crude way to protect your pages from being printed. I don’t know why anyone would want to do this, but it is possible.

    Copy & paste the code below to embed this comment.
  39. div#offer4print

    and not

    div.offer4print

    Copy & paste the code below to embed this comment.
  40. Good catch, James and Brandon. We missed that in editorial. Fixed now. Thanks!

    Copy & paste the code below to embed this comment.
  41. It didn’t have a myriad of flaws in actually execution.

    However the principle is sound, when media declarations are actually supported properly.

    In fact it works exactly like the older “ahem” class for telling people to get a standards complient browser that WaSP etc used to recomend.

    Depressingly a lot of new mobile phones still don’t support the handheld one or any other version. My new SonyEriccson Z600 is an example.. screen media on a 127x128 screen? mmm tasty..

    Of cource the false content problem (divs containing content that is just junk except in their designed media.. but could be seen in google.. etc) will be solved when we get proper support for before, after, and content css.

    So.. 2015 at this rate then?

    Copy & paste the code below to embed this comment.
  42. Until media types are properly supported, a more universal approach would be to use something akin to FIR for the print media type. In that you would replace a section of the site that would appear to all users on the web with an image that would appear only in the print version. This supports non-CSS users as their user experience is left relatively unchanged. Plus, image replacement is better supported than before and after pseudo-classes (eg: MSIE).

    Copy & paste the code below to embed this comment.
  43. Would there be a way to do this same sort of thing with server side scripting, rather than hiding the content with CSS? So you would only be presenting the content only when appropriate.

    Copy & paste the code below to embed this comment.
  44. I use it myself to chop navigation items and un-necessary fluff from some of my work.

    In creating materials for iTV services, mobile phones and PC based platforms I’ve come to realise that what often needs to be delivered is multiple versions of copy rather than just multiple designs.

    However, managing this content, most definitely when you have different authors or editors for each platform, can be really awkward if you embed the copy into the same file and use design (via css/server-side detection/client-side detection) to hide or reveal sections.

    Navigation conventions can be very different too. Once again, the single-file/many-layout solution can cause many problems in managing these differences.

    Now the arguement might be that you want a single URL for a piece of content that appears on different devices. Also, client detection via header info is often (though not always) unreliable.

    This makes no sense however, if users never see an address bar (e.g. UK cable TV services, most UK mobile phones) or if nearly all of the traffic on a device is coming through a gateway service that guarantees handing you a particular referer or ID.

    I’ve even done similar work on different mobile phones (colour/non-colour/lists as drop-downs/lists as bullet-point lists) and it seemed, at the time, to make sense to embed the content and markup all in a single delivery. Didn’t work that way in practice as even business relationships interfered, not just technology and management issues. Don’t particularly want to go into detail on this.

    Er, guess my point is, it’s a nice trick and works well for PC screen/print differences. However, it is limited in value for other devices, most definitely hand-held and TV screen devices.

    Copy & paste the code below to embed this comment.
  45. ... Then this is another technique that you might like to use.

    But first of all, why would someone be apposed to hiding divs? Well, because if someone comes along with a non-css browser, they will get all the content, for all the different media types. And let’s face it, no matter how good an explanation you put at the beginning of the page about then not using a CSS supporting browser; it would be better if they didn’t see it at all!

    Now this idea I have had, and use, is limited to short messages, and not big bulks of text. Why because it uses images.

    What I suggest is that if you want to change the content of the page for print, you can have an empty div, and then give it a background image with your message in it on the media=“print” style sheet. Other browsers will not know the difference, and the paper it gets printed onto won’t know the difference either!

    For an example of this, check out the print style sheet of my site http://www.wubbleyew.com, and notice how the logo of the site changes.

    The only failing of this work around that I can see at the moment, is that if the user specifies to NOT print background images or colours, they wont get the extra content.

    Regards to all, Keep up the good work ALA!
    Phil Baines.

    Copy & paste the code below to embed this comment.
  46. ——————————————-

    Quote:
    “Would there be a way to do this same sort of thing with server side scripting, rather than hiding the content with CSS? So you would only be presenting the content only when appropriate.”

    ——————————————-

    Yes, there is a way!

    You could use this with ASP to refer back to your own page, with a query string telling it to print an extra piece of content.

    <link rel=“alternate” media=“print” href=”<%=request.ServerVariables(“SCRIPT_NAME”) & “?version=print”%>”>

    But then, you would have to have something on every page of your site to handle the argument version=print, or it will just look exactly the same.

    Phil Baines

    Copy & paste the code below to embed this comment.
  47. Real Tests:
    As mentioned by someone above, we need REAL tests on what alternate UA’s look like, what is their hardware capable of and what CSS / JavaScript does the UA support???

    This is vital information akin to the discovery that display:none; is ignord by Jaws. Of course I would assume that Jaws will not read content makred with speak:none; but that’s only a guess!

    Fixing IE:
    IE parses javascript expressions in CSS by using the [removed]) property. This can be used to emulate ::bofore and ::after dynamic content. I have already used this to add position:fixed; and background-attachement:fixed; in Internet Explorer using only CSS.
    See the example: http://dev.jdenny.co.uk/css/ie_fixed.html
    and give me feed back on here or at: http://www.internet-marketing-research.net/forums/ftopic4755.html

    Combine this with ‘behaviors’ (in the pipe-line for CSS but already supported by IE) you can add behaviors to fix IE’s shortcommings, such as :hover on all elements, using a behavior: url(file.htc). And to ensure future browsers that add support for behaviors, but don’t need the fixes for IE, you can use - [removed]‘url(file.htc)’) ... You could even put browser-sniffing / object detection in the expression on the off chance that future non-IE browsers start supporting the [removed]) feature!

    Copy & paste the code below to embed this comment.
  48. Sorry I forgot to mention my fixes for IE does involve a seperate [removed] but that can be taken out by putting the required script functions into the [removed]) properties, or by using behaviors, or in the future using CSS @script rule, or by adding an [removed]) that dynamically loads a new .js file with the functions in there.

    Copy & paste the code below to embed this comment.
  49. I have a limited and captive audience, all IE5.5, and a situation where help for a browser-based app is delivered on HTML pages. Because of Canadian requirements, we have to deliver the help in French and English. Heretofore I’ve made two projects, one for each language, and tried to keep them in sync, not very successfully.

    But we know that to log into the application, users’ language preference is detected from their corporate login ID, and they then see the corresponding version of the app (screens in French or English) and help (pages in French or English).

    This much seems doable with CSS, but there are little things like browser title bar text; can that be styled too?

    Copy & paste the code below to embed this comment.
  50. You can do this:
    body {
    background-image: url("[removed]script here");
    }

    Copy & paste the code below to embed this comment.
  51. “there are little things like browser title bar text; can that be styled too?”
    - Philip Jones

    The browser title is tag content, so until most browsers support the CSS3 content selector.. no, not really.

    TECHNICALLY of cource it is possible, but then we hit browser limitations, as ever.

    If you have the time you *could* put the CSS in there - forward compatibility if you like. It won’t do any harm, and means no more edits when its actually supported.

    Depends on how inportant it is to you I guess.

    Copy & paste the code below to embed this comment.
  52. I think in principle this is a good idea for providing context dependent messages. However how would this strategy fair with search engines . Won’t they see the text? It wouldn’t be very helpful if the search engine picked up the text only for a user to visit the page and see that seemingly it wasn’t there. It sparks visons of text the same colour as the page background. Please correct me if I’m wrong, it’s just a concern I had.

    Copy & paste the code below to embed this comment.
  53. Sorry, commenting is closed on this article.