RLASKEY: words

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;}

now instead 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 :)

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

“f”.

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.