How to proportionally scale images that have dimension attributes

Allowing images to scale along with their container is an important part of responsive web design (and was so even before the term “responsive web design” existed). It’s really quite easy – all you need to do is give the image a width (or max-width) in percent: img { max-width:100%; } This will prevent any img element from getting wider than its container. If the container is narrower than the image, the image will scale down. But there is a catch.Read full postPosted in CSS.Copyright © Roger Johansson

Posted by on 13 June 2013 | 2:09 pm

Firefox and the magical text-overflow:ellipsis z-index

A while ago I received a strange bug report for a site I’d been working on. The report mentioned dots appearing on top of a dropdown menu when it was expanded. I had a look in Safari, could not see any dots, but then tried Firefox. And sure enough, there were sets of three dots in the dropdown menu. It didn’t take long to find the cause, fortunately. Just below the dropdown menu was a list of news items whose text-overflow value was set to ellipsis. The dots in the dropdown menu were the ellipsis characters peeking through, or being rendered on top of, the dropdown’s background. After checking in a lot of different browsers I can only replicate this in Firefox. Apparently the ellipsis rendered by text-overflow gets a z-index that is higher than the element it is applied to. It also appears above any absolutely or relatively positioned elements that come before the element with text-overflow in the source order, unless those elements have a z-index value greater than 0. Read full postPosted in Browsers, CSS.Copyright © Roger Johansson

Posted by on 31 May 2013 | 1:09 pm

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.Read full postPosted in CSS.Copyright © Roger Johansson

Posted by on 14 May 2013 | 2:07 pm

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.Read full postPosted in Accessibility, Browsers, CSS.Copyright © Roger Johansson

Posted by on 30 April 2013 | 12:36 pm

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.Read full postPosted in Browsers, CSS.Copyright © Roger Johansson

Posted by on 11 April 2013 | 2:22 pm

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.Read full postPosted in CSS.Copyright © Roger Johansson

Posted by on 4 April 2013 | 2:15 pm

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.Read full postPosted in CSS.Copyright © Roger Johansson

Posted by on 25 March 2013 | 1:32 pm

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.Read full postPosted in CSS.Copyright © Roger Johansson

Posted by on 4 March 2013 | 1:07 pm

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.Read full postPosted in CSS.Copyright © Roger Johansson

Posted by on 23 February 2013 | 9:16 am

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. Read full postPosted in Accessibility, JavaScript.Copyright © Roger Johansson

Posted by on 12 February 2013 | 11:37 am

Acai Berry Select

Harvested by Brazilians for hundreds of years as a food staple and for their rejuvenating and detoxifying properties, Acai berries (fruit of Amazonian Acai Palms) have been all over the media, from articles in fitness magazines to features on popular television programs like Today show. Click here for your Risk Free Trial