Under the "Rules" tab I can see styles that are either directly assigned, inherited or styles that come from "User Agent Stylesheet". As you can see there is no line-height set in here. However, when I switch to the "Computed" tab, I can see the line-height is 47px. Why is it and where is it coming from? Shouldn't it be located under the "Rules" tab somewhere in the "User Agent Stylesheet"? I don't quite understand how all those rules are categorised, I thought that "User Agent Stylesheet" shows all the default styles for a particular element. However, it looks like this is not the case. Thanks in advance for clearing this up for me.
Why is line-height not appearing under Rules tab?
The line-height is not shown in the Rules tab because it is not part of default user-agent stylesheet for h1 tag. Safari's default user-agent stylesheet can be found here.
h1 {
display: block;
font-size: 2em;
-webkit-margin-before: 0.67__qem;
-webkit-margin-after: 0.67em;
-webkit-margin-start: 0;
-webkit-margin-end: 0;
font-weight: bold
}
All properties that you see as defined under the h1 above are being shown in the Rules tab because they are part of the User Agent's default stylesheet.
However, the line-height is not a part of it and hence doesn't get shown in the Rules tab.
Why is it getting displayed under the Computed tab when it is not part of UA stylesheet?
Since there is no value specified for line-height, the default value as specified in the spec (which is normal) is used. The W3C spec says the following:
A value of 'normal' sets the 'line-height' to a reasonable value for the element's font. It is suggested that UAs set the 'normal' value to be a number in the range of 1.0 to 1.2.
As you can see the specs there place importance on two points which are:
The line-height is set to a reasonable value for the element's font. So, the font used plays a key role in determining the line-height.
The spec only suggests that UAs use 1.0 to 1.2 as a value and not mandates. This means that each UA can determine a number that it finds reasonable for the element's font.
So, each UA computes the value for line-height as it deems appropriate. Since the UA is actually computing the value instead of picking it up from a default stylesheet, it is shown under Computed tab.
Why is it showing a value of 47px for base font-size of 32px?
As I had mentioned earlier, there is no fixed computation logic for line-height. For the default font, when I set font-size as 2em (32px) and the line-height explicitly as normal, the value that I get is 37px (which is roughly equivalent to line-height: 1.175).
But when I use the Indie Flower (Google font) that you've used on body, the computed value for the line-height is equivalent to 47px. You can see this in the below snippet where I have added three h1 tags - one with no line-height setting, one with line-height: normal and another with line-height: 47px. All three are the same height. So, it seems like UA determines that such a big factor is required for this font unlike others.
h1 {
display: inline-block;
font-size: 2em;
-webkit-margin-before: 0.67em;
-webkit-margin-after: 0.67em;
-webkit-margin-start: 0;
-webkit-margin-end: 0;
font-weight: bold;
background: red;
}
h1.withnumber {
line-height: 47px;
}
h1.normal {
line-height: normal;
}
body {
font-family: 'Indie Flower', cursive;
}
<link rel="stylesheet" type="text/css" href="//fonts.googleapis.com/css?family=Indie+Flower" />
<h1>Abcd</h1>
<h1 class='normal'>Abcd</h1>
<h1 class='withnumber'>Abcd</h1>
Related
I have some icons that are set via pseudoelement in CSS, like this:
.button a:before {
font-size: 1.3em;
font-family: font-awesome;
content: "*";
}
And there are other, similar declarations elsewhere, like
.button .otherclass a:before {
font-size: 1.35em;
}
This works fine with modern web browsers, but IE >= 9 compounds all the font sizes, so that the resulting icon is enormous (like 5 times its size). How can I prevent this from happening?
(BTW, the actual code with the problem is here.)
This is a bug in IE, as reported on the Microsoft Connect page mentioned by #Aibrean, but the page also shows that Microsoft does not admit that this is a bug (they say they cannot reproduce it). It can be reproduced in IE 11 on Win 7 with the following simple document:
<style>
.foo, .bar:before {
font-size: 2em;
content: "X";
}
.bar:before {
font-size: 5em;
}
</style>
X<span class=foo>X</span>
<span class=bar>bar</span>
The second X should be 5 times as big as normal X, but it is actually 10 times as big in IE, since IE incorrectly multiplies the effects of 2em and 5em.
The workaround, it seems, is to organize your style sheet so that the font size of generated content is set once only for each element. That is, so that there are no two font-size declarations that apply to the same :before or :after pseudo-element.
There is a slightly better solution than using absolute font-sizes, and that is to use rem inside the :before or :after declaration.
em and rem units are based of the default font-size (commonly 16px, so 1rem = 1em = 16px) so if the user changes their default font then your font will change too. However rem units do not compound.
rem support is growing but you can use both (if you don't need compounding):
font-size: 2em
font-size: 2rem
and then those browsers (e.g. IE8) that don't support rem will use em. And as IE8 doesn't have the compounding issue to which you refer, this actually works nicely.
For the life of me I cannot find documentation explaining what the word 'Display' does in the following css:
h1 {
font: 3em 'Display'
}
According to this post about the css font property
http://www.impressivewebs.com/css-font-shorthand-property-cheat-sheet/
the size and font family are mandatory or the rule is ignored.
I thought it must be a built-in font family or something but look at this bin I created:
http://jsbin.com/yuhaw/1/edit?html,css,output
HTML
<h1 class="test1">font: 3em 'Display' </h1>
<h1 class="test2">font: 3em</h1>
<h1 class="test3"> font-size: 3em;font-family: 'Display' </h1>
CSS
h1.test1 {
font: 3em 'Display'
}
h1.test2 {
font: 3em
}
h1.test3 {
font-size: 3em;
font-family: 'Display'
}
If it was the case I would expect test1 and test3 to look identical but they don't. What's going on here?
In the rule h1 { font: 3em 'Display' }, the 'Display' part specifies the font family name. This makes the rule syntactically valid, whereas if it is omitted, the rule is syntactically invalid and gets completely ignored. It does not matter here whether the system actually has a font family named Display. It probably does not, and then the browser uses some fallback font(s), normally its default font.
By the definition of the font shorthand, this rule sets all font properties to their initial values, unless a value is provided for them in the rule. So font-size is set to 3em and font-family to Display and all other font properties to their initial values as specified in CSS specifications. For font-weight, the initial value is normal, so the rule overrides the common and recommended browser default that sets font-weight to bold for h1.
As mentioned, the rule h1 { font: 3em } is ignored (by CSS specifications and in browser practice), so the element is displayed with default settings (in bold and typically in 2em size).
The rule h1.test3 { font-size: 3em; font-family: 'Display' } is valid and gets applied, but it affects only the two specific font properties that it sets. This means that font-weight is bold.
Note: Inheritance has nothing to do with this. This is simply a matter of setting properties on an element, in an author’s style sheet and in a browser’s default style sheet. And the key issue here is the effect of the font shorthand property.
The reason why they are not the same is because for Test3 you inherit all the properties that you do not explicitly set. Every existing style is kept, and you only change the size and the family.
Therefore, Test3 is bold, which is the browser default style for H1.
Test1 is a complete font declaration and resets every unspecified property to a default font. That's why Test1 has a font-weight of normal. You overwrite every font property by specifying a 'complete' font declaration, so the size and family are set to the specified value and the weight is reset to normal, which is browser-default for a font.
In your browser (at least in Chrome), you can inspect the Computed style. In that view, you can also check View inherited properties. If you do that in your fiddle, you can compare all the font properties, and you'll notice those differences.
You can try it. E.g. Google Chrome helps you to see the computed styles using that notation.
element.style {
font: 3em 'Display';
font-family: Display;
font-size: 3em;
font-style: normal;
font-variant: normal;
font-weight: normal;
line-height: normal;
}
As per documentation, you can specify all the font properties in one declaration, using the following notation :
font: font-style font-variant font-weight font-size/line-height|caption|icon|menu|message-box|small-caption|status-bar|initial|inherit;.
there is no such Font Named "Display"
you have to upload the otf to your webserver and enable it that way:
#font-face {
font-family: "Display";
src: url("type/filename.eot");
src: local("☺"),
url("type/filename.woff") format("woff"),
url("type/filename.otf") format("opentype"),
url("type/filename.svg#filename") format("svg");
}
http://www.alecos.it/new/125027/125027.php this link is an example of my problem... I used a png 1x16 for drawing the rows... the rows are visible in the link posted... my question is:
why under IE 6/8, FireFox, Opera, Safari and other browsers the rows are perfectly aligned with the text while under IE 9/10/11 the text do not fit in the rows?
I used a simple css:
/* Style Source Code */
.code {
border-radius: 7px;
border: #6666FF 1px solid;
background-color: #FFF5EE;
background-image: url("../bkg/Bkg_116.png"); /* Horizontal Rows */
background-repeat: repeat;
background-position: 0 10px;
}
/* Style Source Code */
.xcode {
color: #008000;
font-family: 'Courier New', Courier, FreeMono, 'Nimbus Mono L', monospace;
font-size: 13px;
font-style: normal;
line-height: normal;
font-weight: normal;
font-variant: normal;
}
/* Style Div */
.alignment {
line-height: 20px;
text-align: justify;
}
Hope in workround to fix the issue...
here there is my css: http://www.alecos.it/css/alecos.css
I'm not on Windows machine right now but my guess is .xcode(line-height:16px;} would solve your problem, but I must say that this is the wrong way of creating row borders. Why not add:
.xcode td{border-bottom:1px solid #ddd;}
instead of using background image?
Firefox is temporarily outdated unti it's next update meaning that it's browser does not have the ability to process codes in the same manner as other browsers.
.alignment {line-height: 20px;}
Gets over ruled by .xcode line-height normal;
IE aint normal ;)
Besides content tages like h1, p, font all have slightly different margins/paddings around them. So a non responsive img isnt the best way to go.
Would be better if you could wrap each line with a span, div or sinces its a table a tr,td and give those a border-bottom.
Gr.
Kevin
In order to make your text inside .xcode aligned with the horizontal lines, the "code" lines must be distributed vertically. Unfortunately, It seems that you did not understand the meaning of line-height property and use the default value without considerations.
The line-height property
As you can see, the line-height property will decide how much is the distance of two lines of text. In your case, we need it to be exactly 16px inside the whole block of .xcode.
The value of normal value of the line-height property
From the W3C CSS spec, the value of normal value is defined as:
Tells user agents to set the used value to a "reasonable" value based
on the font of the element. The value has the same meaning as
. We recommend a used value for 'normal' between 1.0 to 1.2.
From some online resource like this article or this page, you can see that the real value of normal value depends on many arguments like font size, font family, OS, user agent, ... Therefore, it is recommended that you should use some css normalize stylesheet to set the value of line-height correctly and cross-browser.
About your case
The quick fix here is setting the line-height inside the .xcode class to be 16px (which is the height of the of your background image).
How can I reset the sizes of headings to the default sizes? Here's some HTML that I have:
<h2>Hello World</h2>
Here's the CSS for it:
h2 {
font-size: 16px;
margin: 1em 0 0.5em;
}
/*I'd like to reset that height of 16px and use the default browser height */
h2 {
font-size: 100%;
}
I need to override the old h2 selector and reset the headings to the default size? I've Googled this and it said that the heading sizes were browser dependent and I don't want to hard-code the heading sizes.
This is a really basic question I know but somehow I can't wrap my head around what value I need to use to reset the height.
According to A List Apart, the default body font size is 16px (and this is consisent across browsers).
The W3C recommended default stylesheet shows the h2 size as 1.5 em.
Some simple calculation brings us to 16 * 1.5 = 24px.
So, setting your h2 font-size to 24px should do it.
In general, you cannot set a property of an element to its default value except by not setting the property in any author style sheet. Methods suggested for this are based on misunderstandings or on some assumptions about defaults, but the defaults are browser-dependent.
You can use Normalize.css from the beginning and it'll normalize the heading sizes across browsers:
Normalize.css makes browsers render all elements more consistently and in line with modern standards. It precisely targets only the styles that need normalizing.
For example, here is a fix for the <h1> tag:
/*
* Addresses `h1` font sizes within `section` and `article` in Firefox 4+,
* Safari 5, and Chrome.
*/
h1 {
font-size: 2em;
}
There isn't a way to go back to the browser's default font-size because everyone does it a little bit differently.
When you change the font size on your h2, it will impact the size of your margins as well (since they are defined in em). I suspect you are trying to modify the font-size to 16px in an attempt to match the margins of other elements that are also specified in em. If this is the case, you will need to set your properties differently:
h2 {
font-size: 1.5em;
margin: .75em 0 0.333em; /* (1 / 1.5) 0 (.5 / 1.5) */
}
The default font-size for headers is medium. See here: https://developer.mozilla.org/en-US/docs/CSS/font-size
So you would do:
h2 {font-size: medium;}
Probably the easiest way to have the heading font-size be set back to default is to remove the font-size declaration from the h2 element you already have, so instead of:
h2 {
font-size: 16px;
margin: 1em 0 0.5em;
}
you will just have
h2 {
margin: 1em 0 0.5em;
}
You will also want to check your style sheets for any other spots a h2 font-size might be declared. If you can't or don't want to remove the font-size delcaration you can do the following to reset the font-size for all h2 elements to default
h2 {
font-size: medium !important;
}
The font-size of medium is the default value for all browsers and the !important at the end makes it override all other declared styles. You need to be careful using important though because it makes it much harder to determine how a style is going to cascade through the elements and/or how it is being applied.
Cheers and how this helps.
Source for default value: http://www.w3schools.com/cssref/pr_font_font-size.asp
UPDATE: Please note that I am seeing this issue only in Chrome (latest version). Everything seems to be fine in Firefox.
By definition:
The rem unit is relative to the root—or the <html>—element. That means
that we can define a single font size on the <html> element and define
all rem units to be a percentage of that.
Let me explain my situation with an example...
Relevant CSS:
html {
font-size: 87.5%;
}
body {
font-size: 17px;
font-size: 1.21428571rem;
}
code {
font-size: 14px !important;
font-size: 1rem !important;
}
I am using the !important declaration to override the font-size of inline code.
The thing is, I noticed that the font-size of code blocks is much smaller than 14px, most probably 12px. But if I remove the !important declaration and set the font-size on a specific code element (styling a specific inline code element), the fonts-size is nice and fine at what appears to be 14px.
Does you have any idea as to how !important declarations may affect sizing in rem's? (Especially considering in my case.)
First off !important is lazy coding and dangerous to maintainability. It's toxic and breaks the nature of CSS (the Cascading portion). Avoid it at all costs.
Second:
code {
font-size: 14px !important;
font-size: 1rem !important;
}
Might as well be written:
code {
font-size: 1rem !important;
}
The second rule overrides the first (again, the Cascading nature of CSS)
rem stands for root em, which is the font-size of the top level element (i.e., html)
and what your rule is saying 1 x the em of the html element, with is 87.5% of the browser default.
EDIT:
Your <p> tags have a font-size of 100% inherited from the parent element which is eventually inherited from body and body has a 1.2142857rem which is roughly 17px This is why you're seeing a difference in font sizes, which is also exacerbated by the the difference of monospace and sans serif fonts.
Okay, the issue was with (1) font-family not defined for code and pre blocks, which meant Chrome and other webkit browsers chose some monospace font that appears smaller (2) line-height was smaller (almost equal to the font-size).
Fixing these two has solved the problem.
I have no idea why Chrome Dev Tools Web Inspector's "Computed Style" shows 11px as the font-size (also applies to any webkit browser, including Safari). I can confirm that it's showing the wrong value because by changing the font to Arial I could easily tell that it's 14px.
Also, after setting the font-family on code and pre blocks, Chrome now shows the correct computed font-size value.