meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: 'Web' Category

In Defense of Vendor Prefixes

…that having been the original working title for “Prefix or Posthack“, my latest article for A List Apart.  (Sort of like Return of the Jedi had a working title of Blue Harvest.)  In a fairly quick read, I make the case that vendor prefixes are not only good, they have the potential to be great and to deliver greater interoperability and advancement of CSS.

So far the reaction has been overwhelmingly positive, which frankly came as a bit of a surprise.  The annoyance factor of prefixes is undeniable, and it’s been my experience that annoyance dramatically hardens opposition regardless of whether or not there are good reasons to oppose.  I could flatter myself that the agreement is due to the Obvious Rightness of my argument, but I suspect it’s actually that I merely articulated what most people had already instinctively decided for themselves.  Which isn’t a bad place to be.

Anyway, if you haven’t already, feel free to decide for yourself by reading the article—which, I feel like mentioning for no clear reason, is only the fourth piece I’ve ever written for ALA.

App Shopping

While I agree with Neven Mrgan’s Walled Gardens, I feel like the whole imagery of walled gardens is a bit of a metaphorical stretch—not because it’s inaccurate, but because it’s fundamentally unnecessary.  We don’t need metaphors here.

That’s because the iTunes App Store is just what its name states: it is a store.  That has a fairly specific and intentional meaning in the world of commerce.  It means that the stock is not infinite and that someone has screened it.

Think of visiting a store in the real world.  Not a small shop, but a store.  Something large (or at least largish) with lots of things to buy.  Macy’s.  Target.  Wal-Mart.  Or even the local hardware and general store in a small town, where there’s more than just tools and nails and bags of cement mix.

You go there to buy things because it’s a central location for buying a lot of things.  But inherent in the experience is that what you find on the shelves has been selected and vetted by the person or people running the store.  That doesn’t just mean favoring one brand of soap over another, but also deciding what to carry at all.  Your hardware store doesn’t sell flat-panel HDTVs.  Macy’s doesn’t stock six-inch PVC pipe.  Target doesn’t offer porn.  They have all selected some things to carry and rejected, if only implicitly, others.  Certain brands are not carried because their quality didn’t meet the proprietor’s standards, didn’t fit the store’s audience and brand, or weren’t sufficiently profitable to claim valuable shelf space.

This is an assumption about stores that we hardly notice except when it’s clearly not so.  If you’ve ever stepped into a store where it’s fairly obvious that everything, and I mean everything, the owner has ever come across in their life has been thrown onto the shelves on the theory that hell, it might look like junk but you never know what might be valuable to somebody, and you know what I mean.  We subconsciously expect that a store will offer wares which have been screened for quality and price, all conveniently collected in one place for our purchase.

So it is with the App Store.  It’s a central location for iPhone and iPad owners to go shop for apps.  The stock is large—too large for any physical store to handle—but it is still screened.  You may not like the screening criteria, just as you may not like the screening criteria exercised at Wal-Mart, but it exists nonetheless.

In the desktop computing world, of course, no such control exists.  There you find and collect applications wherever you find them, whether in a store or somewhere on the internet.  This is much the same as doing your shopping by driving around to garage sales and flea markets.  Taken as an aggregate, there’s no quality control, no screening, no organization.  It’s catch as catch can.

There’s room in the world for both models, of course.  Some people avoid stores in favor of flea markets and yard sales and the like because that’s what they prefer.  Others go to stores and avoid garage sales because they prefer the more controlled experience.  In fact, think about everyone you know.  How many prefer store shopping, and how many prefer flea market shopping?  In that light, the iTunes Store’s success is really no mystery.  It’s not just curated computing, which some have derided.  It’s curated shopping, a model which has already proven wildly popular.  More than that, it’s simple and cheap curated shopping, which is approximately the square of two wildly popular models.

You may say that there’s a significant difference between the physical world and the iTunes App Store.  If the real world were like iPhone/iPad ecosystem, there would only be one store in the whole world.  Everyone would have to shop there, and any merchant who couldn’t get in would be out of business for lack of customers.  In the real world, we can go to any store we like:  each is curated, but we can shop at the stores that offer what we like (read: that curate in a manner we find pleasing) and not the ones that don’t.  The App Store is the only place to shop.

But that’s only true if you believe that the iPhone/iPad is the only mobile ecosystem in town, which is an assumption a weirdly large number of Apple’s critics seem to make.  In fact, you’re perfectly free to join other ecosystems and shop at other stores.  Android has one, for example.  There are others.  If you don’t like what Apple offers you, then you can shop somewhere else, as many people do.

But let’s assume that you’re personally invested in the iPhone/iPad ecosystem and can’t for some reason avoid or leave it.  In that case, you’re stuck with that one single store, the App Store.

Except that’s only true because until now, nobody has launched an alternate store that offers web stack applications (WSAs).  Maybe that’s because nobody is really building WSAs yet, at least not in numbers large enough to justify building a store to sell them.  But then, maybe developers aren’t building WSAs because there’s no central place to sell them.  The centralization of stores is at least as attractive to sellers as to shoppers.  That’s a driver behind the recent announcements from Google and Mozilla, though as yet they’re just announcements.

A WSA store organized along lines similar to the App Store could do very, very well.  It would need to make the shopping and, more importantly, purchasing experiences as frictionless as possible; this is something the iTunes Store has definitely gotten right.  But suppose someone built a great WSA store and sold WSAs on a 20% commission.  How many developers might look at that and figure that the extra 10% was worth making a shift?

It certainly wouldn’t be as easy as just setting up a store and building a Scrooge McDuck vault; no, there would be many challenges, but nothing truly insurmountable.  Of that I am certain.  And the great thing is that, just like in the physical world, there’s room for multiple stores—boutique app shops, if you like.  Maybe one specializes in games; another in parent- and kid-centric apps; another in productivity apps; yet another in the “naughty” apps Apple booted out of its ecosystem a while back.  (I call them “fapps” for obvious reasons.)  Maybe these are app shops instead of app stores, but then, any large population can support a whole lot of shops.  They can coexist with any number of other stores, including those from Apple and Google and Mozilla and anyone else.

None of these WSA stores and shops would be able to sell native apps, but that’s less of an obstacle than many seem to think.  The window between native app behavior and WSA behavior has narrowed at an astonishing rate recently, and will continue to do so.  I’m not saying that you can do absolutely anything with a WSA that you can do in native code, of course, but a lot of native apps could have been done as WSAs.  Could still be done that way, in fact.

That points to the other advantage of a WSA store: it’s not limited to the iPhone/iPad ecosystem.  A well-written WSA can run in multiple ecosystems.  Being based on web technologies, they can (for the most part) go where the web goes.  The market is suddenly much bigger than the iTunes Store, much bigger than people carrying around Apple devices.  Much bigger than the people carrying around Droids, for that matter.  With WSAs, developers can sell in multiple ecosystems at once, using the most successful cross-platform technology since ones and zeros.

Besides which, in a very real sense, WSAs are not cross-platform apps.  They’re web platform apps that run in a native app that provides a window from a mobile ecosystem into the web.  We call that app a web browser, but it’s becoming more than that, and faster than many would have credited even six months ago.  The opportunities are beyond enormous.

For starters, imagine this: you have bought a number of apps at your favorite WSA store and installed them on your iPhone.  Then you find out you can finally get the hell off AT&T and move to a Verizon iPhone.  When you do that, the WSA store lets you install the apps you’ve already bought on your new ViPhone.  If it’s sufficiently smart, it will even migrate their data for you by way of the store itself.  Then, two years later, you decide you’ve had enough of Apple and want to move to another smartphone.  Once again, your apps and data go with you.

This is what the web stack makes possible.  If you thought mobile number portability was cool, imagine what you’ll think of mobile app portability.

The Web Stack

Following on my “HTML5 vs. Flash” talk of a couple of weeks ago, I’m hoping to do a bit of blogging about HTML5, Flash, mobile apps, and more.  But first I need to get some terminology straight.

As I did in my talk, I’m going to refer to the collection of front-end web-standards technologies—(X)HTML (of any flavor), CSS, and JavaScript—as “the web stack”.  I’ve seen the term used here and there and it makes the most sense to me as a condensed verbal shorthand.  It beats writing out the specific technologies every time or trying to use similarly clumsy constructions like “front-end tech”.  If you like, think of “web stack” as a rough equivalent to “Ajax”—a term that was invented because continually saying “asynchronous JavaScript + CSS + DOM + XMLHttpRequest” was unworkable.

The web stack sort of includes downloadable fonts, but only in the same sense that images or any other external resource is part of the stack.  SImilarly, it encompasses frameworks like jQuery in the sense that they’re built out of the components of the web stack.

When I use the term “web stack”, though, I’m not referring to back-end technologies.  Those things are important, certainly, but not from the front-end point of view.  A browser doesn’t care if your page was generated by PHP, Django, Rails, Perl, or what have you.  It doesn’t even care if the server runs on Apache or something else.

Furthermore, it doesn’t refer to plugins.  Yes, that means Flash, but it also means QuickTime, Real, ActiveX, and so forth.  What I need to make clear is that I’m not doing this in an attempt to imply that plugins don’t belong on the web at all.  They’re just not part of that core web stack any more than the web stack is part of them.  That doesn’t stop them working together, obviously.

Okay, so that’s out of the way, and I hope my meaning is sufficiently clear to everyone.  Please do leave a comment if it isn’t.  Onward!

Web 2.0 Talk: HTML5 vs. Flash

Earlier this week I presented a talk at the Web 2.0 Expo titled “HTML5 vs. Flash: Webpocalypse Now?” which seemed to be pretty well received.  That might be because I did my best to be unbiased about the situation both now and into the future, and also that the audience was very heavily weighted toward web stack practitioners.  Seriously, out of 100-150 audience members, about six raised their hand when I asked who was developing with Flash.

Many people have asked if the slides will be available.  Indeed so:  head on over to the session page, which I encourage attendees of the talk to visit so that you can leave a rating or comment on the session.  The 5.4MB PDF of my Keynote slides is available there whether you attended or not.

While I was at the conference I was also interviewed by Mac Slocum on the topics of the HTML and Flash, and that’s been put up on YouTube along with interviews with Brady Forrest and Ge Wang (both of whom are awesome).  I haven’t watched it so I don’t know how dorky I come off but I’ll bet it’s pretty dorky.

I indulged in a little good-natured ribbing of Adobe at the front of the interview (I kid because I love!) but the rest of it is, as best I recall, a decent distillation of my views.  I’m hoping to get a few more detailed thoughts written and published here in the next week or two.

Many thanks to Brady Forrest and the entire Web 2.0 crew for having me on stage and getting me out to San Francisco.  It’s always a great place to visit.

Seeking Hosting Advice

A friend and I have decided to build a web service/site/whatever the kids are calling them these days.  A thing on the web to help you out from time to time.

As a result, we’re looking for a web host with great service, reliability, and scalability, and I was curious about your experiences.  Here are a few details on what we need:

  • A managed server where patches are applied automatically.  Neither of us are Linux experts, and we want something secured for us without us having to worry about whether some patch breaks the system. 
  • mySQL with phpMyAdmin.  (Don’t judge.)
  • PHP w/cURL, mySQLi, and mCrypt, as well as an editable php.ini file.
  • Apache!
  • Some sort of CVS (Subversion and the like) built in.
  • Bonus: some experience on the hosting side with the ability to escalate to Memcached and other noSQL techniques.

The mySQL and PHP bits are of course incredibly common, but still, no point not mentioning those requirements.  In our case, the bigger issue is really “Who can we trust to provide support for what may turn out to be a reasonably large-scale service?”  So the features aren’t nearly as important as the reliability and trust.

Thus: what say you, friends?  Who rates as a great place to plant a web service seed that could one day grow into a mighty forest?  Let me know!

Inspector Scrutiny

It’s been said before that web inspectors—Firebug, Dragonfly, the inspectors in Safari and Chrome, and so forth—are not always entirely accurate.  A less charitable characterization is that they lie to us, but that’s not exactly right.  The real truth is that web inspectors repeat to us the lies they are told, which are the same lies we can be told to our faces if we ask directly.

Here’s how I know this to be so:

body {font-size: medium;}

Just that.  Apply it to a test page.  Inspect the body element in any web inspector you care to fire up.  Have it tell you the computed styles for the body element.  Assuming you haven’t changed your browser’s font sizing preferences, the reported value will be 16px.

You might say that that makes sense, since an unaltered browser equates medium with “16”.  But as we saw in “Fixed Monospace Sizing“, the 16px value is not what is inherited by child elements.  What is inherited is medium, but web inspectors will never show you that as a computed style.  You can see it in the list of declared styles, which so far as I can tell lists “specific values” (as per section 6.1 of CSS2.1).  When you look to see what’s actually applied to the element in the “Computed Styles” view, you are being misled.

We can’t totally blame the inspectors, because what they list as computed styles is what they are given by the browser.  The inspectors take what the browser returns and prettify it for us, and give us ways to easily alter those values on the fly, but in the end they’re just DOM inspectors.  They don’t have a special line into the browser’s internal data.  Everything they report comes straight from the same DOM that any of us can query.  If you invoke:

var obj = document.getElementsByTagName('body')[0];
alert(getComputedStyle(obj,null).getPropertyValue('font-size'));

…on a document being given the rule I mentioned above, you will get back 16px, not medium.

This fact of inspector life was also demonstrated in “Rounding Off“.  As we saw there, browsers whose inspectors report integer pixel values also return them when queried directly from the DOM.  This despite the fact that it can be conclusively shown that those same browsers are internally storing non-integer values.

Yes, it might be possible for an inspector to do its own analysis of properties like font-size by checking the element’s specified values (which it knows) and then crawling up the document tree to do the same to all of the element’s ancestors to try to figure out a more accurate computed style.  But what bothers me is that the browser reported computed values that simply aren’t accurate in the first place.  it seems to me that they’re really “actual values”, not “computed values”, again in the sense of CSS2.1:6.1.  This makes getComputedStyle() fairly misleading as a method name; it should really be getActualStyle().

No, I don’t expect the DOM or browsers to change this, which is why it’s all the more important for us to keep these facts in mind.  Web inspectors are very powerful, useful, and convenient DOM viewers and editors, essentially souped-up interfaces to what we could collect ourselves with JavaScript.  They are thus limited by what they can get the browser to report to them.  There are steps they might take to compensate for known limitations, but that requires them to second-guess both what the browser does now and what it might do in the future.

The point, if I may be so bold, is this:  never place all your trust in what a web inspector tells you.  There may be things it cannot tell you because it does not know them, and thus what it does tell you may on occasion mislead or confuse you.  Be wary of what you are told—because even though all of it is correct, not quite all of it is true, and those are always the lies that are easiest to believe.

Fixed Monospace Sizing

Monospace text sizing is, from time to time, completely unintuitive and can be quite maddening if you don’t look at it in exactly the right way.  Fortunately, there is a pretty simple workaround, and it’s one you might want to consider using even if you weren’t aware that a problem existed.

But first, allow me to lay some foundations.  Assuming no other author styles beyond the ones shown, consider the following:

span {font-family: monospace;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>
All right, what should be the computed font-size of the span element?  Remember, there are no other author styles being applied.

The savvier among you will have said: “It depends, but most likely 13px.”  That’s because here, the size of the monospace text is controlled by the browser’s preferences.  The vast majority of users, of course, have never touched their default settings of “16” for proportional fonts and “13” for monospace/fixed fonts.  For them, then, the answer is 13px.  Similarly, if I’d asked about the p element’s computed font-size, the answer would be: “It depends, but most likely 16px.”

So let’s add a bit more and see where we land.

span {font-family: monospace; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

As before: bearing in mind that there are no other author styles, what should be the computed font-size of the span element?

In this case, building on the previous question and answer, you might say, “It depends, but most likely 16px.”  The reasoning here is pretty straightforward:  since the computed font-size of the p element is 16px, the font-size: 1em; assigned to the span will result in it having the same size.

And that’s true… in two of five browsers I tested: Opera 10 and Internet Explorer 8.  In the other three I tested—Firefox 3.6, Safari 4, and Chrome 4—the computed (and rendered) font-size of the span is 13px, the same as in our first example.  This result holds true if the rule is changed to use font: 1em monospace; instead of the two separate properties.  The behavior continues to persist even when adding specific font families, like Courier New, Courier, Andale Mono, and so on to the rule.  It also persists if 1em is converted to 100%.

So in other words, even though I have written CSS that explicitly says “Make the font-size of this element the same as its parent”, three of five browsers apparently ignore me.

I say “apparently” because what’s happening is that those browsers are allowing the span to inherit the default font-size from its parent (and thus, indirectly, all its ancestors), but the default font-size is medium.  If you go look up medium, you find out that it doesn’t have a defined numeric size. So what those browsers do is equate medium with the preference settings, which means it’s different for monospace fonts than for everything else.

In other words, those three browsers are doing something like this:

  1. This span needs to have the same font-size as its parent element.
  2. The parent’s font-size is medium, even though when my web inspector (or an author’s DOM script) asks, I report the 16px I used to output the text.  So the span‘s font-size is actually medium.
  3. This medium-sized span is using a monospace font.  The preference setting for monospace is “13”, and I equate medium with the preference setting, so I’ll output the span using 13-pixel text.

Opera 10, as I said, doesn’t do this, even if your monospace font preference setting is the default value of “13” or indeed different from the preference for non-monospace fonts.  And IE8 doesn’t appear to do it either, although you can’t set numeric font size preferences in IE8 so what it’s actually doing is open to interpretation.  Oh, IE8, you inscrutable little scamp, you.

All that might seem reasonable enough, but it turns out that’s not the whole story.  No, the three resizing browsers are being a good deal more “clever”, if that’s actually the word I want, than that.  In fact, what those browsers do makes it seem like they use the two preference settings to create a ratio, and that ratio is used to scale monospace text.  That’s not actually what’s happening, but it looks that way at first.  To see what I mean, let’s consider:

span {font-family: monospace; font-size: 2em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

Again: in the absence of other author styles, what should be the computed font-size of the span element?

The answer: “It depends, but most likely 26px as long as we aren’t talking about Opera 10 or IE8.  If it is one of those two, then most likely 32px.”  Why?  Because the resizing browsers see the font-size: 2em; declaration as “twice medium” and twice 13 is 26.  Opera 10 and IE8, as previously established, don’t do the resizing.  Or else they simply interpret medium as being equal to the proportional font size preference setting.  Whatever.

Okay.  So what all this means is that in many browsers, you can declare that an element’s font size should be twice the size of its parent’s and have it actually be 1.625 times the size—or, if you want to look at it another way, 0.8125 times the size you expected it to be.  The 0.8125 comes from 26/32, which of course reduces to 13/16.  If you were to adjust your browser’s preferences so the monospace setting is “15”, then monospace fonts would be 0.9375 (15/16) times the expected size.

But—and here’s where things get really fun—this is not always so.  See, you may not have run into this problem if you’ve been declaring specific font families with no generic fallback.  Consider this variation (note that I dropped back to 1em for the font-size):

span {font-family: "Courier New"; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

This time, in every one of the five browsers I mentioned before, assuming the browser defaults, the computed (and rendered) font-size of the span will be 16px.  Not 13px.  And the only difference is that we switched from a generic font family to a specific one.

“Hey presto!” you shout.  “We’ll just tack the generic family on the end there and be right as rain!”  Sadly, no.  For if you do this:

span {font-family: "Courier New", monospace; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

…then the answer to the question I keep asking will be:  “It depends, but given browser defaults it will be 16px, unless we’re talking about Safari.  In that case, it’s 13px.”

Really.  Alone among the browsers I tested, Safari goes back to doing the resizing when you provide a generic fallback to your specific family.  Or even multiple families.  Do your best to make sure the user at least gets a fixed-width font, and you get a size smaller than you’d intended.  (You can get the back story on this in a late-2006 post on the Surfin’ Safari blog.)

So what do we do?  Get creative.  That’s what the ARIA folks did in their specification’s style sheet, where they declare two font stacks: the first with a generic fallback, and the second without it.  That works, but it’s ugly.  I didn’t like that at all.  And then, halfway through writing up this post, a fix came to me like a shot in the dark.  Check this out:

span {font-family: "Courier New", monospace, serif; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

This time around, the answer is:  “It depends, but given browser defaults, 16px.”

Really!  Even in Safari!  And in all tested browsers, it falls back to a generic monospace font at the requested size even if the specific family (or families) we declare aren’t available!  This can be verified by altering the specific font family to something that doesn’t actually exist:

span {font-family: "Corier Neu", monospace, serif; font-size: 1em;}

<p>This is a 'p' with a <span>'span'</span> inside.</p>

Monospacey goodness at the intended, parent-matching size.  It’s enough to make a body believe in monotheism.

Since I generally assume that anything I devise was already invented by someone else, I went Googling for prior art.  And wouldn’t you know it, the Wikipedia folks had worked it out around the end of last year.  This, of course, supports my contention that Wikipedia is the new Steve Allen.  I also found some claims that ending the font stack with monospace, monospace would have the same effect, but that wasn’t borne out in my testing.  Perhaps it worked in older versions of browsers but no longer does.

I did leave out another way to make monospaced fonts behave as expected, which you may have already figured out from the preceding: declare the font-size for any parent of a monospaced element to be a length value, along the lines of body {font-size: 12px;}.  That will pass the length value down the document tree to the monospaced element via inheritance, which will use it without resizing it in every browser I tested.  Though you may have heard that page zooming makes pixel-sized text okay, I’m not really convinced.  Not yet.  There are too many people who don’t know how to zoom, and too many whose browsers aren’t advanced enough to zoom pages.  Even in page-zooming browsers, there are problems with pixel text.  So I’m still on the ems-and-percentages bandwagon.

In fact, there are a fair number of details and extra browser oddities that I left out of this, as it’s already way more than long enough, and besides you don’t really want to hear the gory details of manually stepping through 37 different preferences settings just to verify a theory.  Plus you already heard about the font-size rounding investigation that spawned off of this one, about halfway through.  I think that’s more than enough for the time being.

I should also lay down a caveat: it’s possible that this behavior will be interpreted as a bug by the Safari team and “fixed”, if that’s the word I want, in a future release.  I really hope not—and if they’re looking for ways to improve how they handle monospace font sizing, I have a few suggestions—but it is possible.  Adjust your expectations accordingly.

And with that, I’m going to stop now.  I hope this will be useful to you, either now or in the future.

Rounding Off

In the course of digging into the guts of a much more complicated problem, I stumbled into an interesting philosophical question posed by web inspection tools.

Consider the following CSS and HTML:

p {font-size: 10px;}
b {font-size: 1.04em;}

<p>This is text <b>with some boldfacing</b>.</p>

Simple enough.  Now, what is the computed font-size for the b element?

There are two valid answers.  Most likely one of them is intuitively obvious to you, but take a moment to contemplate the rationale for the answer you didn’t pick.

Now, consider the ramifications of both choices on a situation where there are b elements nested ten layers deep.

If you hold that the answer is 10px, then the computed font-size of the tenth level of nesting should still be 10px, because at every level of nesting the mathematical answer will be rounded down to 10.  That is: for every b element, its computed font-size will be round(10*1.04), which will always yield 10.

If, on the other hand, you hold that the answer is 10.4px, then the computed font-size of the tenth level of nesting should be 14.802442849px.  That might get rounded to some smaller number of decimal places, but even so, the number should be pretty close to 14.8.

The simplest test, of course, is to set up a ten-level-deep nesting of b elements with the previously-shown CSS and find out what happens.  If the whole line of text is the same size, then browsers round their computed font-size values before passing them on.  If the text swells in size as the nesting gets deeper, then they don’t.

As it happens, in all the browsers I’ve tested, the text swells, so browsers are passing along fractional pixel values from level to level.  That’s not the interesting philosophical question.  Instead, it is this:  do web inspectors that show integer font-size values in their ‘computed style’ windows lie to us?

To see what I mean, load up the font size rounding test page in Firefox and use Firebug to inspect the “1(“, which is the first of the b elements, in the first (1.04em) test case.  Make sure you’re looking at the “Computed Styles” pane in Firebug, and you’ll get a computed font-size of 10.4px.  That makes sense: it’s 10 × 1.04.

Now try the inspecting that same “1(” in Safari or Opera.  Both browsers will tell you that the computed font-size of that b element is 10px.  But we already know that it’s actually 10.4px, because the more deeply-nested layers of b elements increase in size.  These inspectors are rounding off the internal number before showing it to us.  Arguably, they are lying to us.

But are they really?  The reason to doubt this conclusion is that the values shown in those inspectors accurately reflect the value being used to render the characters on-screen.  To see what I mean, look at the last example on the test page, where there’s sub-pixel size testing.  The “O” characters run from a flat 10 pixels to a flat 11 pixels in tenths (or less) of a pixel, all of their font-sizes assigned with inline style elements to pin the characters down as much as possible.  In Safari, you can see the size jump up one pixel right around the text’s midpoint, where I wrote font-size: 10.5px.  So everything from 10px to 10.49px gets drawn at 10 pixels tall; everything from 10.5px to 11px is 11 pixels tall.  Safari’s inspector reflects this accurately.  It’s telling you the size used to draw the text.

A comparative illustration of the many-O test case in three different browsers showing three different results.  The browsers used to create the illustration were Safari, Opera, and Firefox.

In Opera 10.10, you get the same thing except that the jump from 10 to 11 pixels happens on the very last “O”, both visually and in the inspector (Dragonfly).  That means that when it comes to font sizes, Opera always rounds down.  Everything from 10px to 10.9px—and, presumably, 10.99999px for as many nines as you’d care to add—will be drawn 10 pixels tall.  Brilliant.

In Firefox for OS X, there’s no size jump.  The “O” characters look like they form a smooth line of same-size text.  In fact, they’re all being drawn subtly differently, thanks to their subtly different font-size values.  If you use OS X’s Universal Access screen zooming to zoom way, way in, you can see the differences in pixel shading from one “O” to the next.  Even if you don’t, though, the fact that it’s hard to tell that there is an increase in size from one end of the line to the other is evidence enough.

In Firefox for XP, on the other hand, the size jump occurs just as it does in Safari, going from 10 pixels to 11 pixels of text size at the 10.5 mark.  But Firebug still reports the correct computed font-size values.  Thus, its reported value doesn’t match the size of the text that’s been output to the screen.  Arguably, it’s lying just as much as Safari and Opera,  in a different way.

But, again: is it really?  The computed values are being accurately reported.  That there is a small variance between that fractional number and the display of the text is arguably irrelevant, and can lead to its own confusion.  Situations will arise where apparent rounding errors have occurred—I see people complain about them from time to time—when the apparent error is really an artifact of how information is delivered.

I have my own thoughts about all this, but I’m much more interested in the thoughts of others.  What do you think?  Should web inspectors report the CSS computed values accurately, without regard to the actual rendering effects; or should the inspectors modify the reported values to more accurately reflect the visual rendering, thus obscuring the raw computed values?

Addendum 10 Feb 10: I’ve updated the test page with a JS link that will dynamically insert the results of getComputedStyle(el,null).getPropertyValue("font-size") into the test cases.  The results are completely consistent with what the inspectors report in each browser.  This tells us something about the inspectors that most of us probably don’t consciously realize: that what they show us rests directly on the same JS/DOM calls we could write ourselves.  In other words, inspectors are not privileged in what they can “see”; they have no special view into the browser’s guts.  Thus another way to look at this topic is that inspectors simply repeat the lies that browsers tell the world.

December 2014
SMTWTFS
November  
 123456
78910111213
14151617181920
21222324252627
28293031  

Archives

Feeds

Extras