Develop Reference

Why is the point unit in CSS equal to 1.333 pixels? [duplicate]

What is the difference between pt and px in CSS? Which one should I use and why?

px ≠ Pixels
All of these answers seem to be incorrect. Contrary to intuition, in CSS the px is not pixels. At least, not in the simple physical sense.
Read this article from the W3C, EM, PX, PT, CM, IN…, about how px is a "magical" unit invented for CSS. The meaning of px varies by hardware and resolution. (That article is fresh, last updated 2014-10.)
My own way of thinking about it: 1 px is the size of a thin line intended by a designer to be barely visible.
To quote that article:
The px unit is the magic unit of CSS. It is not related to the current font and also not related to the absolute units. The px unit is defined to be small but visible, and such that a horizontal 1px wide line can be displayed with sharp edges (no anti-aliasing). What is sharp, small and visible depends on the device and the way it is used: do you hold it close to your eyes, like a mobile phone, at arms length, like a computer monitor, or somewhere in between, like a book? The px is thus not defined as a constant length, but as something that depends on the type of device and its typical use.
To get an idea of the appearance of a px, imagine a CRT computer monitor from the 1990s: the smallest dot it can display measures about 1/100th of an inch (0.25mm) or a little more. The px unit got its name from those screen pixels.
Nowadays there are devices that could in principle display smaller sharp dots (although you might need a magnifier to see them). But documents from the last century that used px in CSS still look the same, no matter what the device. Printers, especially, can display sharp lines with much smaller details than 1px, but even on printers, a 1px line looks very much the same as it would look on a computer monitor. Devices change, but the px always has the same visual appearance.
That article gives some guidance about using pt vs px vs em, to answer this Question.

Here you've got a very detailed explanation of their differences
http://kyleschaeffer.com/development/css-font-size-em-vs-px-vs-pt-vs/
The jist of it (from source)
Pixels are fixed-size units that are used in screen media (i.e. to be read on the computer screen). Pixel stands for "picture element" and as you know, one pixel is one little "square" on your screen.
Points are traditionally used in print media (anything that is to be printed on paper, etc.). One point is equal to 1/72 of an inch. Points are much like pixels, in that they are fixed-size units and cannot scale in size.

Have a look at this excellent article at CSS-Tricks:
px – em – % – pt – keyword
Taken from the article:
pt
The final unit of measurement that it is possible to declare font sizes in is point values (pt). Point values are only for print CSS! A point is a unit of measurement used for real-life ink-on-paper typography. 72pts = one inch. One inch = one real-life inch like-on-a-ruler. Not an inch on a screen, which is totally arbitrary based on resolution.
Just like how pixels are dead-accurate on monitors for font-sizing, point sizes are dead-accurate on paper. For the best cross-browser and cross-platform results while printing pages, set up a print stylesheet and size all fonts with point sizes.
For good measure, the reason we don't use point sizes for screen display (other than it being absurd), is that the cross-browser results are drastically different:
px
If you need fine-grained control, sizing fonts in pixel values (px) is an excellent choice (it's my favorite). On a computer screen, it doesn't get any more accurate than a single pixel. With sizing fonts in pixels, you are literally telling browsers to render the letters exactly that number of pixels in height:
Windows, Mac, aliased, anti-aliased, cross-browsers, doesn't matter, a font set at 14px will be 14px tall. But that isn't to say there won't still be some variation. In a quick test below, the results were slightly more consistent than with keywords but not identical:
Due to the nature of pixel values, they do not cascade. If a parent element has an 18px pixel size and the child is 16px, the child will be 16px. However, font-sizing settings can be using in combination. For example, if the parent was set to 16px and the child was set to larger, the child would indeed come out larger than the parent. A quick test showed me this:
"Larger" bumped the 16px of the parent into 20px, a 25% increase.
Pixels have gotten a bad wrap in the past for accessibility and usability concerns. In IE 6 and below, font-sizes set in pixels cannot be resized by the user. That means that us hip young healthy designers can set type in 12px and read it on the screen just fine, but when folks a little longer in the tooth go to bump up the size so they can read it, they are unable to. This is really IE 6's fault, not ours, but we gots what we gots and we have to deal with it.
Setting font-size in pixels is the most accurate (and I find the most satisfying) method, but do take into consideration the number of visitors still using IE 6 on your site and their accessibility needs. We are right on the bleeding edge of not needing to care about this anymore.

A pt is 1/72th of an inch and is a useless measure for anything that is rendered on a device which doesn't calculate the DPI correctly. This makes it a reasonable choice for printing and a dreadful choice for use on screen.
A px is a pixel, which will map on to a screen pixel in most cases.
CSS provides a bunch of other units, and which one you should choose depends on what you are setting the size of.
A pixel is great if you need to size something to match an image, or if you want a thin border.
Percentages are great for font sizes as, if you use them consistently, you get font sizes proportional to the user's preference.
Ems are great when you want an element to size itself based on the font size (so a paragraph might get wider if the font size is larger)
… and so on.

pt is a derivation (abbreviation) of "point" which historically was used in print type faces where the size was commonly "measured" in "points" where 1 point has an approximate measurement of 1/72 of an inch, and thus a 72 point font would be 1 inch in size.
EDIT: Note to clarify
There are approximately 72 (72.272) points in one inch or 2.54 cm. The point was first established by the Milanese typographer, Francesco Torniella da Novara ( c. 1490 – 1589) in his 1517 alphabet, L'Alfabeto. (you can search for various references to those)
px is an abbreviation for "pixel" which is a simple "dot" on either a screen or a dot matrix printer or other printer or device which renders in a dot fashion - as opposed to old typewriters which had a fixed size, solid striker which left an imprint of the character by pressing on a ribbon, thus leaving an image of a fixed size.
Closely related to point are the terms "uppercase" and "lowercase" which historically had to do with the selection of the fixed typographical characters where the "capital" characters where placed in a box (case) above the non-capitalized characters which were place in a box below, and thus the "lower" case.
There were different boxes (cases) for different typographical fonts and sizes, but still and "upper" and "lower" case for each of those.
Another term is the "pica" which is a measure of one character in the font, thus a pica is 1/6 of an inch or 12 point units of measure (12/72) of measure.
Strickly speaking the measurement is on computers 4.233mm or 0.166in whereas the old point (American) is 1/72.27 of an inch and French is 4.512mm (0.177in.). Thus my statement of "approximate" regarding the measurements.
Further, typewriters as used in offices, had either and "Elite" or a "Pica" size where the size was 10 and 12 characters per inch respectively.
Additionally, the "point", prior to standardization was based on the metal typographers "foot" size, the size of the basic footprint of one character, and varied somewhat in size.
Note that a typographical "foot" was originally from a deceased printers actual foot. A typographic foot contains 72 picas or 864 points.
As to CSS use, I prefer to use EM rather than px or pt, thus gaining the advantage of scaling without loss of relative location and size.
EDIT: Just for completeness you can think of EM (em) as an element of measure of one font height, thus 1em for a 12pt font would be the height of that font and 2em would be twice that height. Note that for a 12px font, 2em is 24 pixels. SO 10px is typically 0.63em of a standard font as "most" browsers base on 16px = 1em as a standard font size.

Yes, "px" means "pixel"
Now that I said it, I can already hear an army of clairvoyants approaching, with "px has nothing to do with pixels" on their banners. They're so proud of knowing better that they look up every comment containing the original truth and explain in detail that it's false, incorrect, misleading, etc.
And yes they have a point - a very specific point in time, actually, called iPhone 4.
Here's what happened.
The peaceful days
Before Retina displays, one pixel was one pixel. Because that's how it should be, according to human logic. You put a single pixel line on the screen, you magnify the hell out of it, and there you go: it's exactly ONE PIXEL wide. On many hardwares, modern ones included, this is still the case, so it's everything but "incorrect" to say 1px = 1 pixel.
But.
Back then, one day, iPhone 3 was followed by iPhone 4, doubling the resolution in both X and Y, and the developers of Safari worried that all webpages will look ricidulous, especially because many web developers relied on the steady 320x480 resolution. So just creating a 640x960 pixel area would have killed most of the sites. And at this point, someone had the billion-dollar idea to introduce a magical beast: a CSS feature called -webkit-min-device-pixel-ratio - on iPhone 3 it was 1, and on iPhone 4 it was set to 2 by default. Meaning "1 CSS pixel now means 2 screen pixels". A very ugly hack to keep websites look somewhat intact - it worked at that time, with the very small cost of some images looking a bit blurry, but in the long run it caused this worldwide misunderstanding of poor old px who actually did nothing wrong.
So then: pt or px?
On screens, use px because on many-many displays it will mean ONE PIXEL. The biggest advantage of using pixels is they look crispy; even if 1px means 2 or 3 physical picture elements, whatever you draw will start at the boundary, not somewhere-in-between. This is very important. Watch any browser animation that includes text, especially size transitions: when you increase a div to double size, but slowly. You'll see how your browser recalculates its pixels and redraws the font when the animation is done. There's a temporary image of the area which is a little blurry - to make the animation itself smoother -, and then, after reaching its final state, a more exact image is calculated. See this CodePen.
1px is always an integer multiplication of hardware pixels; that is, unless your operating system is being smart like resizing your whole desktop to sqrt(2) x PI. Or just 125%, yes, hello Windows on tiny laptops. But anyway - with px, you have the highest chance to align your things with the physical grid.
What about pt? The funny thing about pt is it's actually translated to px, so it's just a worse way to specify pixel sizes. Here's a calculator. Points (since they come from the print world) start to make sense when you print something, but today there are better alternatives, depending on what you need - so tbh, points are almost never needed.
TL;DR
For screens, use px whenever possible.

How to convert PX into DP in Layout

Designer has given me a PSD file, He has created it for 1080X1920 resolution
In PSD he defines that the header height should be 52px, Slider height should be 350px and so on..
In layout when i write layout_height=350dp its taking a lot of height and covering more than half of screen.
I am using default layout to accomplish this task.
Kindly guide me how to define Height in layout in DP with respect to PX

Looks like there's a lack of designer-developer flow. The designs you were given are not mobile friendly (Android neither iOS). I recommend you to take a look to a couple of tools for a nice workflow.
Sketch
Zeplin
And please read this article you both:
Designer's guide to DPI
In Android you need to work in dps and you need the designs to be given in dps. In case you are given the designs in pixels you have to have the agreement with the designer that 1px is equals to 1dp, in other words, the designer is working on MDPI basis where 1dp is equals to 1dp.
So the easiest way to go is your designer needs to work in a screen that is 360x640 pixels instead of 1080x1920. Now you can forget about translating pixels to dps and the other way around because 1px would be 1dp for you. For your designer as well will be easier because he needs to go from guidelines to the design tool, and he doesn't need to translate dps into pixels anymore. Everytime he reads 48 dps in the guidelines (which is everywhere) he knows he has to read it as 48 pixels in his 360x640 canvas in the design tool.
Notes
360x640 is a common screen size in dps (Galaxy S5, Nexus 5 and many others) and because of that is taken as a reference now a days. Please realize your designer can not give you the exact sizes for every component in every layout size for every device. So things like the toolbar height (usually 56dp) is easy to translate to every device, but the toolbar width that you'll size in his designs (360 if you follow my recommendation) is completely useless for you, because that depends on the real device. The Galaxy S5 and the Nexus 5 are 360, but the Nexus 4 is 384, and the nexus 6, 6P and 5X is around 413.... and actually there's much more!!
Designing just for one device or one screen size is too simplistic and problematic. Be aware you have to develop responsive layouts ready for a multiwindow.

What is the default unit of style in React Native?

I am contributing to an Open Source Project where I am developing Material design for React Native. I am blocked at work,I am unable to make some UI level enhancements w.r.t. padding, alignment etc.,
This is the Official Spec of Material Design for Drawer-
In the above image, the UNIT of measurement is dp.
But, in my React Native code, I see there is no such units mentioned. Considering it is "react native" I am confused whether it is px or dp.
I even went over the Official Docs of React Native for Style component. I don't see a mention anywhere.
My Code looks like-
const styles = {
touchable: {
paddingHorizontal: 16,
marginVertical: 8,
height: 48
},
item: {
flex: 1,
flexDirection: 'row',
alignItems: 'center',
},
icon: {
position: 'relative',
},
value: {
flex: 1,
paddingLeft: 34,
top: 2
},
label: {
top: 2
}
},
Please can you tell me, if this is pixels or dp? And also, is 1px = 1dp?

From the docs:
All dimensions in React Native are unitless, and represent
density-independent pixels. Setting dimensions this way is common for components that should always render at exactly the same size, regardless of screen dimensions.
So yes, units in React Native are in dp. If you want to convert them to pixels, use PixelRatio.getPixelSizeForLayoutSize()

I share your confusion somewhat, not being able to actively inspect with a developer console as we are used to in the browser.
I am not familiar with the 'dp' unit, but from what I gather width: 1 renders differently on each device depending on the pixel density of the screen (see link). The information in the react-native docs say that 1 would render thicker on screens with high pixel density. Which then sounds logical as you have more precision on high density screens than you would have on low density screens and react-native aims at being universal so it would not assume high dpi.
It is my understanding that you can use the below linked PixelRatio API to calculate sizes for detail elements (think borders, icons, etc), that way you can dynamically adjust the rendered size according to the device's screen density.
https://facebook.github.io/react-native/docs/pixelratio.html#content

It is the pixel ratio that you have to consider. pixel represents an absolute value. pixel ratio is a relative value. to make app screen and components responsive you have to use pixel ratio.
i have been using in multiple apps already. and i think that is how you have to do it. hope this answers your question.

From what I know, the javascript styling that we use in react js or react native uses pixels. Pixel ratio is only needed to support different size of mobile device screens.

Fractional CSS Pixel Sizes on High Resolution Displays

(I've seen this already; I do not believe this is a duplicate: Are the decimal places in a CSS width respected?)
I set the size of an object as follows:
.foo {
height: 10.5px;
width: 10.5px;
}
Normally, that rounds down; you can't use half a pixel.
That said, the latest Nexus 7 has 320dpi, and a CSS pixel on an Android device is defined as 160dpi. A 10px by 10px image is drawn on the Nexus 7 using 400 pixels, not 100.
So on high-pixel density devices - those where window.devicePixelRatio > 1.0 - are fractional pixels useful, or just discarded anyways?
(Thanks!)
Edit, for a somewhat real-world example.
I have a MacBook Retina. I have a image file that's 21x21 px. I want this to display on my retina without rescaling in any way; I want each pixel in the file to correspond to one pixel on the screen. CSS pixels aren't linked to hardware pixels, and 1 px in CSS corresponds to 4px (2 wide, 2 high) on a Retina display or Nexus 7/10.
I want to be able to specify the exact size of the image, so that it's not rescaled, and so that the page doesn't reflow once the image is loaded. I can do this by putting the image into an div that's set to 11x11, and having the image display as 100%, but that's adding an extra div, and I'm a touch OCD about page size.

They are discarded.
I think I get what you are trying to achieve with the fractional pixels, but really the route you need to go is using higher resolution images for the higher density displays. That should do what you want, no?
I can't think of any reason you would ever need the fractional pixel, or anything similar to it.
That being said, fractional pixels don't work, but fractional percentages do.
.foo {
height: 10.5%;
width: 10.5%;
}
This will work and should do whatever you would need fractional pixels for (you would need to change the percentage obviously from the example).

What's dp (density independent pixels) units with CSS?

For Android, people recommend using dp (density independent pixels) measurements for UI elements, and there are conventions that exist such as using 48dp for a button height, etc.
I'm working on a web application, and I'm getting a lot of criticism on the UI design saying it does not conform with Android design standards. Obviously, my application is going to look different since it is using CSS and HTML instead of the Android Holo theme, but I would still like to make it conform as much as possible. However CSS does not allow density independent measurements.
When I test my application on different resolutions and pixel densities, it does not look good, and sometimes, it is way out of proportion so it's not even functional. CSS doesn't have dp units like Android native development does, but I was wondering what some alternatives are.
Can I somehow get the pixel density using Javascript and manually scale everything appropriately? What is the best way for making a web app that looks and works nicely on all resolutions/densities?

I disagree with the currently accepted answer. As uber5001 suggests, a px is a fixed unit, and in a similar spirit to the efforts of the Android-specifc dp.
Per Material's spec:
When writing CSS, use px wherever dp or sp is stated. Dp only needs to be used in developing for Android.
Additionally
When designing for the web, replace dp with px (for pixel).

http://www.w3.org/TR/css3-values/#lengths
The closest unit available in CSS are the viewport-percentage units.
vw - Equal to 1% of the width of the initial containing block.
vh - Equal to 1% of the height of the initial containing block.
vmin - Equal to the smaller of vw or vh.
vmax - Equal to the larger of vw or vh.
The only mobile browser to be aware of that doesn't support these units is Opera. http://caniuse.com/#feat=viewport-units

Use rem.
It is the font size of the root element and a very good base unit for the size of other UI elements.
If one used the same absolute size (in centimeter), the text and other elements would be much too big on mobile or much too small on desktop.
If one used the same amount of pixels, the text and other elements would be much too small on mobile or much too big on desktop.
The rem unit is on spot because it says "Hey, this is how big normal text should be." Basing the size of other UI elements on this is a pretty reasonable choice.

In CSS3 it may be more accurate to say that the web doesn't have Android's px. The spec for CSS3's px says this:
pixels; 1px is equal to 1/96th of 1in
px might be the measurement you want, in the future.

As of CSS3, there are no CSS units that are truly device-independent. See the W3C spec on absolute lengths. In particular, the absolute units might not match their physical measurements. From the spec:
Note: If the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
Note: This definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption broke the content.)
If physical units were true to their purpose, you could use something like points; points are close enough to dps:
1 in = 72 pt
1 in = 160 dp
1 dp = 72 / 160 pt
If you use SCSS, you can write a function to return in pts:
#function dp($_dp) {
#return (72 / 160) * $_dp + pt;
}
And use it:
.shadow-2 {
height: dp(2);
}

What about a interface based on rem units?
I'm not experienced enough on the matter to confirm, but I think you could make some math based on the viewport size to apply a font-size in the root element and the entire interface would adjust accordingly. This stuff is a bit of witchcraft to me yet.

Why not use points, it is a consistent size across devices. And is relative to the screen size. Most are not familiar with it since it comes from traditional publishing.

What about use some mix between vw ( screen's width for any device) and em?
Here font-size is changing dynamically, depending your device screen width.
Use in your main CSS file next rule:
font-size: calc(100vw * 10 / 375);
(width for iPhone 6/7/8 is 375px, change it to 320px (iPhone5) and etc)
In all cases it is going work perfect. There is only one minus. If your goal is "pixel perfect", then you need to use big numbers after dot.
Example: your goal is font-size h5: 18px on all screens.
Then your perfect "em" will be:
h5 {
font-size: 1.79904em;
}
without perfection use 18 / 10:
h5 {
font-size: 1.8em;
}
According to Google Chrome you get 18.0096px;

It's 2023 and responsive web design with breakpoints that target device widths are the best practice to anticipate changes to screen and appropriate sizes for typography. An alternative to using break points to adjust font sizes is to load discrete CSS files per device, so separate sets of CSS exist in parallel for each width. This latter however is a nightmare to maintain, and simply keeping CSS written with breakouts for breakpoints together keeps everyone sane and everything tidy.
That all said, use PX, reduce font sizes for smaller screens with breakpoints, and let the devices themselves handle the smoothing.
Having lived in the world of relative units where sub-elements refer up a level for their size reference so 1em at the root level and 1em two levels down the child hierarchy / DOM are not the same is another recipe for madness.