css

Centering text, but only when there’s just one line of it

Jordyn BondsLeave a comment

I just spent a fair bit of time figuring this out and thought I’d document it in case someone else is looking for the same thing.

What I wanted to do was center some text if there was only one line, but left-align it if the text spilled over to a second (or more) line:

Screenshot 2016-02-21 19.09.50

After going down a bit of a rabbit hole w/r/t ::first-line and :text-align-last, and even considering employing some JavaScript, I realized there’s actually a pretty vanilla way of achieving the effect:

div.parent { text-align: center; }
p.child { display: inline-block; clear: both; margin: 0 auto; text-align: left; }
Centering text, but only when there’s just one line of it

Honing a Cross-Browser Font Stack

Jordyn Bonds, , , , , 3 Comments

It is a testament to many things that I didn’t find this problem sooner, but apparently it is more difficult to arrive at an effective cross-browser font stack than I previously thought.

I have the good fortune to be working on a website redesign with a client and a designer who are realistic about web fonts.  They agreed that while Trade Gothic Condensed No. 18 was ideal for the headlines on the site, Arial Narrow would suffice when users didn’t have Trade Gothic installed.  Thus began my epic quest for a font stack that would work in all browsers.

The Problem

At the outset, I couldn’t figure out why font-family: "Trade Gothic Condensed No.18", "Arial Narrow", Arial, sans-serif; was not doing the trick. It wasn’t just not showing up on one or two browsers, it wasn’t showing up on any of them!

So I did a search for “font-family: trade gothic”. After a few modifications to my search, I found a number of situations where developers had “TradeGothic” in their font stack. Having never seen this space-less construction, I dug deeper.

Eventually, my search turned up a very thorough blog post by Rachael Moore fittingly titled Declare a Safe Font Stack With CSS Font-Family?, the upshot of which was that different browsers use different standards for naming fonts and font families.

Some interpret spaces in the name as spaces, some as dashes, and some prefer no spaces at all.  (I am not too proud to admit that this led me to hours of creating the most enormous font stack ever conceived, where I listed every possible permutation of “Trade Gothic Condensed No.18” with spaces, without spaces, with dashes, without dashes, with some words abbreviated and some not, etc).

Furthermore, some browsers (for instance Chrome) will accept styling inside the family name, e.g. “Arial Narrow Bold”; whereas other browsers (Firefox, for instance) take only family names, e.g. “Trade Gothic”, and relegate styling such as bold or italic (or “Condensed No.18”) to CSS properties like font-style and font-weight.

This last revelation led almost instantly to despair for me.  How was I going to be able to achieve bold for one browser but not the other without some very disappointing hacks? What could I possibly do about “condensed”?

The Solution

Luckily in my case I wasn’t trying to bold something.  Going forward, I’ll probably just always do that with font-weight rather than in the font name.  (Let’s not start thinking about what’s going to happen when I want a non-bolded font to cascade down to a bolded one).

But condensed was pretty key to my current mission.   This is where Moore’s post came in handy once again, as it introduced me to the concept of “font-stretch”.

Never heard of it? Neither had I.  Do a Google search for it. Click that w3schools link and then ctrl-F “font-stretch”.  Weird, right? Read on and you’ll discover what I did, which is that apparently this property is a spottily implemented one at best, and at the very least controversial. Luckily for us, Firefox, the main perp as regards strict font-family names, has started supporting font-stretch.  Also, and this is key, the other browsers seem to ignore it.

So, drumroll please, here is my working cross-browser font stack for “Trade Gothic Condensed No.18”:

font-stretch: condensed; font-family: "TradeGothic-CondEighteen", "Trade Gothic Cond Eighteen", "Trade Gothic Condensed Eighteen", "Trade Gothic", "TradeGothic", "Trade-Gothic", "ArialNarrow", "Arial-Narrow", "Arial Narrow", Arial, sans-serif;

Honing a Cross-Browser Font Stack

Conditional Statements As A Weapon

Jordyn Bonds, , , , 3 Comments

A friend of mine recently sent me this article in defense of using inline hacks instead of conditional statements for IE-specific styles.  I disagree with a lot of things in that article (see user Alex’s comments for a good summary of my thoughts), but I mostly use conditional statements for two reasons: 1) It makes code easier to maintain; and 2) I want to punish IE users.  If I have to use extra HTTP requests to exact said punishment, so be it.

Get a real browser.

Conditional Statements As A Weapon

Anatomy of a Web Page: Inline Tabs

Jordyn Bonds, , , , , , , , Leave a comment

The graphical conceit of tabs is a prevalent one on the web, and that fact is not without justification. Hyperlinks are like little doors suggesting treasure troves behind, tabs marked “top secret” in an FBI agent’s filofax. One can find unordered lists of main navigation links marauding as file folder tabs all over the Internet.

Which is all well and good, but what happens when tabs are not merely hyperlinks to other pages, but are rather intended to show and hide information without a page refresh?  The problem of how to semantically mark up such inline tabs has troubled me for years. Yes, years.

I started out making them their own unordered list of links, connected only by JavaScript to their corresponding content further down the page.  But this created a semantically empty set of links that were useless to users browsing without JavaScript.  To solve that conundrum, I even went so far as to generate the HTML for the tab links on the fly using JavaScript.

My next generation thinking on this problem led me to all kinds of fanciness involving definition lists (one of my favorite browser elements) and absolute positioning.  The idea was to have each tab be the DT of a corresponding DD — a semantically sound idea, but a very difficult structure to transform into graphical tabs with only CSS and a little JavaScript.

At long last, about a year ago, it occurred to me — something so fundamental to the Internet, I couldn’t believe I had overlooked it for so long.  Of course there was a deeply semantic way for me to link a list of hyperlinks at the top of a page to corresponding set of content further down: named anchors.  Duh!

All I had to do was write a quick JavaScript to hide my inactive tabs on page load and then convert links to “#divName” into a show/hide function.  So easy!  So obvious!  Now my inline tabs not only degrade nicely for users browsing without JavaScript but are also extremely friendly to search engines.

Anatomy of a Web Page: Inline Tabs

Why the future is not yet now: The truth about @font-face

Jordyn Bonds, , , , 1 Comment

I’ve had a number of clients come to me recently claiming that — because of growing browser support for the CSS rule @font-face — the future is now and they should be able to have whatever fonts they want for body copy (and everything else).  They’ve seen the Google Font API or Typekit and they’re certain that the floodgates have finally opened.  What ensues is a painful conversation about intellectual property, font foundries, and free fonts.

Unfortunately, the future is not now.  You cannot use Helvetica or Trade Gothic for your body copy unless said body copy is part of a Flash movie (or worse an image!).  It is still illegal to make rights-protected fonts downloadable on your website — which is what @font-face does.  Yes, you can now easily embed web-licensed fonts on your website.  And yes there are many services making this easy and fast to do.  But I have yet to meet a professional graphic designer who is willing to confine themselves to those fonts.

Why the future is not yet now: The truth about @font-face