Scott, definitely this technique will become a standard. Making websites that adapt perfectly to every device and situation is growingly challenging. I just finished a couple of responsive websites and got to say that my bills are going to grow a lot for this.
As I said, this techinque will become mandatory, but will also add a lot of work, especially when editing a complex website’s css to second customer’s requests. The days of pre-settled website costs are over.
This can cause problems on smaller devices where you may want to viewport to equal the device width. On phones, everything would shrink down to fit the viewport and on larger screens things would need to scale up. However, if you are targeting devices on the server side this can be a great solution that will even override the users scale settings. Sending something to a user that is that rigid can cause plenty of usability issues though, so be careful if that is the path you take.
Hopefully it doesn’t add too much to your development time. This is really an argument to use relative units like em, rem, and percent instead of px, in, pt and so on. If you are finding yourself going back to make core adjustments to your CSS later in a projects development I recommend using a CSS precompiler like Sass.
In my point of view websites are built in the present to facilitate the future. Take ALA for example, with a design that has lasted for quite a few years it is facilitating game changing articles like responsive design. While it does not implement these new ways of thinking it does its job wonderfully. There is no point in killing yourself keeping legacy sites current, instead build it the best you can the first time around. I am trying to keep a normalization list up to date here: https://github.com/scottkellum/pixel-normalization. It should be a matter of copy/paste to keep up to date.
Hm, ok, so I follow, but unfortunately I don’t have multiple devices to fully grasp and experiment with. So I guess my question is, how important is its application, and when/how do we apply it now?
I feel like responsive web design addresses a similar issue, accounting for different devices, except now this accounts for two devices, same screen size, different rendering. As a web designer, if I’m making my website responsive, and font size isn’t critical to layout or other structural issues, do I need to worry about this?
I feel like this is fine tuning that could be practical/helpful/important in certain circumstances, such as trying to get super small subtext and still making it readable across all devices, but for the most part, isn’t essentail to usability.
And, if it is important, can I cut and paste that gist and go about my way, or do I need to worry about more?
Very interesting topic, and thanks for laying it out!
Think about the last time you went to footlocker (or another shoe store). You see a pair of kicks you really like the look of, everything about them screams your personality so you ask the store clerk for a 9 to try on. When you get them, your right foot is snug but you can barely get the left one in at all before your toes hit the end.
You try the 10 only to find that it’s like trying to walk in two small rowing boats.
See the problem with shoe manufacturers is that they all interpreted a size 9 differently. The actual size itself is altered based on the contour of the shoe, the density of the soul, the stitching and so on. If that wasn’t enough of a headache, a US size 9 is actually a UK size 8 and a European 42!
Suddenly exactly the same product has 3 different measurement methods to be based upon along with the manufacturer’s interpretation of each of those fundamental measuring concepts.
Buying shoes is exactly the same as working with html/css layouts. We all have shoes on our feet today though, so we must have found a size and pair that suited us personally.
Pick the style, the materials and the measurement that suits with you and try them on, wear them to the club or kick back and watch TV in them, ultimately it really doesn’t matter how they got on your feet just that you feel comfortable in them.
I try to avoid absolutes, especially in the web design space. There are cases for and against almost every technique. This is more of an argument to use relative units like em and rem instead of absolutes like px and pt. As long as your layouts are defined in relative terms alterations are easy.
It is more important to normalize for responsive and fluid layouts that fit to the screen. Fixed layouts are always zoomed differently on touch devices anyways so they don’t need to really worry about this. Tablets are rapidly increasing in popularity and 7” tablets are one of the fastest growing areas while having some of the biggest issues with pixel scaling. “Usability studies show”:http://www.useit.com/alertbox/kindle-fire-usability.html that there are some major issues on these devices, the Nook suffers from them as well although the native UI is better designed for touch input. Because of these issues I have converted my frameworks to use this technique and have taken the time to refactor some older projects to use ems for pixel scaling. That said, I work on digital publications for the web so the kindle/nook market is a bigger deal for me than most people.
Yes, as long as you are using relative units everywhere you can cut and paste the gist and go about your way :)
I’m glad I’m not the only one who lacks appreciation for needlessly making coding more complex. I begin to long for the application of non-complicated standards, as Web Standards did for websites. But it is what it is.
Copy & paste the code below to embed this comment.
Richard Fink
I think the move to relative units like em is inevitable.
Too many screen sizes, too many resolution settings.
I don’t normally do web design – these days usually I work with web fonts. But when it comes time to put demo pages together, I realize more and more that no matter what I do, I’ve got invisible “partners” who are going to come along after I’m finished and secretly alter what I’ve done.
Device manufacturers, the OS, users – they all have just as much say in my design as I do. The difficulty is accepting this and making it work as an advantage, not a liability. It’s a big mental adjustment. A complete change in paradigm. It’s been coming for awhile, and now it’s arrived full blown with the proliferation of mobile devices. Until recently, there was still some semblance to the fixed media of print which has dominated for 500 years. But that’s all gone now. I don’t agree with the notion that screen sizes will eventually “boil down” to some reasonable, manageable number.
Some used to argue that it was best to view the CSS as a “suggestion” only. Now, it’s not even a suggestion. Just a beginning, a start – an offer. Nice article, thanks.
I’m really having trouble getting past the opening paragraphs of this article. Yes, the pixel is a unit of measurement. But you fail to specify what is being measured. What is the pixel a unit of? The answer has always been resolution, not size.
Consider the content being presented and not the hardware. A digital image that is 640 × 480px has no inherent size; it has only an inherent resolution—which helps us understand its size in quantitative and/or relative terms. (Which leads us to think we’re talking about size.)
This issue became crystal clear to me recently while studying bitmap fonts and font-rendering (aliasing, sub-pixel aliasing, anti-aliasing). A bitmap font is one that’s been designed based upon a particular grid; it has no inherent size but its resolution is clearly defined—which gives it very distinct limitations.
This is where pixels and points are worlds apart. Point is a true unit of size, being defined as 1/72 of an inch by modern standards. A point is always a point—in terms of its size—but its resolution is completely ambiguous. Point is a unit of size, without resolution. Pixel is a unit of resolution, without size.
There are two definitions of a pixel, one is the hardware pixel or the size of one unit on a physical screen, the other and w3c standard is a relative size based on a reference pixel.
How big is a pixel exactly according to the spec?
For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch).
That probably doesn’t give you a good idea as to how the unit behaves. So imagine looking up at the moon, then bringing your thumb up and covering the moon. Optically your thumb and the moon are the same size, but physically the moon is much larger than your thumb.
When dealing with font hinting and anti-aliasing you are altering how text falls across various hardware pixels, not reference pixels. A bitmap font scaled on some screens to the w3c standard of a pixel might have issues displaying properly. Using the method outlined in the article can work to fix this or using the method “described earlier in the comments”:http://www.alistapart.com/comments/a-pixel-identity-crisis/P10/#13 of using target-densitydpi=device-dpi might help with bitmap fonts.
I think it’s important that at least one of your definitions acknowledges content—not just the hardware or a W3C standard.
Fundamentally, pixels are descriptive of a grid-based or bitmap-style visual representation. The size of the grid is completely arbitrary. When talking about digital photos, we don’t talk about their physical dimensions, or the size of their pixel units, we talk about the number of pixels they contain. One of my points is that we commonly confuse that number with size. And I think that confusion runs wild in the web design and development world as well. We get used to pixels seeming a certain size, but they were never the size we presumed they were; they were just a quantity—a quantity that helped us assess relative size, dimensional ratio, and the limitations of a particular digital asset.
Unlike a vector object, a bitmap object (whether a photo or a bitmap font) has very specific limitations by virtue of its pixel dimensions. Those dimensions by no means represent the physical size of the object, only the resolution of the object.
Personally, I’d like everyone who reads this to repeat this mantra for one week: “Pixels are a unit of resolution, not size.”
In web design and development pixels are used as a unit of measure, not to describe content. Changing the resolution of a photo in the context of web design will change it’s size, not it’s refinement. This is because CSS is a presentation language that is usually used to describe elements on a screen with it’s own resolution. Because the resolution of screens are set, pixels of images and bitmaps are displayed at a 1:1 default ratio to that of the device making the unit of measure on the screen significant. Within this context, pixels are a unit of size that describe resolution, but not a unit of resolution. If we were discussing digital photography without the context of presentation formats then yes, pixels would be a unit of resolution, not size.
Copy & paste the code below to embed this comment.
kylew
I think Doug’s posts are helpful. Scott, the beginning of your response: “in web design and development pixels are used as a unit of measure” – I understand the point you’re making, but isn’t this exactly the problem? The “reference pixel” is an appropriate next step, but like others have said, the name isn’t great. How about lexip? I actually think its better to mentally abandon the whole idea of designing based on a little square unit. RWD gets us close. But there is still that default font size measured in pesky pixels. The last step is to define font size without pixels and be done with them. What if we could just directly define an em as a percentage of the viewing window? For example, we redefine em slightly as the area (not just length) that a capital M fits inside of, then define how big an em is in our documents, like 1/7500 of the area of the window. Essentially we would define our own “pixel.” I understand something similar is happening in the article when you change the base font size. But I like the idea of defining all sizes according to the screen real-estate, including the actual em.
See, the very fact the W3C has tried to ascribe a standard size to a pixel (or create a concept called a “reference pixel”) is indicative that the pixel has no inherent size. It’s ever-changing.
Yes, it’s a unit of measure—but of quantity, not size. I call this quantity “resolution” (you may call it “refinement”?) because it’s intimately connected to the level of detail that can be rendered by a grid-based representation. For example, a 4×4 pixel grid cannot render the detail that a 400×400 pixel grid can; it doesn’t have enough resolution.
Content is everything. It’s what designers and front-end developers work with. To any CSS designer:
If you’re using pixels to “size” content that is not a bitmap*—*such as a font, or an HTML element*—*reconsider what it is you’re really doing.
You’re saying to the browser, “Please map this to a grid of [this many] pixels”. In other words, you’re limiting or commiting that content to a particular grid-based resolution—in effect, asking the browser to treat it as a bitmap. Yes, you’ll get a relative size from this type of declaration—by tethering it to the other bitmap elements on the page—but there should be no expectation of an absolute size.
This is very different from using a unit like points. With points, you’re making an explicit statement of size only, with absolutely no commitment to a particular resolution.
Sorry if I’m repeating myself here. And my apologies if we’re using different terms. To me, this understanding of the pixel simplifies things greatly, in a way that adds clarity instead of complexity.
I would love it if the W3C adhered to this mantra and agree with kylew above that a new unit would be wonderful. Having pixels that don’t describe resolution is confusing and a new unit would be nice. However facts are facts which aren’t up for debate and the W3C has actually defined a pixel like this for a long time. Changing it now would cause a lot of problems.
Yes, I totally agree it isn’t the best solution but this is the problem and I proposed a solution in my article. The solution involves abandoning pixels and moving to ems or other relative units.
I read most of the commets but not all so sorry if this has already been mentioned and I missed it.
As you mentioned device-pixel-ratio is currently only supported within webkit and opera, I thought its worth mentioning that -o-device-pixel-ratio uses fractions rather than decimals like webkit.
Haven’t read through the entire comments, but just wondering why you used -device-pixel-ratio which needs to be prefixed rather than ‘resolution’ in your media queries? Seems to me you could be more accurate and less tied to specific device definitions by using resolution.
Also… to me your MQ for targeting the Kindle and the Tab are great in terms of a useful exercise, but are amazingly impractical for real-world development. It just shouldn’t be that hard.
Copy & paste the code below to embed this comment.
Mwahaha
Scott, Thanks for a good article.
But what does this sentence mean:“Devices usually give a height less than the actual device-height so to avoid 1024 × 768 tablets identifying those under 600 pixels tall will avoid those.”?
It’s not just grammatically gonzo, it’s actually totally unclear. I’ve read it over and over and I just don’t get it. Device height isn’t reported correctly? On which devices? Can you document/expand on this? You’re dropping a huge bomb here without any elaboration. I think we’d all be really interested to see a table of actual devices with their actual and media-query-reported dimensions, if such a thing exists.
Also, you make a sweeping (and I believe correct) generalization about how developers probably shouldn’t try to get locked into targeting specific devices, but instead classes of devices with different characteristics. But then you go on to specifically target two devices in the most narrow way possible. It’s philosophically “¦ baffling. Even for just these two devices, I’m left at the end of the article wondering which approach I should take to preserve reference pixel scale for typography across all devices. Scale up the Fire or scale down the Tab? I get the relativity of it all, but it would clarify a lot if a single position were taken.
@jameswillweb At the time, this was the most widely available tool at the disposal of developers. Resolution vs device-pixel-ratio is still under some amount of debate from what I have read, although the W3C seems to be settling on resolution. Time will probably provide more and better solutions and resolution is one of them, but the issue of unit discrepancies is a big one. Unfortunately the unit specs are, in my opinion, a mess. This is how I was taming a particularly annoying outliers at the time.
@Mwahaha Sorry for my gramatical mis-steps. I have always struggled with my writing. What that means is that devices rarely report the correct device height in pixels. Instead they report the height minus any browser chrome, so essentially the viewport height. Querying a lower number ensures that those devices are included.
These are just two devices I am using as examples. Many other devices in the 7” class of tablets are targeted with these queries, like the Nook, Viewsonic viewpad, ACME Android 7” “¦
@Mwahaha Also I did take a stance on what scale I prefer. I scaled both devices to the equivalent of 1.2. “From what I hear”:https://twitter.com/huafi/status/220941824955654144 , this is around the same scale as the Galaxy Nexus.
45 Reader Comments
Back to the ArticleRyan Cannon
It seems like a lot of this complexity could be avoided with
<meta name=“viewport” content=“width=640” />Suddenly all devices treat your pixels as the exact same percentage of the screen width. Isn’t this all we want?
fornace
Scott, definitely this technique will become a standard. Making websites that adapt perfectly to every device and situation is growingly challenging. I just finished a couple of responsive websites and got to say that my bills are going to grow a lot for this.
As I said, this techinque will become mandatory, but will also add a lot of work, especially when editing a complex website’s css to second customer’s requests. The days of pre-settled website costs are over.
Scott Kellum
Ryan,
This can cause problems on smaller devices where you may want to viewport to equal the device width. On phones, everything would shrink down to fit the viewport and on larger screens things would need to scale up. However, if you are targeting devices on the server side this can be a great solution that will even override the users scale settings. Sending something to a user that is that rigid can cause plenty of usability issues though, so be careful if that is the path you take.
Scott Kellum
fornace,
Hopefully it doesn’t add too much to your development time. This is really an argument to use relative units like em, rem, and percent instead of px, in, pt and so on. If you are finding yourself going back to make core adjustments to your CSS later in a projects development I recommend using a CSS precompiler like Sass.
In my point of view websites are built in the present to facilitate the future. Take ALA for example, with a design that has lasted for quite a few years it is facilitating game changing articles like responsive design. While it does not implement these new ways of thinking it does its job wonderfully. There is no point in killing yourself keeping legacy sites current, instead build it the best you can the first time around. I am trying to keep a normalization list up to date here: https://github.com/scottkellum/pixel-normalization. It should be a matter of copy/paste to keep up to date.
son0fhobs
Hm, ok, so I follow, but unfortunately I don’t have multiple devices to fully grasp and experiment with. So I guess my question is, how important is its application, and when/how do we apply it now?
I feel like responsive web design addresses a similar issue, accounting for different devices, except now this accounts for two devices, same screen size, different rendering. As a web designer, if I’m making my website responsive, and font size isn’t critical to layout or other structural issues, do I need to worry about this?
I feel like this is fine tuning that could be practical/helpful/important in certain circumstances, such as trying to get super small subtext and still making it readable across all devices, but for the most part, isn’t essentail to usability.
And, if it is important, can I cut and paste that gist and go about my way, or do I need to worry about more?
Very interesting topic, and thanks for laying it out!
Cheers!
Andy Parker
Think about the last time you went to footlocker (or another shoe store). You see a pair of kicks you really like the look of, everything about them screams your personality so you ask the store clerk for a 9 to try on. When you get them, your right foot is snug but you can barely get the left one in at all before your toes hit the end.
You try the 10 only to find that it’s like trying to walk in two small rowing boats.
See the problem with shoe manufacturers is that they all interpreted a size 9 differently. The actual size itself is altered based on the contour of the shoe, the density of the soul, the stitching and so on. If that wasn’t enough of a headache, a US size 9 is actually a UK size 8 and a European 42!
Suddenly exactly the same product has 3 different measurement methods to be based upon along with the manufacturer’s interpretation of each of those fundamental measuring concepts.
Buying shoes is exactly the same as working with html/css layouts. We all have shoes on our feet today though, so we must have found a size and pair that suited us personally.
Pick the style, the materials and the measurement that suits with you and try them on, wear them to the club or kick back and watch TV in them, ultimately it really doesn’t matter how they got on your feet just that you feel comfortable in them.
Scott Kellum
son0fhobs,
I try to avoid absolutes, especially in the web design space. There are cases for and against almost every technique. This is more of an argument to use relative units like em and rem instead of absolutes like px and pt. As long as your layouts are defined in relative terms alterations are easy.
It is more important to normalize for responsive and fluid layouts that fit to the screen. Fixed layouts are always zoomed differently on touch devices anyways so they don’t need to really worry about this. Tablets are rapidly increasing in popularity and 7” tablets are one of the fastest growing areas while having some of the biggest issues with pixel scaling. “Usability studies show”:http://www.useit.com/alertbox/kindle-fire-usability.html that there are some major issues on these devices, the Nook suffers from them as well although the native UI is better designed for touch input. Because of these issues I have converted my frameworks to use this technique and have taken the time to refactor some older projects to use ems for pixel scaling. That said, I work on digital publications for the web so the kindle/nook market is a bigger deal for me than most people.
Yes, as long as you are using relative units everywhere you can cut and paste the gist and go about your way :)
Diane Vigil
I’m glad I’m not the only one who lacks appreciation for needlessly making coding more complex. I begin to long for the application of non-complicated standards, as Web Standards did for websites. But it is what it is.
Richard Fink
I think the move to relative units like em is inevitable.
Too many screen sizes, too many resolution settings.
I don’t normally do web design – these days usually I work with web fonts. But when it comes time to put demo pages together, I realize more and more that no matter what I do, I’ve got invisible “partners” who are going to come along after I’m finished and secretly alter what I’ve done.
Device manufacturers, the OS, users – they all have just as much say in my design as I do. The difficulty is accepting this and making it work as an advantage, not a liability. It’s a big mental adjustment. A complete change in paradigm. It’s been coming for awhile, and now it’s arrived full blown with the proliferation of mobile devices. Until recently, there was still some semblance to the fixed media of print which has dominated for 500 years. But that’s all gone now. I don’t agree with the notion that screen sizes will eventually “boil down” to some reasonable, manageable number.
Some used to argue that it was best to view the CSS as a “suggestion” only. Now, it’s not even a suggestion. Just a beginning, a start – an offer. Nice article, thanks.
Doug Downing
I’m really having trouble getting past the opening paragraphs of this article. Yes, the pixel is a unit of measurement. But you fail to specify what is being measured. What is the pixel a unit of? The answer has always been resolution, not size.
Consider the content being presented and not the hardware. A digital image that is 640 × 480px has no inherent size; it has only an inherent resolution—which helps us understand its size in quantitative and/or relative terms. (Which leads us to think we’re talking about size.)
This issue became crystal clear to me recently while studying bitmap fonts and font-rendering (aliasing, sub-pixel aliasing, anti-aliasing). A bitmap font is one that’s been designed based upon a particular grid; it has no inherent size but its resolution is clearly defined—which gives it very distinct limitations.
This is where pixels and points are worlds apart. Point is a true unit of size, being defined as 1/72 of an inch by modern standards. A point is always a point—in terms of its size—but its resolution is completely ambiguous. Point is a unit of size, without resolution. Pixel is a unit of resolution, without size.
Scott Kellum
Doug,
There are two definitions of a pixel, one is the hardware pixel or the size of one unit on a physical screen, the other and w3c standard is a relative size based on a reference pixel.
How big is a pixel exactly according to the spec?
For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch).
That probably doesn’t give you a good idea as to how the unit behaves. So imagine looking up at the moon, then bringing your thumb up and covering the moon. Optically your thumb and the moon are the same size, but physically the moon is much larger than your thumb.
When dealing with font hinting and anti-aliasing you are altering how text falls across various hardware pixels, not reference pixels. A bitmap font scaled on some screens to the w3c standard of a pixel might have issues displaying properly. Using the method outlined in the article can work to fix this or using the method “described earlier in the comments”:http://www.alistapart.com/comments/a-pixel-identity-crisis/P10/#13 of using target-densitydpi=device-dpi might help with bitmap fonts.
Doug Downing
Scott,
I think it’s important that at least one of your definitions acknowledges content—not just the hardware or a W3C standard.
Fundamentally, pixels are descriptive of a grid-based or bitmap-style visual representation. The size of the grid is completely arbitrary. When talking about digital photos, we don’t talk about their physical dimensions, or the size of their pixel units, we talk about the number of pixels they contain. One of my points is that we commonly confuse that number with size. And I think that confusion runs wild in the web design and development world as well. We get used to pixels seeming a certain size, but they were never the size we presumed they were; they were just a quantity—a quantity that helped us assess relative size, dimensional ratio, and the limitations of a particular digital asset.
Unlike a vector object, a bitmap object (whether a photo or a bitmap font) has very specific limitations by virtue of its pixel dimensions. Those dimensions by no means represent the physical size of the object, only the resolution of the object.
Personally, I’d like everyone who reads this to repeat this mantra for one week: “Pixels are a unit of resolution, not size.”
Scott Kellum
Doug,
In web design and development pixels are used as a unit of measure, not to describe content. Changing the resolution of a photo in the context of web design will change it’s size, not it’s refinement. This is because CSS is a presentation language that is usually used to describe elements on a screen with it’s own resolution. Because the resolution of screens are set, pixels of images and bitmaps are displayed at a 1:1 default ratio to that of the device making the unit of measure on the screen significant. Within this context, pixels are a unit of size that describe resolution, but not a unit of resolution. If we were discussing digital photography without the context of presentation formats then yes, pixels would be a unit of resolution, not size.
kylew
I think Doug’s posts are helpful. Scott, the beginning of your response: “in web design and development pixels are used as a unit of measure” – I understand the point you’re making, but isn’t this exactly the problem? The “reference pixel” is an appropriate next step, but like others have said, the name isn’t great. How about lexip? I actually think its better to mentally abandon the whole idea of designing based on a little square unit. RWD gets us close. But there is still that default font size measured in pesky pixels. The last step is to define font size without pixels and be done with them. What if we could just directly define an em as a percentage of the viewing window? For example, we redefine em slightly as the area (not just length) that a capital M fits inside of, then define how big an em is in our documents, like 1/7500 of the area of the window. Essentially we would define our own “pixel.” I understand something similar is happening in the article when you change the base font size. But I like the idea of defining all sizes according to the screen real-estate, including the actual em.
Doug Downing
See, the very fact the W3C has tried to ascribe a standard size to a pixel (or create a concept called a “reference pixel”) is indicative that the pixel has no inherent size. It’s ever-changing.
Yes, it’s a unit of measure—but of quantity, not size. I call this quantity “resolution” (you may call it “refinement”?) because it’s intimately connected to the level of detail that can be rendered by a grid-based representation. For example, a 4×4 pixel grid cannot render the detail that a 400×400 pixel grid can; it doesn’t have enough resolution.
Content is everything. It’s what designers and front-end developers work with. To any CSS designer:
If you’re using pixels to “size” content that is not a bitmap*—*such as a font, or an HTML element*—*reconsider what it is you’re really doing.
You’re saying to the browser, “Please map this to a grid of [this many] pixels”. In other words, you’re limiting or commiting that content to a particular grid-based resolution—in effect, asking the browser to treat it as a bitmap. Yes, you’ll get a relative size from this type of declaration—by tethering it to the other bitmap elements on the page—but there should be no expectation of an absolute size.
This is very different from using a unit like points. With points, you’re making an explicit statement of size only, with absolutely no commitment to a particular resolution.
Sorry if I’m repeating myself here. And my apologies if we’re using different terms. To me, this understanding of the pixel simplifies things greatly, in a way that adds clarity instead of complexity.
Thanks for the responses!
Scott Kellum
I would love it if the W3C adhered to this mantra and agree with kylew above that a new unit would be wonderful. Having pixels that don’t describe resolution is confusing and a new unit would be nice. However facts are facts which aren’t up for debate and the W3C has actually defined a pixel like this for a long time. Changing it now would cause a lot of problems.
Yes, I totally agree it isn’t the best solution but this is the problem and I proposed a solution in my article. The solution involves abandoning pixels and moving to ems or other relative units.
GlynnPhillips
I read most of the commets but not all so sorry if this has already been mentioned and I missed it.
As you mentioned device-pixel-ratio is currently only supported within webkit and opera, I thought its worth mentioning that -o-device-pixel-ratio uses fractions rather than decimals like webkit.
-webkit-device-pixel-ratio : 1.5
will be become
-o-device-pixel-ratio : 3/2
sminfosoft10
I like what you guys tend to be up too. This sort of clever work and reporting! Keep up the terrific works guys I’ve included you guys to blogroll.
“Web Design Company”:http://www.sminfosoft.com
“Technology News”:http://update-technologynews.blogspot.in/
shoes and sunglasses for sale
i am waiting for the iphone 5.
povinne ruceni
Interested article and very useful information in it.
jameswillweb
Haven’t read through the entire comments, but just wondering why you used -device-pixel-ratio which needs to be prefixed rather than ‘resolution’ in your media queries? Seems to me you could be more accurate and less tied to specific device definitions by using resolution.
Also… to me your MQ for targeting the Kindle and the Tab are great in terms of a useful exercise, but are amazingly impractical for real-world development. It just shouldn’t be that hard.
Mwahaha
Scott, Thanks for a good article.
But what does this sentence mean:“Devices usually give a height less than the actual device-height so to avoid 1024 × 768 tablets identifying those under 600 pixels tall will avoid those.”?
It’s not just grammatically gonzo, it’s actually totally unclear. I’ve read it over and over and I just don’t get it. Device height isn’t reported correctly? On which devices? Can you document/expand on this? You’re dropping a huge bomb here without any elaboration. I think we’d all be really interested to see a table of actual devices with their actual and media-query-reported dimensions, if such a thing exists.
Also, you make a sweeping (and I believe correct) generalization about how developers probably shouldn’t try to get locked into targeting specific devices, but instead classes of devices with different characteristics. But then you go on to specifically target two devices in the most narrow way possible. It’s philosophically “¦ baffling. Even for just these two devices, I’m left at the end of the article wondering which approach I should take to preserve reference pixel scale for typography across all devices. Scale up the Fire or scale down the Tab? I get the relativity of it all, but it would clarify a lot if a single position were taken.
Scott Kellum
@jameswillweb At the time, this was the most widely available tool at the disposal of developers. Resolution vs device-pixel-ratio is still under some amount of debate from what I have read, although the W3C seems to be settling on resolution. Time will probably provide more and better solutions and resolution is one of them, but the issue of unit discrepancies is a big one. Unfortunately the unit specs are, in my opinion, a mess. This is how I was taming a particularly annoying outliers at the time.
Scott Kellum
@Mwahaha Sorry for my gramatical mis-steps. I have always struggled with my writing. What that means is that devices rarely report the correct device height in pixels. Instead they report the height minus any browser chrome, so essentially the viewport height. Querying a lower number ensures that those devices are included.
These are just two devices I am using as examples. Many other devices in the 7” class of tablets are targeted with these queries, like the Nook, Viewsonic viewpad, ACME Android 7” “¦
Scott Kellum
@Mwahaha Also I did take a stance on what scale I prefer. I scaled both devices to the equivalent of 1.2. “From what I hear”:https://twitter.com/huafi/status/220941824955654144 , this is around the same scale as the Galaxy Nexus.