I have question about using dp in web development. Im currently reading google material design guidelines and they are talking about elevation and shadows based on dp. How can I use this in web development? Is there any way to calculate this how to create shadow based on dp with HTML CSS?
Example from the web page:
Raised button
Resting state: 2dp
Pressed state: 8dp
For desktop only, raised buttons can have an elevation of:
Resting state: 0dp
Pressed state: 2dp
As mentioned in the Google Material design documents:
A dp is equal to one physical pixel on a screen with a density of 160.
To calculate dp:
dp = (width in pixels * 160) / screen density
When writing CSS, use px wherever dp or sp is stated. Dp only needs to
be used in developing for Android.
and screen density is
Screen resolution refers to the total number pixels in a display.
screen density = screen width (or height) in pixels / screen width (or
height) in inches
So it depends on the screen width and height. There are some converters on the web to calculate for each density. But as most screens are still 72dpi (not mentioned the HDPI screens), I think that is a proper starting point.
There are no CSS units that are truly device-independent. See http://www.w3.org/TR/css3-values/#absolute-lengths. In particular, the absolute units might not match their physical measurements.
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);
}
For Material's shadows they only really use the concept of dp to attempt to relay how elements should be layered.
i.e.
2dp < 8dp // 2 is layered under 8
// or
2dp (resting) => 8dp (focused)
What they are referring to is z-depth (or on the z-axis). This cannot be converted straight to CSS. When they talk about elevation levels they are not referring to x & y or width & height dimension.
See design guide page on elevation.
If you are simply looking for the values for CSS shadows check here.
https://github.com/mrmlnc/material-shadows/blob/master/material-shadows.scss
That is as close to converting z-depth dp to CSS values. The CSS values do match Google's Polymer elements though so it's most likely spot on.
Good Luck!
Related
PNG files may contain chunks of optional informations. One of these optional information blocks is the physical resolution of the image (chunk-signature pHYs).[1] [2] It contains separate values for horizontal and vertical resolution as pixels per unit, and a unit specifier, that can be 0 for unit unspecified, or 1 for meter ← that's quite confusing, because resolutions are traditionally expressed in DPIs.
The Inch is defined as 25.4 mm in the metric system.
So, if I calculate this correctly, 96 DPIs means 3779.527559... dots per metre. For the pHYs chunk, this has to be rounded. I'd say 3780 is the right value, but I found also 3779 suggested on the web. Images of both kind also coexist on my machine.
The difference may not be important in most cases,
3779 * 0.054 = 95.9866
3780 * 0.054 = 96.012
but I try to avoid tricky layout problems when mixing images of both kind in processes that are DPI-aware like creating PDF files using LaTeX.
[1] Portable Network Graphics (PNG) Specification (Second Edition), section11.3.5.3 pHYs Physical pixel dimensions
[2] PNG Specification: Chunk Specifications, section 4.2.4.2. pHYs Physical pixel dimensions
The relative difference is less that 0.03% (2.65/10000), it's hardly relevant.
Anyway, I'd go with 3780. Not only it's the nearest value, but it would give the correct value if some (sloppy) conversor rounds the value down (instead of rounding to the nearest).
Also, if you google "72.009 DPI PNG" you'll see a similar (non) issue with 72 DPI (example), and it seems that most people rounded the value up (which is also the nearest) 2834.645 -> 2835
I really hope, you are able to assist me on this one, as I'm tearing my hair out...
I have a little marquee, based on this code: http://jsfiddle.net/TCJT4/525 that feeds some text.
Here's how it looks on an iPad 6... and please disregard from the preliminary design, but this is how it should look:
Here's how it looks on an iPhone 4S:
The ticker is retrieved from the exact same source, but as you can see, the text appears larger on the iPhone (the iPad image is zoomed, so it appears larger, but in reality, they are both displaying a 320x30 pixels placeholder. The text is temporarily hardcoded to 20px in height and I've tried using other units as well... the banner still looks different on the devices.
I did some debugging of the ticker container/placeholder, as well as the detected banner height and disabled all text-adjusting elements. Here's a result of some of the properties:
iPad 6: Tickerplaceholder DIV-height: 24pixels, bannerheight: 30px, pixelaspect-ratio: 2
iPhone: Tickerplaceholder DIV-height: 32pixels, bannerheight: 30px, pixelaspect-ratio: 2
PC (Chrome): Tickerplaceholder DIV-height: 24pixels, bannerheight: 30px, pixelaspect-ratio: 1;
I find it very strange that two retinadisplay devices display the same banner differently - and that the iPad and the PC displays them correctly.
The ticker can also be found here in its latest form: www.videobanner.dk/ph.html
Pixels are different physical sizes on different devices - so 24px is smaller on one device than on another.
For text, if you use points instead then the size will be the same across devices - they will all make 72pt 1 inch (thereabouts).
Of course this means you have to use text and not bitmaps etc.
Mobile devices may also have a zoom level set for readability (by the user) which will also affect the size - eg you specify 24pt or px and the browser makes it 36pt or px - the calculated size in the inspector will be different to the styled size - to get around this you need to set a value somewhere, then see what it actually is when rendered and apply a ratio to get what you want (via javascript). I've used code like this in the past to ensure text fitted in a box of a given pixel size;
var fontScale = 1 ;
var mySpecifiedFontSize = 24 ;
var myTextElement = document.getElementById("MY_TEXT_ELEMENT_ID") ;
function fontScalingCorrection(){
var style = window.getComputedStyle(myTextElement);
var fontSize = parseInt(style["font-size"]);
if(!isNaN(fontSize)){
if(fontSize !== mySpecifiedFontSize){
fontScale = (mySpecifiedFontSize / fontSize) * fontScale ; //allows for multiple calls
myTextElement.style.fontSize = (fontScale * mySpecifiedFontSize) + "px" ; //or units used
}
}
}
//after the element has been drawn once ( or use another element as a size marker )
fontScalingCorrection();
The cause of the problem is related to a quirk or error in iOS Safari, which returned an incorrect and unpredictable height when dealing with unordered lists, containing text of various lengths. This became apparent when I compared different text lenghts on different platforms. No fix has been found, but I was able to circumvent the problem by splitting one string into several shorter strings, such as
<li>This is a text that </li><li>doesn't go well with iOS</li>
In my project, this solution also works... perhaps not that pretty, though.
This question already has answers here:
How to make a HTML Page in A4 paper size page(s)?
(15 answers)
Closed 7 years ago.
I need to create an HTML page with A4 paper size.
I know that A4 paper size in pixels is: 595px x 842px (string No. 10-11). But while I put those sizes and try to print the page (I print to PDF file, due to the temporary lack of inks), I do not get my HTML fully fits the page: it is much smaller.
When I tried to add some pixels (with the coefficient, of course), I got 794px x 1122px (string No. 12-13) and the second printing attempt (saving to PDF file) gave me the result that this variant is a bit bigger, then needed.
So, what is the solution and why may 595px x 842px not be compatible with real A4 saved to PDF?
This is the example
P.S. I use Chromium for Ubuntu 13.10 and did not checked it on Windows.
I am doing this to be able to simply change the values via PHP and then convert HTML page to PDF, like described here.
HTML assumes that the screen is 96 DPI, or that 1 pixel is 1/96 of an inch.
On hardware with a very high resolution, it uses the concept of logical pixels, which are units that are close to 1/96 of an inch, and each of which consists of multiple device pixels. This is true for printers, but also for phones and other devices with high res screens.
So, if you want a rectangle the same size an an A4 (21 × 29.7 cm), you should use 794 × 1122 pixels, or in CSS, width:794px; height:1122px. But you can also use physical units, width:21cm; height:29.7cm if you don't want to worry about these logical pixels.
If you're planning on printing this, remember you should print at 300dpi, so 8.5"x11"* 300 = height: 3300px; width: 2550px.
Also, I would buffer .25" for a margin as well, so just do 8" x 10.5" before converting to pixels.
How can I set the text size (inside TextField) in standart CSS/printable points? According to the manual:
fontSize - Only the numeric part of the value is used. Units (px, pt)
are not parsed; pixels and points are equivalent.
As far as I understand, 1 pixel may be equal to 1 point only in 72 PPI case. So, actionscript just operating pixels (not the real points). My trouble is to get the actual text size that I can print. Any advices or solutions are welcome.
SWF is measured in pixels, moreover, is scalable, so 1 pixel can be 1 point now, 2 points a bit later (scaleY=scaleX=2), and an undefined number another bit later (removed from stage without dereferencing). In short, for AS there are NO "real points" since it does not know a thing about printers, while it knows about displays.
So I'm using Supersized to scale my background images and that's all good and well. The problem is that if I want the image to look good at multiple resolutions, it should be big, e.g. 2000 px * 2000 px. But why should someone with a resolution of e.g. 800 * 600 need to download such a large image? So what I'd like to do is to have, let's say, 3 sizes of the image (1024 * n, 1680 * n and 2000 * n) and, depending on the resolution, the smallest possible of them would be sent to the user. Any thoughts on how I should implement this?
Using Javascript's window.screen.width will return you the actual pixel width of the screen, so then you can use a simple if statement to select which image you will use.
if(window.screen.width < 1000) {
image = "small.jpg";
} else {
image = "large.jpg";
}
you can use $(window).width(); (http://api.jquery.com/width/) to determine the user window width and then decide which image do you wish to use -
$('#yourImageId').attr('src', 'images/alt/imagename.jpg');
Many ways:
As others said, get the width of the screen, then based on that, manipulate the background image source of the element.
Use Less to create programmatic CSS at client-side
Use the concept of responsive-images