How is it possible for CSS to recognize a space as a error?
This will work, for example:
height: 50px;
But this doesn't work?:
height: 50 px;
Can someone tell me why this is the case? It was really hard to find this error in my CSS.
The W3C specification states that, for CSS Level 3, all non-zero values must be accompanied by a unit identifier, in this case px. Adding a space after the value is essentially the same as not adding a unit identifier at all. The CSS specification treats a space as an instruction that the browser should stop interpreting that property and move on to a new line or property listing.
body {
font-size: 50 px;
}
is not okay, since the CSS is interpreted as:
What is the element? Body. Interpret according to spec if possible. There's a space; move on to the next line or property. What is the property? Font-size. This property needs a value. What is the value of the font-size property? 50. Interpret according to spec if possible. Move on to the next line or property. Next line says px;. etc. etc.
So your CSS will be interpreted by the browsers in this way. The specification allows for a space or no space between a property and a unit (size:50px; vs size: 50px;), so browsers have a use-case for either of those situations. If there is a space between a unit and a unit identifier (size:50 px;), there is no use-case for that, as it is not allowed by the spec. The browser doesn't understand what to do and moves on; the style is not applied.
CSS doesn't really error. It either works or it doesn't. height: 50 px doesn't work because it doesn't know how to interpret 50 px.
The value (50 in this case) and unit (px) should be next to each other withour any space in between. But the space between 50 and : is not important and is just for decorative purposes.
height: 50 px;
Doesn't work because the browser doesn't know how to interpret it. Browsers interpret CSS according to the specification...
Just because its a space doesn't mean its okay to put it there. For example what if you did this in PHP
$var iable = 1;
Regardless of if you think its right or wrong you have to code to the specification no matter what language you are using
Related
I'm trying to style the kbd buttons to have all the same min-width, based on the font size of the element.
kbd {
min-width: 1.5em;
}
The problem is that it works for all the symbols I've tried, except for ⌃...
It has a different min-width:
Why that? How can I fix it?
They're all the same size, the 1.5em that you specified but the caret (ctrl) is a narrower character than the others. If you set the buttons to have a width of 1.5em instead a font-size, that'll make them all the same size.
Give me a shout if this doesn't work and I'll see what I can do to help - might be worth setting up a JSFiddle to play around with.
I am not 100% sure about this but what i would suggest is that all the other buttons have the same "character size" or rather the same distance after and before the character and the "^" has another one. This would mean with another font it could also look different again.
Look at following picture:
It seems like all the other characters/symbols are like the a and e on this picture, they just have the same width. Your "^" is like the f for example. It's not as wide as the others even if it has the same font-size.
I would suggest you not using width instead of min-width so you can be sure they all have exactly the size you gave them.
I have a project where IE9 is the minimal compatibility browser. That means that I can use the rem unit.
In my experience on large projects, involving many dev, the use of "em" creates quite a mess. I do not say that it is bad in itself, just that it seems to "naturally" happened on over time, when there is different people with varying skills working on a project. Dom elements tend to pile up, and that do not work well with the compounding behavior of "em".
After having looked at a lot of resources online, it seems that there is a lot of cargo cult on the question.
there is the temptation of solution 1:
start with this (suggested here css3files.com comment - David Buell ):
solution 1 :
html { font-size: 10px;}
body { font-size: 1.3rem;}
Rem for anything text-related and px for the rest.
But even though, I am not sure where I am really contrained to use another unit than "rem". I did some zooming test, and did not notice differences between "rem" and "px". The advantage of "rem" over "px" seems to be that "rem" will be relative to the a size set with "%" on the body, and this allows to change all text sizes in one line for a specific breakpoint.
Default text size change IS seemingly an issue, since "px" and "rem" text remains unchanged. But I wonder is there is usage statistics about this (this SO user thinks nobody). If it is really used then, I think I should drop the "easy math" font-size definition on the html tag.
solution 2 :
body { font-size: 0.8125rem;}
That gives 13px size with the browsers default size of 16px - and users can still change the default setting. (and maths aren't that hard starting with 16)
What I am really unsure of is the case of different screen resolution, and the case of different pixel density (which I know can be changed on windows).
to sum up:
No need to accomodate anything below IE9.
reponsive design.
handle zoom well.
handle user text size change if that's really used.
no magic, as barebone as possible (I use a css preprocessor but I want to avoid crazy use of it).
I think many frontend developer adapt their interface to browser zoom. But what is the practice with text-only zoom ? Its a somewhat more hidden browser feature. How many devs actually test it and code for it ?
I see that SO supports it but that it sorta breaks beyond a certain scale.
What the right base setup for a IE9+ interface, that supports responsive web design?
keep a rule - All font sizes must be specified using rem only with a pixel fall back. Do not use percentages, ems or pixels alone.
font-size: 14px; /* pixel fall back rule should come first */
font-size: 1.4rem;
more infor - https://github.com/stubbornella/oocss-code-standards
I did some testing here : http://codepen.io/Olivvv/full/aGDzI
a few interpretations :
solution 1 : WRONG
html { font-size: 10px;}
prevents the permanent browser/user font-size setting to be applied. If the user has requested a bigger font-size,it should take effect.
See here with the SO website, things break a little with very big fonts, but at least the user gets the font-size increase.
solution 2: OK
body { font-size: 0.8125rem;}
is actually the same as
body { font-size: 0.8125em;}
since the can only inherit from the element "em" as the same value as "rem" ("rem" stands for root em, the em value of the root element, i.e the element)
solution 3: INTERESTING
html{font-size: 62.5%;}
body{font-size: 1.6em;}
---> 1 rem == 10px
(if the browser is set to default, i.e 16px; - (62.5/100)*16 == 10)
Now about the possible strategies :
1. rem only
html{font-size: 6.25%;}
body{font-size: 16em;}
+ only working with rem; for font-size, width, padding, margin, borders. This seems to be the easiest way to go.
Here 1 rem equates to 1px in defaut setting. It responds to user change of the default setting, so it is accessible.
When doing responsive design, the interface can be zoomed by changing the % value of the . for instance:
html
the whole interface is zoomed. Zoom is vertical and horizontal.
div.foo{
font-size: 16rem;
border: 16rem solid;
width: 350rem;
border-color: limegreen;
}
That will create a box that expands both vertically and horizontally.
Issue: What about vertical zoom ?
2. rem and em (in order to get vertical zoom)
rem -> interface elements, width essentially
em -> text (can be resized independently from interface elements (which are in rem) by changing the font-size value on the body)
px -> seperators, borders essentially
This way we achieve interfaces that respond well to both browser zoom and browser font-size setting
Some comments on ideas read on some blogs and
"just use px, if your brain works in pixel" --> Very Wrong. Font-size in px will be unreadable for some users who have explicitely requested bigger font size. (and what about dpi different from 96 ?)
"layout in em" --> average wrong, since a different user font size will make appear horizontal scrollbars or not use the full viewport space. Such behavior relates to zoom, not font size. (note that I am not considering browsers older than IE9 - just let them fall back on their default values )
How to balance a decent font-size regardless of the media (small vertical phone screen or full page printing) and a comfortable 40~80 char per lines using the current CSS best practices?
I think I know the drill for regular screens, set body's font-size to some percentage, mark your main content element with width being 70em and min-width 40em...
but then, i know nothing about the accepted standards for mobile and print for this problem.
All my search attempts take me to (now) futile discussions from 2002~2011 about the benefits of [em,pixel,%,pt] over the other...
body {
min-width: 16em;
min-width: 40ch;
max-width: 28em;
max-width: 70ch;
}
Use the ch unit for “width of a character”, and back it up with a setting in em units, with a numeric value that is about 40% of the desired number of characters.
The em unit means the size of the font. For texts in Latin letters, this is about 40% of the average width of characters, maybe a little more.
The ch unit means the width of the digit 0. It is generally the best available approximation for “average width of characters” in CSS. It is supported by modern browsers, but for less than modern browsers, set first the width in em units.
This answers the question in the heading of your message. The body of the message is vague and does not pose a question that could be addressed constructively.
Setting a page width relative to the character size would only make sense with a monotype font. Consider these two strings "iiiiiiiiii" and "WWWWWWWWWW" - both consist of 10 characters, but clearly require a container of different width!
You could play around with ex/em/ch units, but they would not give you full control to accomplish what you're trying to do. Also: ch isn't even fully supported!
Fiddled sample
Say, I have the following CSS rule defined:
.className {
font-size:0.89em;
}
My question is, how "deep" into fractions can I go while specifying 'em's for browsers actually to support it and for the font size to be rendered differently for a small fractional change in the em's value?
JohnB is right. We're still rendering in pixels whatever the size unit we use, and small changes in ems will not change the displayed size:
For example, for text originally displaying at a height of 20px*, we can see that there is no effective change when a rule is added to make it .99em of its original height:
20 * 0.99 = 19.8
The browser can't display .8 of a pixel, so (assuming it will round up) it will still display it as 20px high.
Though it appears that browsers do not always round off as expected:
http://meyerweb.com/eric/thoughts/2010/02/10/rounding-off/
http://ejohn.org/blog/sub-pixel-problems-in-css/
*Yep, I know a font-size of 20px doesn't alway mean it's displayed at 20px!
It should be kept in mind though, that fractional em values, like all floating point numbers, are susceptible to rounding error.
I found that out while setting my media query boundaries, where one max-width was 0.00001em away from another min-width, and it was rounded up and both queries were activated. After changing the difference to 0.001em the queries worked as expected, exclusively.
Is it good to add line-height in body{line-height:1.5} or it would be better if i add separately for tag by tag like p{ line height:1em} etc.
Edit:
body {line-height:in em} create problem with if we put image with float inside
Edit: 24 April 2010:
If i have to add different line heights to elements
like
p {line-height: 1.4}
h1 {line-height:1.6}
h2 {line-height:1.2}
ul li {line-height:1.1}
then shouldn't i use line height in body {line-height:1.4}
if body {line-height:1.4} and h1 {line-height:1.6} then what would be line height for h1?
It just depends. If you put it in the body then you get to be lazy and not worry about ever doing it again, but your going to lose control because everything on the page will have the line-height set to 1.5. Whereas if you declared it in each tag, you gain lots of control, but will have to do more work.
Personally I would go for the tag-by-tag solution, but I'm a control freak, so...
A word of caution on putting line-height on the body tag:
If you specify a height in percent, you would intuitively expect to enlargen / shrink all line-heights (e.g. 50% shrink to half, 200% duplicate space, 100% nothing happens).
body {
line-height: 120%
}
This is not the case. For paragraphs and normal-sized text it works fine. But for headings it's a disaster, since the same line-height as for normal text gets applied... See what happens here: https://jsfiddle.net/11jgwzzu/ .
It works, if you use for example 1.5 instead of 150%.
With this in mind, I think it's quite okay to use something like this:
body {
line-height: 1.61 // Golden Ratio
}
to make the entire page a bit more spacious. You can still overwrite this behaviour for some specific elements if you want to, but I often find I don't even have to overwrite it since I think line-height: 1.61 looks pretty good everywhere.
The obvious answer is specifying it once in the body is less work (and overhead).
There is a definite CON: if you use a unit (like 'px') in the line-height, and you specify it on the body, it will be used like that throughout the page. This may create crazy results with fe big page titles overlapping eachother or tiny aside text getting ridiculous whitespace between lines. If you dont use a unit, and specify it nowhere else, the vertical rythm of the page becomes messy.
Read this: http://www.alistapart.com/articles/howtosizetextincss/
Specifying a unit (in this case, px) when setting the line-height
enables the value to be inherited throughout the page. If a unitless
line-height had been specified, the multiplier would have been
inherited, resulting in line-heights being rendered proportionally to
the text size, thus breaking the vertical rhythm.
It is common in websites to never use a unit on line-height, which is one of the reasons why the most websites look a bit messy, designwise. Just look at this page, already :-)
I would specify a unitless line-height on the body element, and use a unit-based line-height on a designated 'content' area where you know exactly what sort of content to expect (the 'content body').
*-pike
put it where it's appropriate
if you want line-height: 1.5 on everything within the body, put in on the body
if you only want line-height: 1.5 on everything in the main content area, put it on the div id="MainContent"
etc.