Here is a quick tip for creating responsive elements that retain their aspect ratio as they scale.
The problem
In a fixed width layout it is simple to specify both the width and the height of an element:
.rect{width:800px;height:400px;}
When creating a responsive layout things get trickier, since (to the best of my knowledge) it isn’t possible to specify a percentage based height that is relative to an element’s width. For example the following CSS rule won’t have the desired result, since the height value will be ignored:
.rect{width:100%;height:50%;}
A solution
However, when we specify a padding-bottom value for the same element, the padding measurement is calculated relative to the element’s width:
Parallax scrolling website interfaces have been popping up all over the place recently. I didn’t want to miss out on the fun, so I have put together a parallax scrolling demo built using jQuery and CSS.
The very first article I wrote on this blog, back in July 2006, was titled Goodbye hacks. Hello conditional comments. In that post I discussed how conditional comments could be used to feed different stylesheets to older version of Internet Explorer, smoothing differences between browser rendering engines without resorting to CSS hacks.
Conditional comments have provided a great stopgap measure while we wait for obsolete versions of IE to fall into disuse, but as the market share of IE6 and IE7 has dwindled I’ve found myself relying on them less and less. In fact, I can’t remember the last time I resorted to a separate stylesheet to make an old browser behave.
Anyone familiar with CSS will have encountered the concept of specificity, a nifty mechanism that allows web browsers to resolve conflicts between CSS declarations. Specificity is an essential component of the CSS cascade, and most of time it works in predictable ways which make your job simpler. However if you get too specific with your CSS selectors you might be making your stylesheets more complex than they need to be.
Remember when websites came with disclaimers listing their minimum viewing requirements, and shooed away anyone who didn’t make the grade? “This website is best viewed in Netscape Navigator” visitors would be advised, or “View this site in Internet Explorer at 800×600 resolution”. Those were the bad old days, and I would like to believe that as a community we have learned our lesson and moved on, embracing graceful degradation and progressive enhancement as alternatives to the “my way or the highway” mentality.
This morning I visited a website that caused me to wonder if we’ve come so far after all. I was looking forward to experiencing the site’s typography, which I’d been informed was exemplary, and was surprised when my browser served up fallback system fonts rather than the embedded web fonts I was expecting. A warning message in the masthead informed me that if the fonts looked “kind of weird” I should switch to Chrome or Safari.
Last year I created a port of the Monokai syntax highlighting theme for phpDesigner and posted it in the phpDesigner forums, but I think it deserves a proper home so I’m archiving it here on Pixel Acres.
Over the years I have streamlined the way I write and structure CSS to make my workflow more efficient. Here are a few tips I have picked up along the way.
My weapon of choice for code editing is the excellent program phpDesigner, but every so often I like to test drive a different editor to see what I might be missing out on. Recently I spent some time playing with Notepad++, and one feature that jumped out at me was the ability to choose from a large number of pre-installed syntax highlighting themes.
When I switched back to phpDesigner, the default blue-on-white color scheme seemed a tad boring, so I decided it was time to pimp my IDE! Unfortunately user created themes for phpDesigner are thin on the ground, which left me no option but to make my own.
If you want to create your own @font-face kits, you absolutely must check out Font Squirrel’s new @font-face generator tool. All you have to do is upload a TrueType or OpenType format font, and the generator spits out a zip file containing:
The original typeface for Safari and Firefox 3.5
A WOFF font for Firefox 3.6+
An SVG font for Opera, Chrome, and iPhone
An EOT font for Internet Explorer
A sample HTML page
A sample CSS stylesheet
The generator also features options to reduce file size by subsetting the font, cleanup font outlines, and auto-hint glyphs to improve rendering.
Now that all major web browsers finally support the CSS @font-face declaration, embedding fonts in a web page is possible with just a few lines of CSS. In theory this means that web designers no longer need to limit their font choices to a handful of system fonts, and are free to use any typeface they please. In practice that freedom comes with a caveat: we are only allowed to use fonts with a license agreement that allows web embedding.
The trouble is that digital fonts have no provision for DRM, and pirating a copy of an embedded web font is a trivial exercise for anyone with the mind to do so. That’s obviously not a prospect type foundries are too keen on, and consequently no major foundry offers a licensing option for embedding their fonts in a web page. If you link to a commercial font from your CSS stylesheet the chances are that you are breaking your license agreement. Even the number of free fonts with an EULA that condones @font-face embedding is pitifully small.
That’s where Typekit comes into the picture. Typekit is a new font delivery service devised by Jeffrey Veen that promises to take the pain out of licensing fonts for web embedding. In their own words:
We’ve been working with foundries to develop a consistent web-only font linking license. We’ve built a technology platform that lets us to host both free and commercial fonts in a way that is incredibly fast, smoothes out differences in how browsers handle type, and offers the level of protection that type designers need without resorting to annoying and ineffective DRM.
