Tag Archives: css

box-shadow yay

I made a very subtle change to the CSS on this site, but it’s one that’s easy for anyone to add:

#page {box-shadow:0 0 42px 3px;}

In this version, the first two arguments are the x and y offsets of the shadow; the third is the blurring radius; and the fourth is the “spread” or size.  You can also toss in inset in there, which will make the shadow an innie rather than an outie; and a color value, to make the shadow a particular color.

My favorite aspect of the box-shadow is that it’s supported by a reasonable number of current browsers, and it adds an image-like flair with a few extra characters of CSS.  Yay.

CSS for Mobile: tips and tricks

CSS is so broad a topic that it’s relatively silly to offer a single solution that works for all situations.  Even so, I’ve been working more towards creating sites that are reasonable both on the desktop and mobile browsers.

Declare your meta viewport!

Before attempting to work on CSS for mobile sites, it all will be for naught if you forget the meta viewport tag in your <head>.  At a base level, you want something like this:

<meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1, maximum-scale=3" />

The initial and maximum scales control how iOS and Android browsers zoom in and out of the page.  If you don’t want to allow any zooming, you can set user-scalable=no, though setting the initial and maximum scales to the same value can imply about the same effect if both are set to 1.  Setting the width to the device width is also important, since mobile browsers increasingly want to pretend they are full, desktop browsers capable of huge pixel widths, etc.

Media queries to the rescue

I wrote a while ago about media queries for mobile sites, and most of that hasn’t changed.

One important consideration is how large your fonts are for the mobile destinations.  With restricting zooming or the width of the page using the viewport, as detailed above, the resulting text can be quite tiny.  I know this might sound crazy to a crowd used to setting up 11px fonts, yet I would recommend setting a 100% font-size for mobile.  Alternatively, you can not set the font size anywhere outside of your desktop blocks, depending on how you set up your media queries.

Single CSS file

Here’s another suggestion that might ruffle some feathers: if you can, try to reduce your all your CSS into a single file.  Separate HTTP requests are expensive, and that’s even more true for constrained, mobile devices.  All your media queries can go in sections of that one CSS file, and, if you have your expire headers set up properly the browser can cache all that to reduce the network activity for future requests.

Take out the media attribute from your link tag, to get something more akin to this:

<link rel="stylesheet" href="/path/to/style.css" />

You can now even fit your @media print blocks in this one file, in addition to all mobile definitions.

Defining your media targets

Again, there are many ways that you can attack how you want to set up your media queries, though it’s worth noting that you can have a comma separated list to apply to a single block.

I’m currently wrapping my mobile rulesets within a block defined by @media mobile, handheld, all and (max-width:854px).  Browsers that identify themselves as being mobile, or handheld, or screen with a max-width of 854px all fall under the following definition.  Some may say it’s best to target the mobile browsers first, outside of any media queries, and then head for min-width rules instead.  There are browsers which don’t understand the media query structure, too, so it does depend on what kind of a strategy you want to employ.

At the end of the day it’s important to test out the devices which are visiting your site, or, if you don’t have them on hand, find convincing documentation to align a strategy.  Process your access logs or Google Analytics data if you aren’t sure what kind of browsers hit your site.  Failing that, it also might not hurt to send out a survey or two in order to ensure you have the most optimal experience for your users.

Beware of leftover padding!

I don’t want to get too preachy as to the details of how you implement your mobile site, though a final note for your mobile design is to beware of padding values near 100% widths.  On a small screen it is natural to want to make an element the full width of the screen, yet if you have anything in there with a right or left padding it can push the width of the object over 100%.

It’s easy enough to fix this: you can make the padding a percent value and the width correspondingly smaller (width:96%; padding:2%;).  It can also work to nest an element with a margin inside the target: this has the advantage of being able to work with pixel values more easily, which is probably more consistent and thereby desirable.

Your solutions ?

Do you have any tips or tricks for mobile CSS sites?  Please leave a comment below, I’d love to hear your thoughts!

Mobile-compatible websites with CSS media queries

CSS never ceases to amaze me.

Previously, I had a rather simple PHP script on my site which looked at the browser string from the client; if it seemed from that as though the current user was on a mobile device, I then either loaded a mobile-overrides CSS file, or modified the statements inline (in the case that my CSS was served up via PHP).

Smashing Magazine recently posted an article titled Modern CSS Layouts: The Essential Techniques which came up on Digg.  I’ve heard of a number of the other sections, though what really caught my eye was the large amount of discussion about media queries.  What particularly caught my eye was the article titled Safe media queries from dev.opera.com.

This is why, if you’re using Internet Explorer to visit this site, all my pages look a bit messed up in their current state.  I’m being liberal with the “safe” part of the article, and tending towards more what’s in the Dev.Opera tagline: “follow the standards, break the rule.”

General idea

So the idea here is that within a single CSS file, it’s possible to section out certain rules such that they apply only to certain types of devices or screens. The main players are min-width and max-width; the general syntax goes something like: @media all and (max-width:800px) {/* rules */}.

My approach

There are loads of way to attack this. One major concern is that Internet Explorer and other non-supported browsers don’t understand whatever it is you put inside these rules, as defined in the way of the previous paragraph. The Dev.Opera article breaks this down quite well.

As long as the site is readable and easily navigable, I’m not too worried about making sure the page looks exactly the same on each system and browser. Obviously, I have a much looser set of criteria than most designers out there; so if you’re more restricted you’ll have to think about your other options.

Rethinking set widths

In my case, I thought I’d rethink the structure of fixed-width elements; yes, all fixed widths. Why? In the world of mobile devices and all sorts of browsers and options, it’s going to be more and more important that your sites’s content can reflow in an accessible way regardless of the platform.

Ergo, my tack is to put any sort of important definitions pertaining to a width: definition down to the bottom of the CSS file, inside my @media all and (min-width:...) {} block. What once was:

#page {width:820px; margin:30px auto; padding:10px;}

becomes:

#page {padding:10px;}
@media all and (min-width:840px){#page {width:820px; margin:30px auto;}}

The 840px minimum width is to figure in the padding on each side; and the result is that if my browser window is more narrow than that, I don’t have any horizontal scrolling to do.

In my structure, #page contains both a main section and a sidebar. I floated the sidebar left, along with its children; and then in the media query block alone I set the width of the actual sidebar. There is a bit of a jumble of elements at the bottom now, but moving to a small screen makes it worth it.

My pattern, then, is to let the browser expand all the elements as it needs, and to only set the large-screen elements for the browsers that can handle it.

Choice philosophies

With the above plan, Internet Explorer and the other non-supported browsers are going to see my site in some sort of goofy layout that’s meant for phones and pocket devices. I’m OK with that, because I can still get at the content in a nice enough way. I feel that the standards have to logical, but they also have to be pushed forward by aggressive use and stricter implementations, and browsers which accept these standards are the only way towards true progress.

The bigger picture, beyond my half-assed vendetta, is that CSS is alive and well; and I’m more than happy to be ditching the practice of checking browser strings in order to get my site readable on all platforms. I also would urge anyone who takes a quick look at my site and gives the concept a pass: that there’s more than my solution out there; and if you have something even better than what I’ve dreamed, please have at it and leave a note for me in the comments :)

Experimenting with CSS: @font-face

I’ve been playing with some design tweaks to this blog, as I’m prone to do, though in this revision I managed to enter into some advancements with newer browsers: namely, font embedding via the CSS @font-face directive.

Why this matters

The idea is that browsers now support the ability to download and incorporate fonts not on the host system.  This is a big leap forward, because there is a very limited set of fonts which you can use for the web.  Mac fonts aren’t all in Windows or in Linux installations, ditto for Linux into Windows, etc.

You can use CSS to have a list of fall-back font families, though all this does is allow for the particular system to use a different font which is “good enough.”  Namely, you can have:

body {font-family:"Helvetica","Arial", sans-serif;}

which reads that the body tag should first utilize the Helvetica font; if Helvetica is not available, then use Arial; if Arial is not available, then use any sans-serif font on the system.

With embedded fonts, I can keep this same syntax yet with an additional font which isn’t necessarily on the visiting computer:

* {font-family:'Fontin', 'Helvetica', sans-serif;}

This says that for all elements, use the “Fontin” font first, then fall back in the same way as in the other example.  Fontin is a free font which is publicly available and is released under terms which allow for embedding into a page.  You can download Fontin at the exljbris Font Foundry website, and view a list of other fonts also available for this purpose at the webfonts.info wiki.

Making the font files findable: @font-face

So, if you have tried the above without more work, you’ll quickly see that nothing new is happening.  The trick, then, is that the browser needs to know a bit more about this “Fontin” typeface which is not on the computer.  Before the declaration of the font family in the CSS file, you’ll need to add something like this:

@font-face {
	font-family: "Fontin";
	font-weight:bold;
	src: url(/fonts/Fontin-Bold.otf) format("opentype");
}
@font-face {
	font-family: "Fontin";
	font-style:italic;
	src: url(/fonts/Fontin-Italic.otf) format("opentype");
}
@font-face {
	font-family: "Fontin";
	src: url(/fonts/Fontin-Regular.otf) format("opentype");
}

Hopefully this is mostly self-explanatory, though what’s a bit tricky at first is that there are multiple declarations for the same font.  There’s also a src for each font file; so you’ll have to have these publicly accessible on your web server in order for the browser to download and utilize them.

Browser support: not all there yet

With the overloading CSS as above, both Opera and Safari under OS X fail a bit, instead rendering whatever is the last listed directive.  In that case, it’s probably safest to list the normal font last, unless you want everything in italics, etc.

One way around this is to use different font-family names, and then re-define the CSS such that em tags and any other italicized text gets the alternate font-family definition; i.e., font-family:'Fontin-Italic', etc.

Firefox 3.5 works without a hitch, however, so hopefully this will just be reconciled with later versions of the other browsers. Internet Explorer doesn’t play game at all; my guess is that there are additional tweaks specific for IE, as is most alway the case.

Still, what’s great about the system is also what’s great about CSS: even lacking browser support for the latest iterations, your site will fall back to using the same fonts you had set up previously.

Proceed with caution: license considerations

One trick with this font system is that there are not all that many fonts available for this particular use.  Most TTFs are not free, and even those that are free cannot necessarily be shared in such an open way.  While this may seem a bit cruel on the part of the font foundries and font makers, using this system does require that the font files are open and unrestricted: it doesn’t take much work to look at the CSS files to find the web location of the fonts themselves, which then leads towards very easy propagation of the files without a requirement for attribution, etc.

Conclusion

The constant problem in being on the edge, especially with the web, is that it doesn’t always work out for every system.  In terms of danger, however, setting alternate fonts does not seem to me to be all that dangerous.  In the absolute worst case, the site will just display whatever is next in the CSS list of fonts.  I personally am conservative in terms of utilizing new web technologies, though in this case I don’t see too much reason to hold back.