10 ms·

CSS px is an Angular Measurement

129 points by ned 15y ago

nthitz 15y ago
Ok, but does it matter?
- wmf 15y ago
  Only to people who freak out when they realize that 1 px = 2 pixels on Retina displays.
  - tlb 15y ago
    That includes me. Making a pixel not be a pixel is surely one of the great pooch-screws of modern standards. 'pt' existed to be resolution-independent.
    - wmf 15y ago
      If they had set 1 px = 1 pixel, almost all Web pages would be unreadably small. AFAIK, Web designers don't use pt.
      - JoshTriplett 15y ago
        And people would have quickly learned to not use "pixel" unless they really mean "pixel".
        wmf 15y ago
        You never really mean pixel, so I guess you're arguing for the removal of the px unit completely. (bzbarsky explained this better: http://news.ycombinator.com/item?id=3697227 http://news.ycombinator.com/item?id=3697227 ) Then designers would start asking for a unit that is resolution-independent but always an integer multiple of pixels — essentially px under a different name. The px unit is really useful, but maybe it should have had a different name; it's too late to argue about it now.
        JoshTriplett 15y ago
        On the rare occasions where I say "px" rather than some scalable unit, I really do mean pixel. For example, I might use px to specify the width of an element that needs to have exactly the same width as an img tag.
        nitrogen 15y ago
        On devices where 1px != 1 device pixel, images should be scaled by the same proportion as the px unit. So, if you set an img to 150px wide, and a div below it to 150px wide, they will be the same width, even if 150px == 300 pixels. I'd be happy to learn of any browsers where that is not the case.
        JoshTriplett 15y ago
        If I wanted an image scaled, I'd give it a size in em or similar, not in px.
        nitrogen 15y ago
        HTML is a text markup language, not a device interface language. CSS is a page layout language. HTML and CSS are designed for optimum user control as well as designer flexibility. You assume you're designing for one type of device. Designers before you have assumed 96dpi for web pages. The W3C realize these assumptions, realize that the user may want to use a different type of device, and thus define px in terms of DPI. As others have mentioned, if a user prints a web page on a 1200dpi printer, your 960px fixed layout is 4/5ths of an inch wide. Your users would not be pleased. Under the device-centric interpretation of px, you'd have to provide a medium-specific style sheet for every possible type of output device. Designers would not be pleased. Maybe you're trying to use HTML+CSS as a rendering target for a general purpose widget library like Gtk+. In that case, I can understand your frustration.
    - colanderman 15y ago
      I'm not a web designer. Can you explain to me why it's important to be able to position/size something to exactly N pixels, rather than to exactly kN pixels (where k is some integer decided by the browser implementor)?
      - mikeklaas 15y ago
        The biggest reason is that most css properties ignore fractional px values—you can't draw a .5px border, for instance.
        evincarofautumn 15y ago
        Which is absurd, because antialiasing exists for that very reason. I should be able to render a single-pixel-thick vertical line between two columns of display pixels, and get two columns of display pixels at 50% (apparent) brightness. Subpixel rendering would be even better.
        bzbarsky 15y ago
        This is only true in some UAs. Gecko has supported fractional pixel values for years in general, though for borders in particular the width is clamped to integer _device_ (not CSS) pixels. WebKit has been rounding them at parse time (even in cases when 1 CSS px is multiple device pixels) for a while, but they're about to fix that. I believe that IE also supports subpixel layout. Not sure about Opera, offhand.
      - tlb 15y ago
        Images and <canvas> and <embed> use actual pixels. It's hard to make things look right when you don't have the same unit in CSS.
        wmf 15y ago
        Maybe I'm misunderstanding, but I don't think this is correct; the browser should scale everything. See http://joubert.posterous.com/crisp-html-5-canvas-text-on-mobile-phones-and http://joubert.posterous.com/crisp-html-5-canvas-text-on-mob... for example.
- kwamenum86 15y ago
  I think the important part is that setting something to be 1000px wide does not mean it will take up 1000 pixels on a 1000 pixel wide screen.
- JoelSutherland 15y ago
  Increasingly. To my knowledge, all desktop browsers ignore this spec and treat each pixel as a pixel. (This will likely change with the upcoming Retina Macbook Pros) For a while all mobile devices treated all pixels as a pixel. But then iOS and Android devices began to dramatically increase their DPI. In the case of iOS, the math is easy, everything gets multiplied by 2 (though chasing pixel precision in a browser does still require hacks [1]). Android is much more fragmented (go figure). System-wide, there is a DPI setting that influences the viewport pixel-size that the browser claims. For a 800x480 screen, a 1.5x multiplier is used. The browser advertises the mobile-standard 320px viewport width. For the most part, this is good because websites are easier to design for and look roughly as designed on more devices. On ultra-high DPI devices, they even appear pixel-precise. The problem is on the very common mid-dpi devices like the millions of 4" 800x480 devices out there. Pixel-level control is lost, and the pixels are large enough for this to be visible. Some people don't care about pixel-level design precision, some people do. Most people, though, will recognize that a webpage looks not-quite-perfect even if they can't put a finger on it. We're almost out of the woods on phones as DPI is quickly approaching the upper 200's across the board. Unfortunately we're just entering it for non iOS tablets. [1] http://bradbirdsall.com/mobile-web-in-high-resolution http://bradbirdsall.com/mobile-web-in-high-resolution
  - voyou 15y ago
    "all desktop browsers ignore this spec and treat each pixel as a pixel" That's not ignoring the spec, though, it's following it. Where the device pixel is close to the reference pixel (as it is, on desktop browsers), the px measurement is supposed to represent one device pixel. See the CSS 2.1 spec: http://www.w3.org/TR/CSS2/syndata.html#length-units http://www.w3.org/TR/CSS2/syndata.html#length-units
  - Stratoscope 15y ago
    > To my knowledge, all desktop browsers ignore this spec and treat each pixel as a pixel. Not really. Most desktop browsers support pixel scaling with Ctrl+Plus and Ctrl+Minus or user preferences, and they may even remember this setting for each domain. So not only is a CSS pixel not always a device pixel, but it may be a different (fractional) number of device pixels on different websites.
gwillen 15y ago
This is dumb. The fact that one pixel subtends a particular visual angle does not imply that N pixels subtend N times that angle. It should be very plain to anybody implementing or using a rendering engine that pixels are intended to be linearly additive. This implies that N pixels will subtend less than N times the angle one pixel subtends. On a flat screen, this is normal and expected, because a pixel further from the eye will subtend less angle than a pixel closer to the eye.
- crazygringo 15y ago
  That's actually a very good point, don't know why you're being downvoted.
  - gwillen 15y ago
    I find it interesting that I was downvoted to the negatives, then you posted this reply, and then I got upvoted to the top. I wonder what the causation is there. I suspect I know why I was downvoted; I used unnecessary emotive language ("dumb") and didn't explain my point clearly. Most of the rest of the commenters were focused on one part of the article's point, which is very relevant -- the idea that a pixel is no longer a pixel, but a particular fraction of an inch of screen space. I was complaining about a different part, which is the article author's claim that the function mapping real pixels to CSS pixels is nonlinear (which I think is just a misreading of what the spec intended.)
    - bigiain 15y ago
      <meta discussion about voting> I worked out a while ago that the comments I expended least effort on were the ones that were most likely to get significantly upvoted (and also downvoted) - longer comments get way fewer votes. My theory is that a single, almost throwaway sentence is easier to agree (or disagree) with, and hence earn a reflexive vote-click. When I write a few paragraphs (or more) as a comment, particularly with researched links and/or data, and thoughts/commentary on those links/data, I get way fewer votes, either up or down. My initial reaction to this "discovery" was to decide to post shorter and more concise comments. But a few moments of reflection revealed that for me that's a pointless change of behavior for two reasons: 1) I don't comment with the aim of getting voted up, and shouldn't change my comment behavior just because there's a metric to be gamed, and 2) because at least for me, the bulk of my karma has come way more from fortuitously being first to submit a popular link (mostly assisted by my non West Coast GMT+10:00 timezone) - since the karma to be gained from a several hundred upvoted submission is _way_ less effort than writing thoughtful comments - and it's clear people are gaming that to pump karma (who was it that posted a while back about seeing bots stalking their rss feeds to autosubmit new posts? patio11 maybe?) As you can see, I'm rambling all over the place with this comment - almost certainly in a way that makes it more difficult for readers to chose whether to up or down vote, and I'll guess resulting in neither. Possibly stupid idea floating around my head right now - what if the voting system allowed you to not just up or down vote a comment, but to selectively up or down vote paragraphs or sentences or sentence fragments? Maybe I could choose to upvote your "the article author's claim that the function mapping real pixels to CSS pixels is nonlinear (which I think is just a misreading of what the spec intended.)" and possibly downvote another bit (there's not actually any of your post I'd choose to downvote, but maybe for example the "I suspect I know why I was downvoted"), then choose how to split my 1 unit of vote between the bits I want to vote up and the ones I want to vote down, so I could say 2/3rds for the up vote and 1/3rd for the down vote giving you a total of +1/3rd of a unit of karma - and more importantly, giving you feedback on why you're seeing the voting numbers you are…
colanderman 15y ago
Interesting. The angular resolution of the human eye is about 0.02° according to Wikipedia (http://en.wikipedia.org/wiki/Naked_eye#Basic_accuracies http://en.wikipedia.org/wiki/Naked_eye#Basic_accuracies), which, using the provided calculator on this page, corresponds very nearly to one pixel (0.938 to be exact). Pretty sweet.
evincarofautumn 15y ago
This matters more still for a display with head-tracking. As I read this, the apparent angular size of 1px within a human’s FOV ought to remain constant, regardless of viewer position or physical pixels.
yonran 15y ago
Not only is the definition of pixel unexpected, but 1in is now defined to be 96px in CSS 2.1, because this was the default in Windows for so many years. In retrospect, given whole page zoom from Opera and high-resolution displays from Apple, probably CSS shouldn't have had units named "in" and "px" at all but instead should have had a single unit like SVG.
javajosh 15y ago
This is one of the more important Hacker News submissions I've seen in a long time. It seems that there is, potentially, a fundamental disconnect between what "px" is supposed to mean and what it means in practice. Given the incredible importance of the web, particularly the front-end of the web, and the extraordinary increases in screen resolution (today the iPhone 4 and iPad 3, tomorrow most computers), it's very important to resolve this discrepancy. Personally, I'm disgusted at the W3C standard. It's a great idea to have an angular measure (really great) but to call it a "pixel" is horrible. A pixel is the smallest controllable dot on a physical display, and nothing else. Call it an "aixle" abbreviated "ax" and short for "angular pixel" but don't overload the term "pixel".
- ned 15y ago
  I'm afraid this boat has long sailed. The "pixel" term is in the CSS 2.1 Spec. It's set in stone. Personally I've made peace with it. I say either "CSS pixels" or "device pixels", depending on what I want to express. And although the high resolution screens have only made the difference between the two more visible, it was there since Opera featured full pages zoom many years ago, and when Mobile Safari introduced the "viewport" meta-tag in 2007.
  - JoshTriplett 15y ago
    Unfortunately, redefining "px" from its original meaning as "device pixels" to a new meaning of "probably one 96th of an inch except on mobile browsers where ..." means that CSS no longer has any way to express "device pixels".
    - bzbarsky 15y ago
      What are the use cases for expressing "device pixels" in a world of widely varying (both across devices and in time) device pixel densities?
- gauravk92 15y ago
  So basically use em, like we should have all along?
tantalor 15y ago
Example Moon in px: https://gist.github.com/2025080 https://gist.github.com/2025080
kickingvegas 15y ago
I've mentioned this before and I'm not the first to say it, but it's time to stop using px and start using in its place absolute measurements like inches or millimeters. It's the only sane approach to supporting different resolution displays.
- JoshTriplett 15y ago
  Unfortunately, devices stopped actually making "mm" a millimeter long a while ago; for instance, various mobile devices scale "mm" by a factor of 2 because they assume that sites don't actually want a physical unit of measure.
  - kickingvegas 15y ago
    If you don't mind my asking: which devices?
    - JoshTriplett 15y ago
      Take a look at http://robert.ocallahan.org/2010/08/css-units-changes-landed_20.html http://robert.ocallahan.org/2010/08/css-units-changes-landed... for some of the details.
- bzbarsky 15y ago
  Absolute measurements (which no longer exist in CSS) are a sane approach to support different resolution displays that are all used at the same viewing distance. Using absolute measurements to size things on a web page that is then viewed on a TV (viewing distance in the 5-15ft range), a tablet (viewing distance in the 1-2ft range), and an eyeglass HUD (viewing distance in the 1-3in range) would be a disaster. The fact that people _were_ using inches and millimeters on the web and expecting them to somehow work across all these devices is why they're all now defined in terms of CSS reference pixels...
kickingvegas 15y ago
I've mentioned this before and I'm not the first to say it, but it's time to stop using px and start using in its place absolute measurements like inches or millimeters. It's the only sane approach to supporting different resolution displays.

129 points by ned 15y ago

nthitz 15y ago

Ok, but does it matter?

wmf 15y ago
Only to people who freak out when they realize that 1 px = 2 pixels on Retina displays.
- tlb 15y ago
  That includes me. Making a pixel not be a pixel is surely one of the great pooch-screws of modern standards. 'pt' existed to be resolution-independent.
  - wmf 15y ago
    If they had set 1 px = 1 pixel, almost all Web pages would be unreadably small. AFAIK, Web designers don't use pt.
    - JoshTriplett 15y ago
      And people would have quickly learned to not use "pixel" unless they really mean "pixel".
      - wmf 15y ago
        You never really mean pixel, so I guess you're arguing for the removal of the px unit completely. (bzbarsky explained this better: http://news.ycombinator.com/item?id=3697227 http://news.ycombinator.com/item?id=3697227 ) Then designers would start asking for a unit that is resolution-independent but always an integer multiple of pixels — essentially px under a different name. The px unit is really useful, but maybe it should have had a different name; it's too late to argue about it now.
        JoshTriplett 15y ago
        On the rare occasions where I say "px" rather than some scalable unit, I really do mean pixel. For example, I might use px to specify the width of an element that needs to have exactly the same width as an img tag.
        nitrogen 15y ago
        On devices where 1px != 1 device pixel, images should be scaled by the same proportion as the px unit. So, if you set an img to 150px wide, and a div below it to 150px wide, they will be the same width, even if 150px == 300 pixels. I'd be happy to learn of any browsers where that is not the case.
        JoshTriplett 15y ago
        If I wanted an image scaled, I'd give it a size in em or similar, not in px.
        nitrogen 15y ago
        HTML is a text markup language, not a device interface language. CSS is a page layout language. HTML and CSS are designed for optimum user control as well as designer flexibility. You assume you're designing for one type of device. Designers before you have assumed 96dpi for web pages. The W3C realize these assumptions, realize that the user may want to use a different type of device, and thus define px in terms of DPI. As others have mentioned, if a user prints a web page on a 1200dpi printer, your 960px fixed layout is 4/5ths of an inch wide. Your users would not be pleased. Under the device-centric interpretation of px, you'd have to provide a medium-specific style sheet for every possible type of output device. Designers would not be pleased. Maybe you're trying to use HTML+CSS as a rendering target for a general purpose widget library like Gtk+. In that case, I can understand your frustration.
  - colanderman 15y ago
    I'm not a web designer. Can you explain to me why it's important to be able to position/size something to exactly N pixels, rather than to exactly kN pixels (where k is some integer decided by the browser implementor)?
    - mikeklaas 15y ago
      The biggest reason is that most css properties ignore fractional px values—you can't draw a .5px border, for instance.
      - evincarofautumn 15y ago
        Which is absurd, because antialiasing exists for that very reason. I should be able to render a single-pixel-thick vertical line between two columns of display pixels, and get two columns of display pixels at 50% (apparent) brightness. Subpixel rendering would be even better.
      - bzbarsky 15y ago
        This is only true in some UAs. Gecko has supported fractional pixel values for years in general, though for borders in particular the width is clamped to integer _device_ (not CSS) pixels. WebKit has been rounding them at parse time (even in cases when 1 CSS px is multiple device pixels) for a while, but they're about to fix that. I believe that IE also supports subpixel layout. Not sure about Opera, offhand.
    - tlb 15y ago
      Images and <canvas> and <embed> use actual pixels. It's hard to make things look right when you don't have the same unit in CSS.
      - wmf 15y ago
        Maybe I'm misunderstanding, but I don't think this is correct; the browser should scale everything. See http://joubert.posterous.com/crisp-html-5-canvas-text-on-mobile-phones-and http://joubert.posterous.com/crisp-html-5-canvas-text-on-mob... for example.
kwamenum86 15y ago
I think the important part is that setting something to be 1000px wide does not mean it will take up 1000 pixels on a 1000 pixel wide screen.
JoelSutherland 15y ago
Increasingly. To my knowledge, all desktop browsers ignore this spec and treat each pixel as a pixel. (This will likely change with the upcoming Retina Macbook Pros) For a while all mobile devices treated all pixels as a pixel. But then iOS and Android devices began to dramatically increase their DPI. In the case of iOS, the math is easy, everything gets multiplied by 2 (though chasing pixel precision in a browser does still require hacks [1]). Android is much more fragmented (go figure). System-wide, there is a DPI setting that influences the viewport pixel-size that the browser claims. For a 800x480 screen, a 1.5x multiplier is used. The browser advertises the mobile-standard 320px viewport width. For the most part, this is good because websites are easier to design for and look roughly as designed on more devices. On ultra-high DPI devices, they even appear pixel-precise. The problem is on the very common mid-dpi devices like the millions of 4" 800x480 devices out there. Pixel-level control is lost, and the pixels are large enough for this to be visible. Some people don't care about pixel-level design precision, some people do. Most people, though, will recognize that a webpage looks not-quite-perfect even if they can't put a finger on it. We're almost out of the woods on phones as DPI is quickly approaching the upper 200's across the board. Unfortunately we're just entering it for non iOS tablets. [1] http://bradbirdsall.com/mobile-web-in-high-resolution http://bradbirdsall.com/mobile-web-in-high-resolution
- voyou 15y ago
  "all desktop browsers ignore this spec and treat each pixel as a pixel" That's not ignoring the spec, though, it's following it. Where the device pixel is close to the reference pixel (as it is, on desktop browsers), the px measurement is supposed to represent one device pixel. See the CSS 2.1 spec: http://www.w3.org/TR/CSS2/syndata.html#length-units http://www.w3.org/TR/CSS2/syndata.html#length-units
- Stratoscope 15y ago
  > To my knowledge, all desktop browsers ignore this spec and treat each pixel as a pixel. Not really. Most desktop browsers support pixel scaling with Ctrl+Plus and Ctrl+Minus or user preferences, and they may even remember this setting for each domain. So not only is a CSS pixel not always a device pixel, but it may be a different (fractional) number of device pixels on different websites.

gwillen 15y ago

This is dumb. The fact that one pixel subtends a particular visual angle does not imply that N pixels subtend N times that angle. It should be very plain to anybody implementing or using a rendering engine that pixels are intended to be linearly additive. This implies that N pixels will subtend less than N times the angle one pixel subtends. On a flat screen, this is normal and expected, because a pixel further from the eye will subtend less angle than a pixel closer to the eye.

crazygringo 15y ago
That's actually a very good point, don't know why you're being downvoted.
- gwillen 15y ago
  I find it interesting that I was downvoted to the negatives, then you posted this reply, and then I got upvoted to the top. I wonder what the causation is there. I suspect I know why I was downvoted; I used unnecessary emotive language ("dumb") and didn't explain my point clearly. Most of the rest of the commenters were focused on one part of the article's point, which is very relevant -- the idea that a pixel is no longer a pixel, but a particular fraction of an inch of screen space. I was complaining about a different part, which is the article author's claim that the function mapping real pixels to CSS pixels is nonlinear (which I think is just a misreading of what the spec intended.)
  - bigiain 15y ago
    <meta discussion about voting> I worked out a while ago that the comments I expended least effort on were the ones that were most likely to get significantly upvoted (and also downvoted) - longer comments get way fewer votes. My theory is that a single, almost throwaway sentence is easier to agree (or disagree) with, and hence earn a reflexive vote-click. When I write a few paragraphs (or more) as a comment, particularly with researched links and/or data, and thoughts/commentary on those links/data, I get way fewer votes, either up or down. My initial reaction to this "discovery" was to decide to post shorter and more concise comments. But a few moments of reflection revealed that for me that's a pointless change of behavior for two reasons: 1) I don't comment with the aim of getting voted up, and shouldn't change my comment behavior just because there's a metric to be gamed, and 2) because at least for me, the bulk of my karma has come way more from fortuitously being first to submit a popular link (mostly assisted by my non West Coast GMT+10:00 timezone) - since the karma to be gained from a several hundred upvoted submission is _way_ less effort than writing thoughtful comments - and it's clear people are gaming that to pump karma (who was it that posted a while back about seeing bots stalking their rss feeds to autosubmit new posts? patio11 maybe?) As you can see, I'm rambling all over the place with this comment - almost certainly in a way that makes it more difficult for readers to chose whether to up or down vote, and I'll guess resulting in neither. Possibly stupid idea floating around my head right now - what if the voting system allowed you to not just up or down vote a comment, but to selectively up or down vote paragraphs or sentences or sentence fragments? Maybe I could choose to upvote your "the article author's claim that the function mapping real pixels to CSS pixels is nonlinear (which I think is just a misreading of what the spec intended.)" and possibly downvote another bit (there's not actually any of your post I'd choose to downvote, but maybe for example the "I suspect I know why I was downvoted"), then choose how to split my 1 unit of vote between the bits I want to vote up and the ones I want to vote down, so I could say 2/3rds for the up vote and 1/3rd for the down vote giving you a total of +1/3rd of a unit of karma - and more importantly, giving you feedback on why you're seeing the voting numbers you are…

colanderman 15y ago

Interesting. The angular resolution of the human eye is about 0.02° according to Wikipedia (http://en.wikipedia.org/wiki/Naked_eye#Basic_accuracies http://en.wikipedia.org/wiki/Naked_eye#Basic_accuracies), which, using the provided calculator on this page, corresponds very nearly to one pixel (0.938 to be exact). Pretty sweet.

evincarofautumn 15y ago

This matters more still for a display with head-tracking. As I read this, the apparent angular size of 1px within a human’s FOV ought to remain constant, regardless of viewer position or physical pixels.

yonran 15y ago

Not only is the definition of pixel unexpected, but 1in is now defined to be 96px in CSS 2.1, because this was the default in Windows for so many years. In retrospect, given whole page zoom from Opera and high-resolution displays from Apple, probably CSS shouldn't have had units named "in" and "px" at all but instead should have had a single unit like SVG.

javajosh 15y ago

This is one of the more important Hacker News submissions I've seen in a long time. It seems that there is, potentially, a fundamental disconnect between what "px" is supposed to mean and what it means in practice. Given the incredible importance of the web, particularly the front-end of the web, and the extraordinary increases in screen resolution (today the iPhone 4 and iPad 3, tomorrow most computers), it's very important to resolve this discrepancy. Personally, I'm disgusted at the W3C standard. It's a great idea to have an angular measure (really great) but to call it a "pixel" is horrible. A pixel is the smallest controllable dot on a physical display, and nothing else. Call it an "aixle" abbreviated "ax" and short for "angular pixel" but don't overload the term "pixel".

ned 15y ago
I'm afraid this boat has long sailed. The "pixel" term is in the CSS 2.1 Spec. It's set in stone. Personally I've made peace with it. I say either "CSS pixels" or "device pixels", depending on what I want to express. And although the high resolution screens have only made the difference between the two more visible, it was there since Opera featured full pages zoom many years ago, and when Mobile Safari introduced the "viewport" meta-tag in 2007.
- JoshTriplett 15y ago
  Unfortunately, redefining "px" from its original meaning as "device pixels" to a new meaning of "probably one 96th of an inch except on mobile browsers where ..." means that CSS no longer has any way to express "device pixels".
  - bzbarsky 15y ago
    What are the use cases for expressing "device pixels" in a world of widely varying (both across devices and in time) device pixel densities?
gauravk92 15y ago
So basically use em, like we should have all along?

tantalor 15y ago

Example Moon in px: https://gist.github.com/2025080 https://gist.github.com/2025080

kickingvegas 15y ago

I've mentioned this before and I'm not the first to say it, but it's time to stop using px and start using in its place absolute measurements like inches or millimeters. It's the only sane approach to supporting different resolution displays.

JoshTriplett 15y ago
Unfortunately, devices stopped actually making "mm" a millimeter long a while ago; for instance, various mobile devices scale "mm" by a factor of 2 because they assume that sites don't actually want a physical unit of measure.
- kickingvegas 15y ago
  If you don't mind my asking: which devices?
  - JoshTriplett 15y ago
    Take a look at http://robert.ocallahan.org/2010/08/css-units-changes-landed_20.html http://robert.ocallahan.org/2010/08/css-units-changes-landed... for some of the details.
bzbarsky 15y ago
Absolute measurements (which no longer exist in CSS) are a sane approach to support different resolution displays that are all used at the same viewing distance. Using absolute measurements to size things on a web page that is then viewed on a TV (viewing distance in the 5-15ft range), a tablet (viewing distance in the 1-2ft range), and an eyeglass HUD (viewing distance in the 1-3in range) would be a disaster. The fact that people _were_ using inches and millimeters on the web and expecting them to somehow work across all these devices is why they're all now defined in terms of CSS reference pixels...

kickingvegas 15y ago