456 Berea Street
Replacing images when printing
It isn’t all that uncommon that, after you’ve polished your print stylesheet to make a site look well on paper as well as on screen, you realise that the logo really doesn’t look its best. It may look blurry or pixelated on paper due to having a pixel density intended for screen viewing, of course. But even worse, its edges may look ugly or it may actually be invisible because whatever is behind it when viewed on screen isn’t printed.
Applying a background colour to the logo image or its containing element in the print CSS isn’t going to help either since most browsers by default do not print backgrounds at all. If you can’t change the image used for screen so that it will look good in print as well, you need to somehow make browsers use a different image when printing. One way of doing that is by using CSS generated content.
Posted in CSS.
Copyright © Roger Johansson
Using a transparent image as an icon fallback
Sometimes designs contain button styling that is difficult to create with CSS alone. The “official” way of dealing with this is to either use an image button (<input type="image" src="button.png" alt="Ok" />) or put the image in a button element (<button><img src="button.png" alt="Ok" /></button>).
However if the graphic you want to show instead of the button is part of a sprite image, or if you want to display a different image when the button is hovered over or receives focus, that won’t work. In these cases it can be tempting to just use a background image and move any text the button contains out of the way by positioning it off-screen or applying a bit of text-indent. Or even worse, use no text content at all. Using no text content at all is obviously no good to anyone who can’t see the image, like screen reader users. And hiding the text causes problems if the image can’t be displayed.
Much of this is covered by Nicholas C. Zakas in Making accessible icon buttons, and I thought I’d talk a bit more about a technique he mentions that I use in these situations – the transparent one pixel image.
Posted in Accessibility, Browsers, CSS.
Copyright © Roger Johansson
Conditional sibling class names for IE patching
Traditionally, web developers have been using either CSS hacks or conditional comments to target different versions of Internet Explorer with CSS fixes. In the last few years more and more people have started using conditional class names, more or less as described by Paul Irish in Conditional Stylesheets vs CSS Hacks? Answer: Neither!.
I’ve always favoured separating IE fixes from the main CSS by putting them in one or sometimes two separate files loaded via conditional comments. However, a valid argument against that is that keeping the patches in the same file as the main CSS increases maintainability since you’re less likely to forget about the patches when updating the main CSS. That problem can be solved by using conditional comments to add class names to the html element depending on which version of IE is used.
The problem is that it can create plenty of HTML bloat since you need to repeat the opening HTML tag – including any attributes it has – for every version of IE that you want to target. So I started thinking that maybe there is a different way. And there is, though it too has its drawbacks. Nevertheless, here’s another way of solving the problem.
Copyright © Roger Johansson
Responsive drop shadows
Back in the ancient days of fixed-width web design, adding a drop shadow to an element used to be a matter of exporting an image containing the shadow from Photoshop and placing it as a background image on the element. Job done.
However, if you want some flexibility (as many of us have always wanted) it isn’t quite that easy. Sure, if you have a straight drop shadow that can be created with a CSS box-shadow declaration, it will expand and contract as necessary to fit the width of the element it is applied to. But if the design calls for a slightly more complex shadow you need to do a bit more.
I’ve had to do this a number of times and thought I’d share a couple of tricks.
Posted in CSS.
Copyright © Roger Johansson
Letting users disable responsive layout
It’s great that media queries allow us to adapt the layout of our sites to the users’ viewport size, a.k.a. Responsive Web Design. However, some argue that doing so comes with a (slight) risk of confusing some people that don’t expect viewport width to make the layout change as drastically as media queries allow.
While I don’t think this affects a large number of people, it’s quite possible that people who do not know what responsive web design is (i.e. the vast majority of people) can be confused by a site looking radically different on their computer that on their tablet or smartphone. Bruce Lawson mentions an example of this in Turning off responsive web design, and I’ve heard other similar stories.
A colleague mentioned another case when a responsive layout is not always ideal – client support. Support issues from clients often mention layout issues or change requests. If you get a support email referring to the desktop layout while away from your desktop computer you may not be able to see the same thing on your tablet or smartphone, so you’ll have to postpone responding. Sure, it’s an edge case, but one in which being able to turn off the responsive layout would be useful.
Despite having the feeling that it wouldn’t benefit a large number of people, implementing a switch to toggle a website’s responsiveness on and off isn’t really a lot of work. So in a couple of projects I have done that, and thought I’d share how. The approach is pretty similar to what Adrian Roselli describes in Letting Mobile Users See Desktop View of RWD Site. It’s not very complicated, and neither is it revolutionary, but as with most things there are different ways of getting there.
Posted in CSS.
Copyright © Roger Johansson
How to shrinkwrap and center elements horizontally
When you use CSS to float an element that does not have an explicit width, the element’s width becomes its “shrink-to-fit” width. This is useful when you’re floating elements that you don’t know how wide they need to be. A very common example is a navigation bar, where you often want the width of the links to vary depending on how much text they contain.
Not knowing an element’s width makes it harder to center it horizontally, however. Take the navbar example. What if you have a list of a few items, you want them to shrinkwrap, but you also want to shrinkwrap and center the whole navbar horizontally? Shrinkwrapping it is easy – you just need to float it. But centering is not quite that straightforward. You can try margin:0 auto;, but unless you give the navbar an explicit width it won’t do anything. And that’s the problem – you don’t know how wide the navbar is.
If you could specify float:center that would probably do the trick. Sadly you can’t do that (not yet anyway). Fortunately there are several other ways to solve this problem.
Posted in CSS.
Copyright © Roger Johansson
Fieldset, legend, border-radius and box-shadow
The fieldset and legend elements are notorious for being tricky to style, especially if you want the same result across browsers. Other than the line wrapping issue I wrote about in How to line wrap text in legend elements, even in IE, you may run into problems and differences related to padding, backgrounds and positioning of the legend element.
Recently I noticed more fieldset + legend weirdness, this time involving the border-radius and box-shadow CSS properties. If you use either property on a fieldset element that has a child legend element (which all fieldset elements should), you will get unexpected results in some browsers. Luckily I also found a fix after a bit of experimentation.
Posted in CSS.
Copyright © Roger Johansson
Making elements keyboard focusable and clickable
When you want to make an element on a web page clickable in order to trigger a JavaScript function, the best option is to use an element that has native support for keyboard interaction. In most cases a button (either <input type="button" /> or <button type="button"></button>) is the most appropriate element. It lets everybody trigger your function, whether they use a mouse or not.
Unfortunately, many (maybe even most) developers do not use the correct HTML elements for this. Instead they often use elements that have no native support for keyboard interaction, like span, div or li. A slightly better choice is the a element since it can receive keyboard focus as long as it has a non-empty href attribute (i.e. <a href="#">Click me</a>). But it isn’t really a link anymore since it acts like a button and doesn’t lead anywhere.
What do I suggest then? There are two options:
- Use real buttons and style them so they look the way you need them to look.
- If you simply cannot or will not use real buttons, make sure your fake buttons can be focused and activated without using a mouse.
Posted in Accessibility, JavaScript.
Copyright © Roger Johansson
CSS background-position and percent
I was working on making an existing client site responsive recently and encountered a CSS problem I am unable to find a good cross-browser solution to. The problem involves CSS background images and seemed simple at first, but it turned out otherwise.
The site I was working on was using a fixed width. One column had a coloured background extending all the way from the header to the footer, regardless of the amount of content. To achieve this, a background image was used (à la Faux Columns). I needed to make this flexible as part of the responsive remake.
Making the width flexible and changing the column widths from pixels to percentages has an interesting consequence when you use a background image to fake columns because of the way the background-position CSS property works when you use percent, i.e. background-position:40% 0.
Posted in CSS.
Copyright © Roger Johansson
Media Query width and vertical scrollbars
Media queries are a great tool for changing a website’s layout depending on parameters like viewport width, but it can be very annoying when browsers do not do the same thing. An obvious example is whether or not a vertical scrollbar, should one exist, is included when the viewport’s width is calculated.
I made a note about this two years ago in Media queries, viewport width, scrollbars, and WebKit browsers. In that post I also pointed to the following statement in the Media Queries specification:
The ‘width’ media feature describes the width of the targeted display area of the output device. For continuous media, this is the width of the viewport (as described by CSS2, section 9.1.1 [CSS21]) including the size of a rendered scroll bar (if any).
So it’s pretty clear what browsers are supposed to do. But in reality this varies. It doesn’t just depend on the browser and operating system but also on user settings. To find out what current browsers do, I created a simple Media Query width test document with a number of breakpoints and opened it in a lot of browsers.
I saw three different behaviours.
Copyright © Roger Johansson