Please take a look at my site: http://burnett.inigowebdesign.co.uk/local_area
I am using Twitter bootstrap CSS (with HTML5 Boilerplate), Modernizr, and Google fonts using #font-face.
I am using modernizr to test for a browser's support of fontface- it not supported, I need to change the font-size (otherwise it will be far too large)
I am testing the site for compatibility and have noticed in IE8 (and early versions of Safari & Opera) my rules for font-size are being ignored. In particular, the h3 elements in the main list (that you can see on the left in the green box) don't seem to respond to any CSS I apply to them. I am using Firebug to inspect the rules, and can't find any possible conflicts. It even ignores !important. In fact, the only way I can style them at all is to use inline CSS.
What is going on??
The text is differ due to different font-size define in each css file.
In normalize.css h3 have 1.17em font size and in fontface.css font size define 50px . It might be possible the browser rendering the file in some different orders.
normalize.css file using this property.
h3 {
font-size: 1.17em;
margin: 1em 0;
}
fontface.css file using this property.
h3 {
font-size: 50px;
/* letter-spacing: normal;
font-weight: normal;*/
line-height: 36px;
}
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.
I'm working on mobile first framework. The project has a broad range of requirements, with a mass of browsers and devices over various locations to cater for.
One of my key locations to target is India, where the browser and device usage trends differ greatly to that in the UK or US.
India browser usage
http://gs.statcounter.com/#all-browser-IN-monthly-201301-201312-bar
UK Browser usage
http://gs.statcounter.com/#all-browser-GB-monthly-201301-201312-bar
The browsers that I need to target for india region are opera, android, uc browser and nokia, but each of those have their little quirks. With that the range of devices differ
Opera mini - does not support rems
Android (prior to chrome) v2-v4 has problems with both rems and ems
http://www.quirksmode.org/css/units-values/mobile.html
-- Am I right in assuming that more recent versions of Android come pre installed with Chrome and the OS web browser?
I'd ideally like to use rems, as it removes the issues of nested content inheriting the em scale of its parent element. However based on the research on http://www.quirksmode.org, I need to have a fall back set.
So I'm going to need to declare a px value.
For example, can I do this:
h1 {font-size: 24px; line-height: 30px; margin-bottom: 10px; font-size: 1.846rem; line-height: 2.308rem; margin-bottom: 0.769rem} /* 24px / 30px / 10px */
Or do I have to do something like this?
h1 {font-size: 24px; line-height: 30px; margin-bottom: 10px}
h1 {font-size: 1.846rem; line-height: 2.308rem; margin-bottom: 0.769rem} /* 24px / 30px / 10px */
Or is there something else that is better?
I have seen a few js poly-fills, such as https://github.com/chuckcarpenter/REM-unit-polyfill, but there maybe cases where JavaScript is not enabled so this won't work.
Additionally I am try to focus on performance, so I want to keep the number of requests to a minimum and the keep the css a clean as possible.
Thanks
Both of your style declarations will work fine. CSS renders code in a cascading fashion, this means if one value is declared after another, the latter will be used. If a browser can render px but cannot render rem, the rem values will simply be ignored. If a browser can render both px and rem, the latter of the two will be used:
h1 {
font-size: 12px; /* 1. Font size set to 12px */
font-size: 1rem; /* 2. Font size set to 1rem, overriding previous value */
}
In this example, rem will be used on browsers which support that unit, and px will be used on those which do not.
h1 {
font-size: 1rem; /* 1. Font size set to 1rem */
font-size: 12px; /* 2. Font size set to 12px, overriding previous value */
}
In this example, px will be used on both browsers which support rem and browsers which do not.
Can I Use... will give you a better overview of which browsers support this unit.
As for performance, each character contained within a CSS file equates to 1 byte. The more bytes contained within your stylesheet, the longer it will take a browser to download it. So of course, adding px values alongside rem values will ultimately add to the download time, but most of the time this is negligible.
As for whether Android devices come bundled with Chrome: no, this is not the case. This is entirely up to the manufacturer.
Either style declaration will work for you - if a browser doesn't support rems it will fall back to the pixel value.
This is one of those situations where I set the html font-size to 62.5% to take the base font-size down to 10px. This makes the calculations very straight forward and is easy to spot errors in your type declarations.
html {
font-size: 62.5%;
}
body {
font-size: 14px;
font-size: 1.4rem;
}
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).
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.
There are buttons on my website that look overly skinny in Chrome compared to Firefox. The button's HTML looks like: <button name="shutdown" type="submit" value="df" class="boton"> Press </button>
My CSS attempt looks like:
.boton {
font-size: 17px;
color: #000;
background: #ee3333;
background: rgba(225, 50, 50, 0.6) !important;
font-family: lucida console;
border: 1px solid #FF4444;
padding: 2px;
-moz-border-radius: 7px;
border-radius: 7px;
cursor:pointer;
}
.chrome .boton
{
padding: 5px !important;
}
I'm not sure if I'm doing this right. ".boton" does indeed change the style of the button, but the padding doesn't change in Chrome. What's wrong here?
The reason that the padding isn't applying to the element is due to the fact that there is no chrome class assigned to any element. There are various hacks around certain Vendor-Specific styles, see this article, but no browser applies a class of .chrome or .moz or anything like that.
However, to achieve more "horizontal" padding, you can use the -webkit-padding-start(padding-left) and the -webkit-padding-end(padding-right). Currently I do not believe there is full padding, or vertical padding for these yet. Be sure when using these to write the -webkit-padding-start, or whichever rule you use, after your padding rule. Otherwise the latter will overwrite the former and both will be lost.
Unless you've also added some browser sniffing that adds the class .chrome etc. to the body that class has no effect.
On the other hand the box model of Firefox and Chrome is not radically different, but the defaults for padding, border, margins etc. may be different. Just explicitly set those values and they should most likely render the same (give or take a few pixels because of different rounding errors). You should not need to add custom css for each browser (but if you use experimental css features like -moz-border-radius and -webkit-border-radius with vendor prefixes you should use all of them in at the same time; the others will ignore the unknown properties).
The different versions of IE (Internet Explorer) do have a radically different box models, and if you cannot get some version of IE to render something correctly with the standard css you should use conditional comments to include IE specific css overrides after the main css file.