meyerweb.com

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

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.

10 Responses»

    • #1
    • Comment
    • Mon 15 Feb 2010
    • 1042
    Jeff L wrote in to say...

    Wouldn’t line-height have the same issue, if you specify it without a unit? The inspector will report the computed value properly, but that’s not what is inherited down to its children. I think at some point, you have to simply focus on the fact that these tools are made for professionals, and we should have an understanding of what’s happening under the hood as well.

    • #2
    • Comment
    • Mon 15 Feb 2010
    • 1048
    Eric Meyer wrote in to say...

    That’s exactly the focus I’m trying to encourage, Jeff. And yes, you’re quite right about line-height.

    • #3
    • Comment
    • Mon 15 Feb 2010
    • 1328
    John Lascurettes wrote in to say...

    Wait. On line-height, if it’s unit-less, it’s not computing anything other than a relative multiplier, yes? So 1.2 would still be exactly a 1.2 multiplier to children and grandchildren wouldn’t it? It’s exactly “size * 1.2″ no matter what it’s applied to. Yes, there’s an issue of what is the font size of each element as its calculated vs. how it’s rendered; but however the browser is calculating that value, the multiplier for line height will always be 1.2.

    In the case of a fixed height calculated on an ancestor, 1.2em for example, that would be calculated once (and rounded or not depending on browser-OS combination) and applied as a fixed value to each descendant as the same length, regardless of that element’s font size, would it not?

    • #4
    • Comment
    • Mon 15 Feb 2010
    • 1531
    Eric Meyer wrote in to say...

    That’s right, John. I haven’t directly tested this but I will predict with a high degree of confidence that body {line-height: 1.5;} will never be reported as a unitless computed value on any element. I’ll also predict with a slightly lesser degree of confidence that the reported value will be an integer in Safari and Opera even when simple math tells us it can’t be an integer.

    • #5
    • Comment
    • Mon 15 Feb 2010
    • 1611
    ben wrote in to say...

    …So I’m starting to build the product site for http://oreilly.com/catalog/9780596157616/ (out on the first of March, with a shout-out to you in the Acknowledgements) and one of the big pieces for that site is to be a progressive look at inspectors. I’m glad you brought this up, because it’s just the sort of thing that I would’ve mentioned in the book had I not decided to save inspectors for the product site. So, um, thanks again.

    • #6
    • Pingback
    • Tue 16 Feb 2010
    • 0630
    Received from Some links for light reading (16/02/10) | Max Design

    […] Inspector Scrutiny […]

    • #7
    • Pingback
    • Tue 16 Feb 2010
    • 0936
    Received from Things I Found Interesting Around February 15th | Chris Coyier

    […] Inspector ScrutinyThis particular “bug” doesn’t worry me all that much, but I wonder how many other things are incorrectly reported in a tool like Firebug. My guess is not much. I think a cool Firebug feature would be to somehow indicate which DOM values are likely to be inconsistent across browsers. […]

    • #8
    • Comment
    • Sat 20 Feb 2010
    • 1111
    sanbor wrote in to say...

    Eric, I like the article, but in Firebug I see all right. Here is the screenshot http://www.twitpic.com/14c92i

    • #9
    • Comment
    • Sat 20 Feb 2010
    • 2333
    Eric Meyer wrote in to say...

    Those aren’t the computed styles, sanbor.

    • #10
    • Comment
    • Sun 21 Feb 2010
    • 1550
    Chris Hester wrote in to say...

    To me, the “computed style” means “the style the browser needs to display the correct number of pixels”. Correct me if I’m wrong. Therefore “medium” is meaningless to the browser until it computes it into pixels. Therefore any inspector that shows us the computed style won’t show “medium” but whatever that computes to, eg: “16px”.

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


February 2010
SMTWTFS
January April
 123456
78910111213
14151617181920
21222324252627
28  

Sidestep

Feeds

Extras