I use a lot of calc() with percentage values (eg. calc((100vh / 8) + 20px)) in my project. So this results in a lot of decimal values (See image). So is it possible that there are not decimals? So 59.63 would be 60. I'm using SASS.
Best wishes,
Joeri
No, it's not possible while you are using relative units (%, em, rem, etc). When rendering they are recalculated to pixels and gets decimals values.
About css units you can read here.
But anyway brouser renders blocks with integer sizes: http://i.imgur.com/8nJe1BE.png In your case the real size of this block may be 60 to 60 pixels.
You can use the round function from SASS :
http://sass-lang.com/documentation/Sass/Script/Functions.html#round-instance_method
Related
I am trying to determine if, using just CSS, there is there a way to format floating point numbers to a specific number of digits to the right of the decimal point?
The reason I want to do this is that I need to use a website that displays a massive amount of continually updating data in tables. (Because the data is continually updating, I can't just export the data into a spreadsheet.)
The values are floating point and range from 0 to 9999. The number of fractional digits varies from 0 to 7. For the most part, I have no use for anything beyond hundredths (2 places to the right of the decimal point). The exception is for values ranging from 0 to 9, but I'm willing to forego that case, if necessary.
This is an tiny example of how the data is currently displayed:
9484.83
133.57643
1344.5432
9.5848274
58.48381
5989.1
1.5847493
1.348
As you can see, it's hard to read the data with that presentation. Ideally, I would like to use a CSS overlay to reformat that data as:
9484.83
133.57
1344.54
9.584
58.48
5989.10
1.584
1.348
If that's not possible, I'm fine with:
9484.83
133.57
1344.54
9.58
58.48
5989.10
1.58
1.34
Using CSS, I can easily enforce a maximum width for the HTML elements displaying the values. I can use em units to try to not get any digits partially displayed (not 100% effective though, unless forcing a monospaced font, which results in much less visible data in the viewport). But even using such techniques, I still wind up with values displayed as 58.4848.
Can CSS be used to solve this task?
I've been looking at this page, as well as this code example and I've noticed that the x_advance, y_advance, x_offset and y_offset fields in hb_glyph_position_t are of the type hb_position_t, which is an alias to int32_t. I haven't found any documentation about which units are used for these fields. The examples above suggest that they're 64ths of something, but that's all I can infer.
Does anyone else know the exact unit implied by hb_position_t?
It is in input font size units (say pixels).
The idea there is you multiply the input font size by 64 then you divide the position by 64 after the shaping so you will be in control of how much sub pixel precision you need.
I have an element that I want to increase in width as its parent decreases in width
The equation should look something like:
width:calc(150 + 500 / 100%);
But at least in Chrome it says the property is invalid whenever I try to divide by percent width.
Is this possible? (Alternatives to calc() are acceptable)
EDIT
I added spaces (didn't realize about that). Tried it with a variety of units, no luck yet.
Fiddle
<div style="width:100%;position:relative;">
<div style="width:calc(150px + (500 / 100%));position:absolute;top:0;left:0;">This one should get bigger as the page gets smaller</div>
</div>
Thought process:
Fixed width (150px) plus 500 divided by the current parent width.
So if the parent is 500px:
150 + 500/500 -> 150 + 1 = 151
Parent is 100px
150 + 500/100 -> 150 + 5 = 155
Parent is 20px
150 + 500/20 -> 150 + 100 = 250
Solution is so simple it's mind-boggling. Move the 500px into the first part and subtract the width.
width:calc(650px - 100%);
Gets wider as its parent gets narrower.
Updated fiddle
It seems like you've found your solution already, but I'll answer specifically why your original code wasn't working:
I'll start with the syntax for a product equation (when you divide) in calc():
<calc-product> = <calc-value> [ '*' <calc-value> | '/' <number> ]
The spec for the calc() property syntax is a bit more complicated than it sounds. When dividing in calc() as you're doing here, the right side must be a number. You cannot use "unit-ed" values:
Number values are denoted by <number>, and represent real numbers, possibly with a fractional component.
When written literally, a number is either an integer, or zero or more decimal digits followed by a dot (.) followed by one or more decimal digits and optionally an exponent composed of "e" or "E" and an integer. It corresponds to the production in the CSS Syntax Module. As with integers, the first character of a number may be immediately preceded by - or + to indicate the number’s sign.
That is to say, you cannot divide something by a percentage value like 100%.
calc() need spaces between the operators ( but just in + and -), but you are missing the units, which could be px, em,rem etc..., so would something like this:
width:calc(150px + (500px / 100%))
This is would be invalid because as explained by #TylerH, you can't divide by un-ed values(px, %, etc).
But if was possible, when you divide by 100% you are multiplying by 1, so basically you'll stay the same because 1 is the neutral value for multiplication, so this would be useless to do.
Hardly to know, because there isn't much to see in your question, and still invalid, but I'm guessing you are looking for something like this instead:
width:calc(150px + (100% / 500px))
Given your Edited question AFAIK you have to use JS to achieve this, unless you could provide a Fiddle.
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.