Is there a limit on the amount of padding / margin / translateX / etc a div can have ?
For instance, would something like margin-left: 999999999px work reliably across browsers ?
The CSS3 standard (http://dev.w3.org/csswg/css-values/#lengths) does not specify a limit for lengths, it just states that it is a dimension (a number/integer with a unit identifier). And it doesn't specify a limit for integers either.
MDN gives the same description, but on this page (https://developer.mozilla.org/en-US/docs/Web/CSS/integer) it states that
There is no official range of valid values. Opera supports
values up to 2^15-1, IE up to 2^20-1 and other browsers even higher.
During the CSS3 Values cycle there were a lot of discussion about
setting a minimal limit to support: the latest decision, in April 2012
during the LC phase, was [-2^27-1; 2^27-1] # but other values like 2^24-1
and 2^30-1 were also proposed # #. The latest Editor's draft doesn't
list a limit anymore.
So I guess the limit will depend on the limits set by the browser that you use.
Related
I'm writing a calculation for the left property of an absolutely positioned element. After reading the syntax the only thing I can think of is that I'm trying to multiply two different units but I can't find confirmation for that as I thought the first calculation would have resolved to an integer.
left: calc(1vw * ((100vw / 100) * 1.2));
I need to capture the full size of the viewport so 100vw and then divide it by 100. So if the screen is 1600px this should resolve to 16, then multiply by 1.2 so now it is 19.2 and finally multiply by 1vw to convert it to 19.2vw. The issue I can't confirm is whether the first calculation resolves to an integer (16) or a measurement (16px). If the former then I have no idea why this isn't working. If the latter, how do I get around this?
See MDN on calc:
Multiplication. At least one of the arguments must be a number.
Your expression is trying to multiply 1vw by another vw amount and hence is not valid.
I've been trying to do a complicated calculation in CSS to get rid of media queries on a page, and not require too many of them. The second part of the code below with the long decimal number is me trying to use a set number to calculate the percentage of something (a padding). That number almost perfectly represents the percentage needed per pixel of a view-port, so if I had a massive view-port it could still calculate the percentage or even an extremely small one. But since this number needs to be a percent and I can't just put a percent sign at the end. I needed to get it into a percent via pixels. Meaning calculate how many pixels the browser would calculate if it was a percent. I figured out to take the actual 100 percent width of the page and divide it by 100 to get 1% of the page in pixels. I then multiply that by the number we got for the percentage of the page in the second part of the calculation, giving me the actual pixel width as if it were a percent, and as if the browser had calculated this itself. This is the calc operation I used, that is not working properly:
padding-left: calc((100% / 100) * (0.013641975308642 * 100vw));
It's not working and when we look with chrome dev tools, it tells me the object is invalid. What am I doing wrong?
Viewport height usually returns an integer value; however I am now noticing it returning a value with 2 decimal points.
Why / how do viewport units get rounded?
(Additionally, I am not resizing my browser window -- yet 100vh returns 616px sometimes, other times 616.36px)
The specification merely prescribes that 1 unit of vw is:
1% of viewport’s width
This ought to be reasonably precise, as 100 of these units should fill the entire width, so rounding will cause problems here.
The CSS definition of number includes integers and decimals see v2 or v3.
In the cases of the browsers that return an integer, if the view port is not coincidentally exactly divisible by 100, and if the result of 1vw * 100 is significantly off - it is worth raising a bug with the browser vendor.
Result of browser test... note that size difference is down to browser chuff and tool size.
Firefox seems to reliably calculate to 4dp:
height: 3.06667px;
width: 6.76667px;
An old version of IE I have lying around similarly reliable, but to 2dp:
height: 3.78px;
width: 6.76px
How are you obtaining your numbers?
I need to make retina images available. I will be using the same sprite generated, but I need to halve its height, width and background-position. I would like to know how can I obtain the separated units from sprite-position($icon-map, $icon-name) to get the units I need to halve them (as obtaining them like so sprite-position($icon-map, $icon-name) / 2 doesn't work ).
If I understand right, this mixin can help you: https://gist.github.com/thulstrup/2140082
This is related to CSS color codes:
For hexcode we can represent 16,777,216 colors from #000000 to #FFFFFF
According to W3C Specs, Valid RGB percentages fit in a range from (0.0% to 100.0%) essentially giving you 1,003,003,001 color combinations. (1001^3)
According to the specs:
Values outside the device gamut should be clipped or mapped into the gamut when the gamut is
known: the red, green, and blue values must be changed to fall within the range supported by
the device. Users agents may perform higher quality mapping of colors from one gamut to
another. For a typical CRT monitor, whose device gamut is the same as sRGB, the four rules
below are equivalent:
I'm doubtful if browsers actually can render all these values. (but if they do please tell me and ignore the rest of this post)
Im assuming there's some mapping from rgb(percentage) to hex. (but again Im not really sure how this works)
Ideally I'd like to find out the function rgb(percentage)->HEX
If I had to guess it would probably be one of these 3.
1) Round to the nearest HEX
2) CEIL to the nearest HEX
3) FLOOR to the nearest HEX
Problem is I need to be accurate on the mapping and I have no idea where to search.
There's no way my eyes can differentiate color at that level, but maybe there's some clever way to test each of these 3.
It might also be browser dependent. Can this be tested?
EDIT:
Firefox seems to round from empirical testing.
EDIT:
I'm looking through Firefox's source code right now,
nsColor.h
// A color is a 32 bit unsigned integer with four components: R, G, B
// and A.
typedef PRUint32 nscolor;
It seems Fiefox only has room for 255 values for each R,G and B. Hinting that rounding might be the answer, but maybe somethings being done with the alpha channel.
I think I found a solution for Firefox anyways, thought you might like a follow up:
Looking through the source code I found a file:
nsCSSParser.cpp
For each rgb percentages it does the following:
It takes the percentage component multiplies it by 255.0f
Stores it in a float
Passes it into a function NSToIntRound
The result of NSToIntRound is stored into an 8 bit integer datatype,
before it is combined with the other 2 components and an alpha
channel
Looking for more detail on NSToIntRound:
nsCoord.h
inline PRInt32 NSToIntRound(float aValue)
{
return NS_lroundf(aValue);
}
NSToIntRound is a wrapper function for NS_lroundf
nsMathUtils.h
inline NS_HIDDEN_(PRInt32) NS_lroundf(float x)
{
return x >= 0.0f ? PRInt32(x + 0.5f) : PRInt32(x - 0.5f);
}
This function is actually very clever, took me a while to decipher (I don't really have a good C++ background).
Assuming x is positive
It adds 0.5f to x and then casts to an integer
If the fractional part of x was less than 0.5, adding 0.5 won't change the integer and the fractional part is truncated,
Otherwise the integer value is bumped by 1 and the fractional part is truncated.
So each component's percentage is first multiplied by 255.0f
Then Rounded and cast into a 32bit Integer
And then Cast again into an 8 bit Integer
I agree with most of you that say this appears to be a browser dependent issue, so I will do some further research on other browsers.
Thanks a bunch!
According to W3C Specs, Valid RGB percentages fit in a range from (0.0% to 100.0%) essentially giving you 1,003,003,001 color combinations. (1001^3)
No, more than that, because the precision is not limited to one decimal place. For example, this is valid syntax:
rgb(23.456% 78.90123456% 0%)
The reason for this is that, while 8 bits per component is common (hence hex codes) newer hardware supports 10 or 12 bits per component; and wider gamut colorspaces need more bits to avoid banding.
This bit-depth agnosticism is also why newer CSS color specifications use a 0 to 1 float range.
Having said which, the CSS Object Model still requires color values to be serialized at 8 bits per component. This is going to change, but the higher-precision replacement is still being discussed in the CSS working group. So for now, browsers don't let you get more than 8 bits per component of precision.
If you are converting a float or percentage form to hex (or to 0 - 255 integer) the correct method is rounding. Floor or ceiling will not spec the values evenly at the top or bottom of the range.