I just logged a bug report after doing a little testing with the IE8 Beta. Overall, the progress and standards commitment in the latest effort is fantastic and exciting. Hats off to the Internet Explorer Team.
There’s one lingering decision that appears to have carried over though, and it’s an important one. I say “decision” since, by now, there clearly must be a reason why it’s still there. I’m also reminding myself that this is still a beta release. But the earlier we chime in on things, the better, right?
Here’s what I logged:
As with previous versions of Internet Explorer, the IE8 Beta also fails to resize text using the “Text Size” tool when fonts are sized in pixels. Most would consider this a bug, where the user should be able to trump any size specified by the page author, regardless of the unit specified. I remained boggled as to why this has been a consistent design decision.
It creates an accessibility issue for readers with poor or low vision, while making pixels a less than desirable choice for the page designer. In an ideal world, the designer should be able to specify fonts in any unit he or she desires (px, em, percentage, etc.) while the reader should have ultimate control over the size, using the browser’s controls. IE’s “Text Size” tool would appear to be broken when a reader attempts to adjust fonts on a page where fonts are sized in pixels. Surely confusing.
Thanks for listening, and keep up the excellent progress!
Disagree? I’d love to hear it :)
Dribbble What are you working on? 
Instapaper Icon design 
Sass For Web Designers Paperback + eBook A Book Apart
CSS3 For Web Designers Paperback + eBook A Book Apart
Bulletproof Web Design Third Edition New Riders 
Handcrafted CSS Book and DVD New Riders 
Web Standards Solutions Special Edition Friends of Ed
61 Comments
Decision, albeit a very poor one.
It’s a bug. Pixels are relative units and should be scalable in the same way as em. IE should not treat them as fixed units, the distinction is clear and in the CSS specs. IE is wrong.
Smells like a decision to me, although I’m not sure I agree with it.
Thanks, would be interested if you get a response from them regarding why they keep this behavior.
(btw, your post preview page looks a bit banged up)
Bad decision that should at last be treated as a bug and fixed. We started this conversation in 2000. Enough already. Chris Wilson, I love ya. Scalable text, please, regardless of unit. Accessibility says this. CSS says it. Firefox and Safari are on board (and lamented IE5/Mac was, too). It’s time.
This is a very bad decision, but it is one in my opinion.
You can interpret the CSS2 specifications on it if you want to. Paragraph 15.7 (the font-size property) says “Note that an application may reinterpret an explicit size(..)”, the ‘may’ is self-explanatory.
Source: http://www.w3.org/TR/CSS21/fonts.html#font-size-props
So if IE doesn’t want to be a good choice for accessibility, we still have to rely on em’s.
Decision. This falls in line with IE’s trend to not “break the web” from pre standards implementation. If you’re on the IE8 team you have to ask yourself which “breaks the web” more:
Enable scaling of pixel fonts and watch as pixel-based layouts crumble into a mass of text over text and scrollbars, or keep scaling disabled and disappoint those with poor eyesight and a portion of the development and design community while keeping those older websites in “pristine” condition.
Not the choice I’d like to see made, but it isn’t that surprising.
Actually, it’s exactly what Zeldman said. So, both.
Funny you should bring this up today. Just yesterday I worked with a visitor to one of our client’s sites who was upset because he couldn’t read the fonts on the client’s site. His text-size had been inadvertently set to “smaller.”
IMHO that entire option in IE should just go away. It has been troublesome and “odd” since it first became an available in IE, especially due to the fact that depending on what unit a designer uses to specify font-sizes it does or does not work at all (as your bug report suggests).
Now that IE supports page zooming, the need for this options seems depreciated to me.
@Matt Wilcox, pixels are not a relative unit of measure. Isn’t there a page zooming capability in IE8?
I’ve reconsidered my thoughts on this issue lately. If you’re using pixels to define an interface element’s dimensions and also to determine font size, shouldn’t the entire interface scale when the text size is bumped in either direction? Gut reaction: of course not.
Maybe they should implement more consistent rounding mathematics to relative units of measure like ems.
I’d hope that pixels would become scalable in this version of IE8.
I was going to make a joke about implementing a special meta tag to control they way pixels are resized, but actually there’s no reason why IE8 shouldn’t do it differently and just let those targeting IE7 via the meta tag get non-scaling pixel unit and those going with IE8′s defaults getting scalable pixel units.
@Angelo – yes they are.
http://www.w3.org/TR/REC-CSS2/syndata.html
take a look at 4.3.2
@Angelo Simeoni: Actually, Matt is right, pixels are indeed relative units.
See: http://www.w3.org/TR/CSS21/syndata.html#length-units
px: pixels, relative to the viewing device
My point was exactly that. if pixel sized fonts change, so too should an interface sized in pixels. Most designers would balk at this notion, being comfortable using pixels as a means of achieving ‘pixel perfect’ websites.
For further reading, I’d recommend the following resource:
http://icanhaz.com/browsers
Pixels are relative sizes across platforms (resolution dependent), but they’re not relative on any one specific platform, are they? What I mean is that if I increase the size of the text on my page, it’s no longer “12 pixels” tall, even though that’s what’s defined in the style sheet, is it?
Would it make more sense to push for more ubiquitous use of relative sizes? Maybe I’m just hung up on the idea of pixels being a relative unit of measurement.
I don’t actually know anyone (other than developers) who are aware that you can change the default text size in a browser. If they need it, they almost always use ctrl+ or ctrl & mousewheel.
@Angelo – yea, I think IE was using page zooming on IE7 too
@Matt Pixels are *technically* relative, but relative to resolution, and it’s not as flexible as an EM, EX or percentage. Thats what gave birth to the EM based layout (like this page). With page zooming it seems to becoming less of an issue now-a-days.
If crafted right (em based layout), you should be able to change your body font-size and shrink the entire page to fit better into a handheld device (if you need to). Rather than writing a whole new style sheet.
my2cents
Doesn’t change the fact that they are relative according to the spec. If IE doesn’t treat them as relative units, it’s not compliant with the CSS spec.
Also, isn’t page zoom, in essence, re-defining the system ‘pixel’, and thus re-rendering the scale of everything else? Makes perfect sense to me that if you redefine the ‘pixel’ everything should scale. This is the behaviour I want.
The idea of px being absolute units falls over completely with newer devices, where the pixel density is far higher than the 72dpi that constituted ‘normal’ at the time the spec was written. This is exactly why the CSS engineers had the foresight to define px as relative and not absolute. Scale the pixel, scale the entire display.
@Angelo: I agree that a pixel based layout should also resize *if adjusted using a zooming feature*. But changing TEXT size from smaller to bigger should not affect pixel based layout. Px are relative only to the device, not other elements on the page. Therefore, only changing resolution or devices (screens) should affect a px-based layout.
I think the issue here is we are all used to the idea of a text size option. The fact is that text size was, and always has been, a stop-gap measure for making small pages easier to see. It was intended to make the text on a page readable for those that needed a bigger page. But it should never have changed only the text size, it always should have changed the whole page, as current page-zoom does. Trouble was that there wasn’t a way of achieving that at the time, and text zoom was better than nothing. We’re too used to this broken behaviour.
Text re-size, independent of the rest of the page, is a hack.
Page zoom is what should always have happened, it maintains relations between text and content better, and doesn’t destroy the intent of the designer.
Technically this page zoom ought to be achieved by ‘re-defining’ the system pixel (because it’s relative). The idea of resizing text independent of the rest of the page is just harking back to when such an inelegent hack was required. It was never desired. Bin it.
I guess we’re getting into the realm of a de facto standard, but I do believe that all text-units should be resizable per Firefox, Safari, etc. To me, zooming is not the ideal method of allowing people to manage the font size on a page.
That said, I was looking in the accessibility information from WAI and found this:
http://tinyurl.com/38qek8
“The user agent may satisfy provision one of this checkpoint through a number of mechanisms, including zoom, magnification, and allowing the user to configure a reference size for rendered text”
I think *ideally* it would be any of these as suggested in the comments above. I don’t know if IE or any of the other browser vendors pay mind to UAAG 1.0, but it would be worthwhile.
@Angelo: This is not a question of ‘pixel perfect’ designs, this is a question of logic.
An interface defined in pixels should not change when a user changes the text size. The user is not changing the size of a pixel, just the text.
An interface defined relative to the font size, i.e. in
ems, should change when the font size changes, however.A pixel is a relative unit as the size of a pixel is dependent on the ‘dots per inch’ of the screen, so is fixed for each individual computer, but is not the same for all computers, whereas an inch, for example, is the same for all computers.
Decision. Rightly or wrongly I think the IE team put the empahsis on the developer to specify if they want a site text resized by using percentage or em’s over px. If they use px then they want the site fixed how it is and forget about accessibility.
Personally I use em’s if a user resizes a site and it breaks they are aware this could happen but so long as they can read the text thats the main thing.
Having pixels behave differently for
font-sizeseems unintuitive and incorrect. A pixel is relative to the density of the screen in use.pixels = relative
relative != resizable
Pixels are not a relative unit of type size. Sure, the spec says it’s relative, but only to the viewing device. A pixel is always the same size on a particular device. If text is sized as “14px” and a user resizes their text, the type size doesn’t stay the same; it may increase to “18px.” The size of a pixel is still the same; the type size has increased its quantity of pixels. Therefore, it can’t be a relative unit.
I agree with Angelo’s initial comment. If a paragraph and a
divare sized with the same unit, and a user bumps up her text size, why would you expect one to change and the other not to? I agree with Oliver R. White, in that “an interface defined in pixels should not change when a user changes the text size,” but I’ll also assert that neither should text (unless both are intended, in which case computed units—such as ems or percentages—should be used).I’d also say much of the misunderstanding lies in terminology. I think by “relative,” some people mean “computed.” The referenced spec refers to an
emas a computed unit, which is dependent on a number of factors, such as parent element, user settings, etc. Ideally, intended resizable elements like elastic interfaces and text sizes should be defined with computed values.I think that’s the way things should work. Practically (and personally) though, I love how text sized in pixels works in modern browsers (the IE family excluded), even though I see it as technically incorrect. I do wish that IE behaved similarly.
Dan, I think your initial guess is right: it’s a decision. Otherwise, why would it still be around after at least 2 versions and years of uproar from the community? It’s a poor decision and should be rethought.
Personally I believe it is time that IE started to act like everyone else. It would be great if I didn’t have to cringe before loading up a page to see what IE was doing to the rendering of it. But if they decide to forgo the “standard” approach, it wouldn’t really be surprising. In fact the most surprising thing about IE8 is how much they have cooperated with the standards community.
However if they improve the rendering of image scaling that would go a long way with me. Using an em based layout and scaling the images on the same em scale is great, except when you see what IE is doing to the images that are at anything but 100% scale.
Oh, and if they could make a mac version again that renders identically across the two platforms then developing for it would be so much easier.
So if they render everything standards compliant, that would be best. But if they choose not to, at least let me test my site natively on OSX.
@Dan Mall, What’s to love?
I’ve made the switch to em’s when resizing is required (which is, in my book, a must). Taking proper caution, I’ve had no negative experiences so far.
Browsers should strive to be technically correct to the spec, regardless of habits designers & developers may or may not have developed over time.
I think Mr. Mall’s got it. Pixels are relative to the viewing device, but at the end of the day, a pixel is a pixel. I’m sure, in the eyes of the IE8 dev team, if you specify something as being “14px” you fully intend for it to be 14 pixels. However, and possibly counter-intuitively, for the sake of accessibility, pixels should scale “relative” to the increased scale of the layout. As a designer (and front-end coder), I want the pixel-perfect accuracy of “px,” but the relative scaleability of “em.” I think the main hang-up for the IE8 team is semantics. Possibly changing the meaning of “px” from “pixel” to “perfect xpansion unit” would make all things better.
It’s a bug caused by a bad decision and should have been fixed long ago. Like around the time when IE 5/Mac was released.
I would say it’s a hangover.
It kind of makes sense with the other aspects of IE5.5/6 rendering, where allowing fonts to scale would break many sites layout.
However, once that changed (in IE7′s standards mode) it was a poor ‘decision’, and I’m a little surprised it is there in a new engine.
I guess you’re one of the people allowed to enter bugs then? Is there one about “clear:both” not working on br elements?
I basically agree with Dan Mall. The IE team is trying to do the “right” thing here. I can see how it probably is actually the “right” thing. But, they lost the battle so long ago that they just look silly and desperate by trying to forge ahead with pixel-based text being unscalable. Today, the “right” thing to do is to jump on board with the other major browser makers in the name of interoperability and developer goodwill.
“What’s to love? I’ve made the switch to em’s when resizing is required (which is, in my book, a must). Taking proper caution, I’ve had no negative experiences so far.”
With any computed unit, there comes the danger of inheritance issues. If you’re not sure what I mean, drop me a line and we’ll chat over email (as to not clutter up this discussion with a tangent).
“Browsers should strive to be technically correct to the spec, regardless of habits designers & developers may or may not have developed over time.”
I don’t know if I buy that. The people that write the specs are also human, and just as susceptible to error as the browser makers that have to implement it and the developers that code against it. I wouldn’t take the spec as gospel, but rather prefer to support methods that are tried and tested. And subjective. And therein lies the problem :)
Trouble is that a pixel isn’t actually relative to the device. The definition is all about some sort of ‘virtual pixel’ that has lots to do with the distance from the screen, subjectivity, and not a lot at all to do with physical pixels. Take a look at the definition of ‘pixel’ in the spec:
“If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values. It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length.”
So, pixel can’t be called absolute even relative to the screen density, because it also depends on the length of the arm of the operator!
Also note that it says, explicitly, “the USER AGENT should rescale pixel values”. That means I get the choice of how big or small a ‘pixel’ is. Making it completely relative from a subjective standpoint and not a device standpoint.
The thing is, OS’s are going resolution independent, and the physical pixels no longer matter – it’s all about this ‘reference pixel’, which by definition is somewhat arbitrary. And, completely within the scope of the user to decide what size it ought to be. In exactly the same way as an em is user definable.
px == em in terms of behaviour.
I actually really like WebKit’s approach of adding a -webkit-text-size-adjust property that allows developers targeting that specific rendering engine the ability to specify which elements react to user text size changes. It’s actually a handy feature for web app interfaces where you have a “content” area you want to be resizeable without degrading the whole interface. It’s a nice tradeoff in some cases, and would be a nice step forward for IE from the browser-wide lock on pixel sizes.
I may not be as familiar with css and browser specs but I do know a little about typography so here’s my 2 cents on some of the comments above..
There is a huge difference between scaling vector elements such as typefaces and scaling bitmap photos so I disagree that page zooming (a useful feature) makes text-resizing obsolete. It wouldn’t be uncommon for a user to want text more legible without scaling photos or other elements on the page.
There’s even a subtle difference between scaling vector images and scaling typefaces since scaling a typeface is more than just enlarging by x-percent. Good typefaces are carefully crafted at each point/pixel size (or range) to be optimally readable.
Anyway, I agree with the majority that IE8 should scale text defined in px.
It’s funny, I thought this was solved in IE7, but I never bothered to check for myself.
I am absolutely amazed that one of the largest problems in IE6 (as far as designer complaints are concerned) has not been addressed. That is ridiculous.
I think we are all missing the point here, which is surely one of usability.
Text resizing behaviour should be uniform, irrespective of the defining unit.
To clarify, if text resizes when defined in ems, then so should text defined in pixels. The average user has no idea what px or ems are, nor do they need to, but they should not experience irregular behaviour as they will be unable to diagnose the problem or, more pertinently, do anything about it.
This is not an issue of design, but of use.
Pixels are most definitely not relative units, and I have no idea where the misconception that they are came from. If I specify that something is 10 pixels high, it should always be 10 pixels high. It shouldn’t suddenly become 20 pixels high because someone doubled their display size. I think the CSS specification is wrong about this, and it seems that the IE developers agree with me.
I don’t really care what kind of unit has been used to specify the initial size. If I change the “Text Size” from “Medium” to “Larger”, I certainly expect the size of the text to increase.
The current behavior in IE is only ‘correct’ in some obscure technical interpretation, but it is hurting normal people (and it kills kittens).
I’m with Oliver R. White on this one.
The user of a website expects the text size to increase when they request larger text so this should be the default behaviour for all methods of specifying font size.
We could discuss until we are blue in the face as to the correct implementation of the CSS specs, but ultimately it’s the user who is the most important and they shouldn’t be presented with inconsistent behaviour.
Without adding to the pedantic debate, and setting aside the argument of what “relative” means, I do think that Internet Explorer ought to resize pixel-sized fonts. Vote += 1.
Add me to the ‘standards-please’ camp.
Tell me, why does anyone ever need to use pixels? I realize the argument is over IE’s decision to lock the adjustment of text-size, but why not just use ems and percentages?
Is there something I’m missing? When is it an optimal choice to use pixels for font-size?
I think pixel-sized text should be resized when user chooses to make text appear bigger. Why? Because the user chooses to do so.
If user wants text to appear larger than the default (set by the designer), this should happen regardless of technical details, such as the units used in the layout definition.
User experience is more important than any standards, definitions and interpretations. Likewise, despite hours of work spent by sound engineers, producers, musicians and such, we are still free to adjust the volume as each of us requires.
I am not sure whether you guys observed the picture rendering in IE-8. It is quite confusing as the clarity of the picture is losing. Most of the time I use ctl+shift+- sign to reduce the font and picture size is there any permenent solution for the same
A decision that needs undoing along with the decison to make page zoom the default in FF3.
It all comes down to freeing the user. If he takes an action to deliberately bump up the text size, he should. We’re not asking for N pixels to grow automatically to N+X pixels! We’re simply asking for IE allowing users to choose their text size. Period.
And page zoom isn’t the same thing as it’ zooms everything, not just the text.
I’m with IE8
Even though I don’t use it, I do test on IE.
pixels are relative to the device, so pixel fonts shouldn’t scale. In my eyes it’s not a bug and should be kept “as is”. If designers want to really control text, they need the option for an un-scaling font, for whatever reason / reasons might be thrown up now and in the future.
removing this “bug” would then limit the tools at a designers disposal in the quest for accessibility. If you want text to scale relative to the users settings, use em + font size 100% declaration. It’s simple enough.
As Hawken King points out it is a way to let the designer have some control.
I might choose to make my title be in px as it is not important to the reader, and expanding it will just distract the viewer from the actual content of the page, which has text measured in ems so the reader can scale them as needed.
I agree that most of the web designers/coders should use units different from pixels to define their text size, however Internet Explorer team should finally do their coming out (!) and allow pixel zooming.
I think the main problem in this argument is the confusion between the actual meaning of the word “pixel” (a physical dot on the display device), and the interpreted meaning in the CSS spec. The spec essentially says to interpolate the size of the actual pixel to an expected size (nominally 96dpi), independent of the physical display resolution. The CSS idea of pixel is virtual, not real.
When elements sized in actual pixels (images, divs) need to align with text sized in pixels, this alignment should not be broken by resizing. I agree with MS on this point, and the rationale for their decision makes sense. With page zoom, this rationale could change.
Isn’t the point unit (pt) supposed to be the scalable equivalent to pixels? Why not settle on that for sizing instead? (Of course, assuming it would be predictable across browsers.)
Another confusing argument I see in this discussion is over the meaning of “relative” unit sizes. What “relative size” means in CSS is that the unit size changes relative to the element containing it: 1em inside a 1.2em element is bigger than 1em inside 0.8em, right?
“em”, “ex”, “%” are relative.
“px” and “pt” are NOT relative.
Agreed to Maltax. He is right.
@Andrew Vit
pt is a physical measure equivalent to 1/72 of an inch. It is for print, not screen.
@Matt Wilcox
Actually, a typographer’s point is 72.27 to the inch. Thankfully, PostScript rounded it off… ;-)
Real-world points roughly translate to on-screen pixels because monitor resolution is near enough to 72 points. This could be a useful baseline if only it were standardized. *sigh*
In practice, the trouble of course is that OS’s translate the size of a point differently. Mac has historically used 72ppi monitors, so it translates 1:1 by design. Windows considers monitor resolution as 96ppi, so a Windows point is actually 1.333 pixels.
What we actually lack in CSS (let me count the ways) is one single measurement system that’s:
1. not affected by the containing element (so, scratch em, ex, %),
2. scalable equally for both type and element dimensions (so, scratch px),
3. and consistent between platforms.
If it weren’t for that last item, “pt” could be a very useful unit, for both screen and print.
Because “px” is scalable for fonts but not for boxes, then it’s meaningless as a unit of size. Why shouldn’t it treat both the same? I’m not an IE fan, but I actually prefer their interpretation of the spec: to keep the units internally consistent.
The rest should be up to the designer to use the units correctly, and if only pt:px were treated as 1:1 at “normal” size, across platforms, all this would be moot.
Excellent Information. We as web designing also facing same problem. Thanks for nice posting. I also Agreed to Maltax he is right.
Time to grab the IE8 Beta – I haven’t gotten the chance to look at it yet. Is this going to be another conditional comment or did they finally produce something I won’t have to worry about ? (As much)
@Andrew Vit
“monitor resolution is near enough to 72 points” – say that to my laptop or my iPod. Not even close. Pixel density on screens varies massively, look at an iPhone for example. As such, this is exactly why the whole thread is revolving around ‘pixel’ (physical) vs pixel ‘virtual’ (as in the spec). The physical pixel is getting less and less reliable as monitor densities get higher and higher (a 15″ screen at 1920×1200 is at 128px/inch!).
Thinking of pt as mapping to an actual screen size just doesn’t work. You may specify 12pt (.16 inch if my math is good, which it might not be) but it’ll come out smaller on most screen these days.
So, even thinking of pt:px, it still wouldn’t be consistent. What we need is a device that can report it’s pixel density, calculate a virtual pixel that fits our expected 72dpi, and render to that auto-scaled. That’s the only way we’ll ever get px to map accurately to pt.
@Matt Wilcox
Not sure if we’re really on topic anymore, but it’s an interesting discussion anyway: I’m not arguing your points on the meaning of physical measurement units, but I don’t think you get what I mean to say… I didn’t mean that one should hold up a ruler and expect to get 72 pixels an inch on their monitor. It’s the intended size that matters, and it’s always going to be relative to the device.
Of course we have smaller pixels on smaller devices. We expect the content to be rendered smaller there: a visual (imagined) “inch” on your iPhone is smaller so you can fit a reasonable page on the screen.
Of course we want higher resolution, even on larger devices. And yes, we’ll have to adjust for that, but with your 128ppi monitor for example, you currently expect everything to be smaller as it is with all UI elements. Things like res-independent UI (Mac is edging closer to it) and browser page zoom (IE has it) will factor in to take care of this.
Practically speaking, though…
There’s an internal discrepancy in CSS… when we say “px” we mean fundamentally different things whether we’re addressing text or boxes. They behave differently, and this creates a problem when you need to have relative scaling between elements.
There’s no unit in CSS that behaves as I described above. Instead of adding and subtracting relative percentages from parent elements, it would sure be nice to have an absolute unit like “px”, but which also scales consistently with all page elements and text.
I suggested “pt” could fit the bill. Take this measurement to mean what you will, but to me its essential size on screen is the period in body copy text. Today, that practically means one pixel. It may change eventually, but at least it should be internally consistent unlike CSS’s “sometimes scalable” px spec.
It makes no sense. You talk about accessibility? The visually impaired people can read just fine with zooming features that come with operating systems. They prefer the zooming feature over making the fonts bigger than other elements because it makes the web design look more consistent and remember, they are pretty capable of reading or listening with proper tools.
It’s amazing that the deaf is still the most ignored – audios… videos are popular but captioning and transcriptions are scarce and there are NO tools that allow the deaf to read what they are saying. I am deaf myself and it’s irritating to read comments like that as if the blind is helpless and cannot access your website. They CAN as long as you use proper html/css. If you’re designing visually, don’t expect the blind to be wow’d. They probably won’t. They’re more focused on content than visual presentation. Just be sure they get the content they need.
So, I believe that the font should not be allowed to resize if other elements remain the same sizewise. I like IE7′s Zooming feature – which basically zooms ALL elements, not just text. Of course, that was Opera’s first.
I agree a bug – but I remember you saying in you Bulletproof book to set the font size to small globally then set font size as needed using %’s.
You almost gave the impression that it was not a good idea to use px, for accessibility reasons.
But I guess if browsers didn’t behave erratically we needn’t address the issue of how we size fonts anymore?
The answer can be found here: http://www.joelonsoftware.com/items/2008/03/17.html
It’s a pretty long read, but it explains why they make such decisions. It’s all business, folks =) Microsoft will be damned if they followed the spec, damned if they don’t.