At the end of today’s great session Web Typography Sucks by Mark Boulton and Richard Rutter, I made a couple of comments on the mic that have resulted in a few questions from people who heard them. Just thought I’d take a minute to clarify…
The point of my first comment was that, as far as CSS is concerned, all units of measurement are equal. I bought this up because a previous commenter had said something to the effect of, “I highly encourage everyone to use ems to size text.” It has become somewhat of a sacred cow to say, “pixels are bad for text sizing — don’t use them.” But the reality is that there is nothing inherently wrong with sizing text using pixels. There is only something inherently wrong with Internet Explorer 6’s implementation of CSS, which doesn’t allow for text resizing when the fonts are sized in pixels. I think it’s important to understand — especially now that IE7 is out and text resizing is no longer an issue — that this is not a problem with CSS. Shout it from the rooftops: It’s okay to size text in pixels! Sizing text in ems is great, too, of course. All units are equal. But, when dealing with inheritance and the cascade, it can be considerably more complicated to maintain em-sized text as compared to an absolute unit, like pixels. I was definitely not saying, “ignore IE6 users.” Instead, I was just saying, “let’s remember this is a problem of one browser, and not CSS itself.”
In my second comment, I noted that even as much as I care about using the “right” characters (real quote marks and apostrophes versus primes, em dashes versus hyphens, etc.), I still store the “wrong” characters in my database, and do the conversion to the “right” characters (via Smartypants) on the template/presentational side. Why? Because, as Mark and Richard noted, typographic conventions are different all over the place. Whereas I prefer to have my straight quotes converted to American-style curly quotes for this blog, the content for this site isn’t absolutely tied to this blog. If a French magazine wants to re-publish an article of mine, they may want to replace those straight quotes with a different style of quote marks. A magazine that uses a different style guide may wish to replace double-hyphens with another type of dash. So, I prefer to store normalized, generic versions of my content in the database that can be easily filtered into submission on the front-end. I’m pretty sure I wasn’t able to articulate this in the few seconds I had on the mic — my apologizes for that.
001 // Joe Clark // 03.13.2007 // 4:10 PM
If a French site wants to republish your work, they’ll have to translate it. It won’t matter what the original English quotation marks were; they’ll be replaced by French ones.
If you’re thinking they’ll just blockquote your text, on what planet do we substitute the page language’s quotation marks for blockquoted text?
Storing characters as neutral screws up in too many edge cases, particularly with the apostrophe, which is not differentiated from single closing quotation mark in Unicode. You are obfuscating your data, and saving it with known errors, by converting to some equivalent of plain ASCII. And in any event, how do you handle characters that can only be expressed outside ASCII, like ¶, é, or §?
002 // Luke // 03.13.2007 // 4:46 PM
The thing about IE7 is how do we know how many of those who have downloaded it are actually using it now. Is there some sort of site where we can see the statistics ? (Probably, I dont know these things), and how many people using the internet are still going to use IE6 because they simply don’t want to upgrade. So, as unfortunate as it may be, text size in pixels may still be a problem.
On the other hand, if what I heard about IE6 users having to automatically upgrade to IE7 is true, then yes, if you live in London, that is me singing on the rooftops.
003 // Jeff Croft // 03.13.2007 // 4:47 PM
Point taken, that was a bad example. But it’s quite possible that an English magazine may use a different style guide than me, no?
How this this a problem in real-world use? Obviously, I escape data for whatever the presentation is. If I’m putting data from my database into a place where it needs to have single quotes escaped, then I escape them (this is a built in filter for Django, just like Smartypants). My goal is to make the data in the database generic enough that it can be filtered into whatever is needed on the fly. If I store it only in the right output for this site, then there’s a lot more work to massage it into the right format for the next site that wants to publish it.
That’s a pretty backwards way of looking at it, to me. The way i see it, I’m writing in ASCII and then converting my writing to more rich encodings on the fly. I’m not writing in a rich format and then dumbing it down for storing, which is what you’re suggesting.
Obviously, if there’s no “neutral” ASCII character for the entity, then I can’t store an ASCII character for it. So, I just use the unicode character. I’m real-world, Joe. I’m not so religious about this stuff that I won’t break a rule for the sake of what works best — and to me, this works best.
The bottom line is that, since I write in ASCII (or basically ASCII, with a very rare unicode character embedded), there’s three options here:
Best tool for the job, my friend.
004 // Jeff Croft // 03.13.2007 // 4:55 PM
If they downloaded it, they’re using it. There’s not an option to run it alongside IE6.
Again, my point wasn’t that we can now ignore IE6’s bugs — we can’t. My point was simply to note that this is an IE problem, not a CSS problem. People seem to think that it’s against some kind of rule to size fonts it’s pixels. It’s not.
Saying we should never size text in pixels because one browser doesn’t deal with it as elegantly as the next is a bit like like saying we should never record music in stereo because some people still have mono stereo systems. We should definitely make sure we accommodate the people with single-speaker systems, but let’s not blame stereo technology for it. The technology is good, it’s the browser implementation that isn’t.
005 // Wilson Miner // 03.13.2007 // 5:14 PM
I’ll dodge the character encoding bit - I think we’ve reached a point with Unicode support that there’s no reason not to store, serve and display all UTF-8 all the time. But from a practical perspective I don’t see anything wrong with storing straight quotes if you’re writing in an environment that doesn’t convert them on the fly.
But I’ve been trying to make the same point about pixel units for font sizing lately to anybody who will listen. Pixel measures for font sizes, just like min and max-width, are part of the CSS spec. They’re both equally valid techniques from a standards point of view. The reason we have avoided using either one is because the overwhelming majority of our audience aren’t using a browser that supports them properly.
You and I have talked about this a bit and I think we’re pretty much in agreement. I do think it’s one of those things (ems good, pixels bad) that’s been hammered into our collective conscience as web developers (and for good reason) that it’s going to be difficult to re-evaluate objectively as the landscape changes and the underlying reasons for the current guidelines become less and less of an issue.
006 // Ed Eliot // 03.13.2007 // 6:11 PM
I think you made both points pretty clearly in the panel and I agree on both counts. I think we’ll still need to avoid pixels, or provide workarounds, for a little while yet but there’s no harm in pointing out what’s at fault and the reasons we have to take that stance.
007 // Sean S // 03.13.2007 // 7 PM
I was walking out — not because of lack of satisfaction in the panel — when you got on the mic. I stuck around to hear your question and continued leaving before hearing the panelists’ answer(s) to your second remark. I remember thinking, “good points, Jeff, good points.”
On the first point: I appreciate your seemingly unpopular favor of pixel metrics. Although I’ve been experimenting exclusively with ems lately, I’m not ready, nor do I consider it The Way, to abandon “px.” (Way to preface your comment with Pro CSS Techniques, too.)
I wish I had stuck around to hear Mark and Richard’s response to your second comment/question. I thought you made a good point and as I sit here in the airport I’m wondering about the pros/cons of using the character entities in the original content. What did they say?
I thought, though, in both morning panels (Typography and Design Aesthetic) you articulated your thoughts well and introduced great talking points for the panels. Pity I missed you this week.
008 // Jeff Croft // 03.13.2007 // 7:40 PM
Thanks, Sean. Mark and Richard didn’t have a whole lot to say about my second point. They just kind of thanked me for making it and then moved on (which was fine — I wasn’t really expecting a response, per se). :)
009 // Mike D. // 03.13.2007 // 8:07 PM
Jeff: Well in that case, I’m glad I’ve stayed “post-modern” with my pixel sizing this whole time. I never converted to ems and can’t really remember a single complaint about it either on my own site or on Newsvine. Actually, that’s not true. One person complained on my site but I directed him to my javascript-powered text-resizer. We may reach a point sometime in the next 5 years when we indeed move away from pixel sizing for good, but not for the reasons proponents commonly cite… rather for resolution independent display reasons. Once all type is rendered as true vectors, it will really be actual size we’ll want to be specifying (if we choose not to use relative units). I’m talking good old fashion points, baby!
Joe: I agree with what you’re saying, but users cannot be counted on to type in typographically correct quotes on the fly. You probably do it, but 99.9% of the world doesn’t. Converting inputted text on the way in in a CMS is a tricky and dangerous proposition. The postulate you generally follow is “don’t ever change the source material” because a) you eliminate all risk of irreparable harm to due regexes and other nastiness, and b) when the user re-opens the text to edit it, it should look just as it did when they hit save. The best solution for this is actually something we, gasp, can look towards Microsoft Word for: typographical clean-up on-the-fly. Make my quotes smart quotes as I’m typing them and all will be fine.
010 // Alberto // 03.14.2007 // 9:11 AM
That’s not so easy. Everyone can download a copy of IE7 but only legitimate Windows users can install it because of the Windows Genuine Advantage Validation. Moreover only legitimate customers can access Windows Update. If you consider that Windows is probably the most pirated piece of software on earth, you easily understand that many Windows users will stick to IE6 for a long time. Of course there are tools able to baypass Microsoft valitation check but the average Windows user is not that smart.
011 // Jeff Croft // 03.14.2007 // 11:20 AM
You’re kidding, right? As if it wasn’t already impossible to be “accessible” to everyone, now I have to accommodate pirates who can’t figure out how to get their crap to work? Forget it. If you’re going to pirate Windows, then it’s up to you to pirate it well. If you can’t even be a quality criminal, that’s not my problem.
012 // Baxter // 03.14.2007 // 12:22 PM
Just out of curiosity Jeff, what percentage of your users are on IE7 versus IE6? For me it’s 27% IE7, 32% IE6, with the remainder mostly on FF or Safari, so IE6 is very rapidly dwindling. For me, anyway.
013 // Rob Goodlatte // 03.14.2007 // 4:23 PM
I often use pixels for horizontal widths, but will sometimes use ems for vertical dimensions and font sizes on a page. My use is actually a bit ironic - the em unit in traditional typography is a horizontal-only measurement, and comes from the “em dash” - a dash the same width as the letter ‘M’. CSS just uses the height of the font, so the ‘em’ name just makes no sense now.
The only reason I used em’s in the past was for IE 6. Now I’m going back to pixels because they give me that much more control.
014 // Jeff Croft // 03.14.2007 // 4:54 PM
Indeed. But, the page zoom is there for people that need it, so this pretty much alleviates the problem.
015 // Jeff Croft // 03.14.2007 // 5 PM
On this site, I’ve got 10% using IE7 and 15% using IE6. Bear in mind that this is quite a technical audience, though.
016 // Alberto // 03.16.2007 // 3:43 AM
@Jeff In Italy (and in many other countries) piracy is a much bigger issue than in US. It’s a sad reality. Most pirates are simply home users swindled by unscrupulous small local retailers. Software firms have tolerated that for many years (in fact piracy helped to the diffusion of their products) and only recently they are realizing the issue in full. Luckily the diffusion of laptop computers (with a genuine Windows/OS X preinstalled) will contribuite to reduce piracy, at least at os level.
017 // Richard Rutter // 03.16.2007 // 4:33 AM
Thanks for your questions at the panel, Jeff. Both were really good points and I would have liked to have expanded on them more at the time (or at least chatted with you about them at some point).
Regarding sizing text, my method as explained in the presentation, is to start with a baseline set in pixels and then use ems to scale from then onwards. I stick with ems because I’m used to using them, but also because top and bottom margins need to scale with the text, so I just specify everything in ems, rather than mixing up units. As you said there’s nothing technically wrong with sizing text in pixels, and it’s certainly easier on the maths.
As for storing ‘neutral’ characters and converting them for presentation: it’s what I do for my blog. Like you, I write in ASCII (for the most part) and store articles as written in a database. The articles are then post-processed (using a homebrew based on Textile) at display time. Storing stuff as written seems to be the most appropriate was to me.
Anyway I’m glad you enjoyed the panel and thanks again for the questions.
018 // Rob L. // 03.17.2007 // 1:25 PM
Bingo! I think that is the phrasing that will allow many folks to finally get it. Nice.
And if you’re using a conditional comment to deliver an alternate stylesheet to hack around IE6’s ten zillion other annoying issues, you can always provide keyword and/or em-based styles there if you want IE 5&6 users to be able to scale text too (recommended, of course).
Then, on the glorious day that IE6 disappears from your server log reports, just delete the IE6 stylesheet and the call from your template.
Sorry I didn’t get to meet you at SXSW; I live in Austin so it’s hard to tear oneself away from work for the full day and see every panel one might want to see. Been digging this site and particularly its commenting community for a long time, though. Hope you enjoyed my hometown.
019 // Mike Stickel // 03.18.2007 // 12:48 PM
I tend to follow the same process as Richard, set the default/initial size in pixels and use ems to resize from there. If I think back to why I started that way I would have to say it was due to the whole “pixels are bad for IE6” thing. Now with IE 7 out I’m just stuck in my ways.
As far as the comment you made, I can certainly appreciate the point you were making. It’s unfortunate that it didn’t come across as you intended to some people but it seems that’s where blogs come in handy :)
020 // Jeff Croft // 03.18.2007 // 12:56 PM
Well, there’s certainly nothing wrong with your way, either! It’s just more complicated math. If that’s okay with you, then go for it. :)
021 // Mike Stickel // 03.18.2007 // 10:12 PM
True enough. In your case to you just strickly use pixels and not worry about IE 6 visitors? For this site it is pretty easy to decide but what about the sites you do for work?
022 // Jeff Croft // 03.18.2007 // 10:53 PM
For this site, like you said, it’s an easy decision. I ignore the IE6 users when it comes to text resizing. They’re very few of them, and I explicitly state in my about page that I don’t actively try to support IE6 here, as this is my playground for the latest web design techniques (and IE6 support would limit me in that regard).
At work, we’ve generally sized text in ems or percentages to account for IE6 visitors. But, we’ve just (as in over the past four days) built a CSS framework that we’re going to start using, and it is pixel-based. On http://LJWorld.com, we’re up to 30% of users on IE7 (40% for IE6) and growing very rapidly. With only 40% of our users on IE6, and only a small portion of those being people that want to resize their text, I don’t mind saying to someone, “if you want to resize text, upgrade to IE7.”
This may seem insensitive, but I think those people who have certain unique needs (such as people with low vision) have to take some of the responsibility upon themselves. In the real world, we don’t make road signs with gigantic text because some people can’t see well. Instead, we require them to get glasses. Likewise, I think it’s fair to require this small percentage of users to upgrade their browser, now that they can do so easily (IE7 comes through Windows Update, and works on the same hardware IE6 does) and without having to change to an entirely different browser (switching to Firefox is a hurdle some people aren’t willing to bear, but switching from IE6 to IE7 feels much less intrusive).
All that having been said, when I built http://BoomerGirl.com, which is aimed at an older generation of people who are more likely to have lower vision, I did size everything (and I mean everything, even images) in ems. Just goes to show that there’s never a perfect answer. Everything has to be case-by-case.
023 // Mike Stickel // 03.19.2007 // 1:21 PM
How true it is.
I hope we’ll be hearing more about this in the coming weeks.
024 // Jeff Croft // 03.19.2007 // 3:10 PM
I’m not sure if it’s something we’ll be releasing under a public license, but at the very least, you’ll see it used in a few of our upcoming projects — and since it’s CSS, you’ll be easily able to view source and see what we’re doing. It’s nothing terribly revolutionary. Similar stuff, in a lot of ways, to what YUI has done with grids and type, but a bit more opinionated and a bit more tailored to the sorts of sites we make.
025 // Faruk Ateş // 03.26.2007 // 10:11 AM
Except that the page zoom is a relatively useless feature, because it zooms in such large increments that you get sidescrolling right away which may (or already does) turn off a lot of people from using it.
My question is, why not use em’s? They’re just as easy, there’s no downside to using them and they have the benefit of letting IE6 (still most widely used browser, and probably will remain so for at least another year, year and a half) users scale their text as well.
026 // Jeff Croft // 03.26.2007 // 10:35 AM
@Faruk: The only reason not to use ems is because of the complicated math. You can say they’re so easy all you want, but the fact is that they’ll never be as easy as pixels. Check out this segment from Wilson’s The Problem With Pixels:
With pixels, if you want 15 pixels, you say, “15px.” With ems, if you want 15 pixels, you say, “15 divided by the size of my typeface at this point in the document, which is probably no longer the same as the base font size I specified.” You can’t argue that ems is easier. :)
All that having been said, I’ve been clear that I think using ems is a great way to size text. My of the sites I’ve built over the past couple of years have used ems. There’s really no good reason not to use ems, except that the math is a bit more complicated. I’m not advocating pixels for text instead of ems at all.
All I’m saying is that, in the eyes of CSS, the two are equal. That’s all. CSS doesn’t give any preference to any one unit of measurement. CSS couldn’t care less wether you use pixels or ems. That’s my point.
027 // Faruk Ateş // 03.26.2007 // 1:38 PM
Yes, the math is more complicated — if you design in pixels. I can see why you’d want to do that, and there’s good reasons to, but I personally just don’t. I design in a pixel-based environment, but I don’t design (my type) in pixels.
What I do, in my Photoshop compositions I just create rough estimates. As Photoshop’s type rendering doesn’t match any browser’s to begin with, the only thing I really design in the PS stage is a rough size and the typeface for each body of text.
Then, when I’m working with the design done in CSS, I tweak the fonts file (I use a separate type.css) to get every bit of type in my design to fit properly, the way I want it to. I find it much more reliable to use a browser environment for finalizing my type because I don’t have to “convert” from Photoshop’s model (which simply doesn’t translate to the web, I’m afraid) to CSS that way.
This leaves me to design my type in em’s without having to do any complicated math at all. As per Wilson’s example, I wouldn’t be trying to shoe-horn the span to be 15 pixels, I’d be sizing it to resemble something I like (and probably end up with either 0.8 or 0.85em there).
Saves a lot of headaches, but again, I reiterate that I already know that there are good reasons to use pixel-based type in your design stage.
Oh, you’re definitely right about that — I Totally agree with you. Very, very true! :-)
028 // Jeff Croft // 03.26.2007 // 1:51 PM
Good point. If you don’t care about pixel-precision and approximations are good enough, then the math doesn’t have to be very complicated in ems.
Me, I like my pixel precision when I can get it. :)
029 // Faruk Ateş // 03.27.2007 // 5:22 PM
That’s my point though — pixel-precision doesn’t actually exist from Photoshop to the Web, as PS’s way of dealing with type doesn’t match any browser’s rendering engine.
Even when you stick to Photoshop’s pixel units and pixel units (or complicated math) in CSS, it’s still an approximation in the end, in the rendering of the type.
030 // Jeff Croft // 03.27.2007 // 5:45 PM
Woah, I never said anything about Photoshop. :)
I just mean that if I want my type to be 15px, I want it to be exactly 15px. In order to do that, I have to use .833333em in the above example (which is the complicated math I was referring to). You said you would probably just round it off at .8em or .85em. That may be fine for you, but it doesn’t get me my exactly 15px.
Wy do I want exactly 15px? It has to do with alignment of other elements on the page. It doesn’t have anything to do with how my comp looks in Photoshop (half the time, I don’t even make a comp in Photoshop). For example, I might size my image to be 300px tall so that it lines up perfectly with with 20 lines of 15px-tall type. This wouldn’t be possible if I rounded off to .85em or .8em. It’s only possible if I can be sure I have exactly 15px-tall type.
If I want exactly 15px, I am forced to choose between complicated math and using pixel measurements. Period.
031 // Faruk Ateş // 03.27.2007 // 6:39 PM
Or whatever design tool :p
Right, well, if I size my text blocks up to match imagery like in your example, I’d probably go for 0.83 em. I can imagine wanting it to match perfectly, but unfortunately that never quite works given that different browsers render type quite differently from each other anyway.
I see your point though. Guess that’s where we’re actually different, you and I :-) I just give up on wanting pixel-precision to that level of precision, because it doesn’t actually exist[1], but you power through and go for it anyway. Which I must say is admirable, I take the easy way out I guess…
BTW, this is one of the most interesting comment-discussions I’ve seen in quite a while :)
[1] especially not for any browser besides IE that can increase text sizes at all times.
032 // Jeff Croft // 03.27.2007 // 6:55 PM
CSS is my design tool. :)
You’re right. But I personally would like to get it perfect, at least, in the browsers that do things the right way for the first page load. I’ll reference Wilson’s post again, whereby he suggests designing for pixel-precision the initial page load in the ideal environment, and then making sure everything is “good enough” in the other browsers and when people do things like resize their text. That is to say, I’d rather my site looks perfect in Safari and “good enough” in others, than “pretty good, but not quite” in all browsers.
But that doesn’t make your approach wrong. Different strokes for different folks, and different solutions for different problems. In some cases, the pixel-precision isn’t that important and in others, text resizing that works great in all browsers is vitally important (see my earlier reference to http://BoomerGirl.com, which was for an older audience).
:)