Ethan Marcotte now blogs at Unstoppable Robot Ninja.

Weblog entry:

Sexily styling horizontal rules

Earlier this afternoon, I was helping Dunstan debug a bit of CSS. The inimitable Orchard was trying to add another background image to his horizontal rules: a gradient on the left, and one on the right. Nothing too tricky, but in the hopes of keeping his page weight low and his markup light, he was trying to do so without peppering his markup with unnecessary divs. So to that end, he was cleverly trying to use the CSS content property to drop in the second background image. However, while it worked in a transitional XHTML doctype, it failed in a strict one — or at least, it failed unless you’re one of the six people running Opera’s excellent browser.

Doing a bit of trolling around the Mozilla bug database showed me that Mozilla’s implementation of CSS generated content module is a pretty hotly debated topic: bugs 69398, 169334 (which is especially vitriolic), and 219417 gave me a quick overview of the controversy around Mozilla’s interpretation of the spec.

That’s not to say I understand the aformentioned specification any better. But I digress.

Anyway, the issue was with the default line-height and font-size values applied when the browser snapped into XHTML 1.0 Strict; by zeroing those out à la Virtuelvis, the layout now works perfectly in all modern browsers. If your particular browser doesn’t support the content property, then you’re sadly outta luck.

Internet Explorer, I’m looking at you here.

Update: And naturally, no CSS can be all things to all browsers — this one appears to be no exception. It appears that some of the slightly more…crochety Gecko browsers apparently have some difficulty with generating content before horizontal rules. Molly mentioned that there’s a ten-pixel vertical gap in Mozilla 1.4 between the generated image and the rule; Paul mentions that the gap is even greater in his install of Firebird 0.6.1.

In Molly’s case, at least, there’s a simple workaround: add a negative margin-bottom of ten pixels to compensate for the ten pixel offset (math so simple, even an English major could do it); I don’t have access to an old Firebird install to test on, but I’m guessing that the fix for Paul’s bug is similar.

In any event, this technique might be best left as a proof-of-concept for now. It relies on a CSS property that doesn’t exactly enjoy widespread support — and apparently, different versions of one of the browsers to support content disagree on the best way to do so.

So tread lightly as always, and have fun.

Comments

Hooray, technical difficulties.

There’s a WordPress issue that’s currently preventing old comments from displaying correctly. Sorry for the inconvenience, but hopefully we’ll be back online soon.