I would like to have a uniform font-size everywhere. This is not the case right now and I do not know where the bug is.
For example the font size here in page 1 is different from that in page 2. (I do not need to target IE8 and lower. My target audience is Mozilla Firefox, Opera, Chrome, and Safari.)
By the way, what is main copy?
Open up style.css in any text editor.
Find all font-size rules.
Delete them all.
Create a new rule: body { font-size: size; } where size is the value you want.
Related
I'm sure that css code is correct. But Firefox cannot understand and display it.
Here is case 1 within css:
.fa-circle:before {
content: "\f111"
}
and here is another case:
.fa-group:before,
.fa-users:before {
content: "\f0c0"
}
Can you tell me how to fix it? Thank you!
Sounds to me like your pseudo-element's containers (the i and span elements) are having their font properties overridden by something else.
In Firefox's element inspector you should see the following inherited styles:
Importantly the font-family property should not have a line through it - if it does, it means the font being used isn't Font Awesome. If that is the case you'll instead see:
If this is the case, the font being used isn't Font Awesome and the requested character code doesn't exist in the other font's character set.
Its about Print, and Print only.
css:
#page {
size: A4 portrait;
}
#page :first{
size: 210mm 1000mm;
}
As CSS defined, should only first page with 1000mm height and rest pages are 297mm (A4) height.
But in Chrome, from second page, looks like 297mm but all content is gone.
Try it yourself, use Google Chrome, open http://fiddle.jshell.net/T4nnG/1/show/
and try print, see the preview, first page is right, and from second page, size is right, but content gone
You can see more clearly by use "save as PDF", but if you choose a real printer, it will shrink first page, the bugs are same
It may only in Chrome, but I am only use the app for Chrome, so as long as it works in Chrome, I am happy.
Am I done something wrong? Please advice on correct CSS, thanks.
Verified with a lot of trials, so this is the summary of my trials,
While printing the page, there two things happening - Calculation of layout content and actual rendering of the layout with content
#page :first breaks the first part, calculation of the layout in Chrome. The :first properties are used for calculation for other pages even if there are overrides. But Chrome uses the correct values for pasting content in the wrong layout.
For eg: #page :first if size is x, then then the number of pages is calculated based on x, the amount of content in each page is based on x. When it comes to putting in the content, Chrome realizes there is an override and changes the layout to overridden properties, but does not change the calculation of content or pages. Hence the issue. This is very clear if your case is reversed like so,
#page :first{
size: A4 portrait;
}
#page{
size: 210mm 1000mm;
}
You will see that the page heights have been updated but not the content.
Tried with page-break-*, !important rules, but nothing worked.
Tried alternative tools which can be used server side, like
http://www.princexml.com/releases/9.0/ - Not working. Rather breaks further by not calculating content or layout size correctly.
After a bit of searching, found this #page :first { margin: ... } in Chrome bug? Similar to your problem. But unfortunately, same findings here too.
This is a bug in Chrome. Filed a bug report with your case at https://code.google.com/p/chromium/issues/detail?id=355116. Please star it in case you want to follow it.
So to answer your question, your CSS is fine. But Chrome has bugs. You can only wait for them to fix it. Or modify the way you are generating the print. Hope this helps!
Add this to your CSS:
#media print
{
div{
page-break-inside: avoid;
}
}
Does that fix your issues?
I've began working on a new site using REM units with PX fallbacks. Now, I have a question that may be silly, but I can't find anything specifically mentioning it so I'll just go ahead and ask here.
Using property shorthands and specific properties seems to both load take effect in the browser Chrome.
body{ font:16px/23px sans-serif;
font-size:1rem;
line-height:1.438; }
whereas using both shorthand or both specific properties cancels one or the other out (e.g. uses primary or fallback, not both)
body{ font-family:sans-serif;
font-size:16px; font-size:1rem;
line-height:23px; line-height:1.438; }
or
body{ font:16px/23px sans-serif;
font:1rem/1.438 sans-serif; }
Now which is exactly best practice here? All examples validate.
Is there a reason why the shorthands AND specific properties both load in the browser Chrome even though they're targeting the same properties? Are they actually both loading?
Does this have any adverse effects to how the browser/device is rendering the styles?
I've only looked into this via Chrome and I haven't been able to discern any differences through testing. But, You can see how it would be a little bulky if you HAD to use two iterations of the same code for all elements using rem's.
UPDATE:
Tested only in latest versions of all browsers below, all tests pertain to the first code snippet
In Firefox this doesn't seem to be an issue, it just replaces the font-size/line-height in the shorthand code with the rem sizing.
In IE, safari, & Opera it takes the shortcode and separates it into specific properties, but still loads the rem units ignoring the px units.
It seems to be specific to Chrome, at least in modern versions. So the question now, how to figure out how Chrome is handling it? The image, displayed at the bottom of this post, may explain a little more. See how BOTH font properties are loaded and neither are ignored or take precedence?
UPDATE#2:
When using margins, Chrome acts properly. I'll use the following "off the wall" example to demonstrate:
margin:16px 0 19px 0;
margin-top:1rem;
margin-bottom:1.188rem;
reads in chrome as:
margin:1em 0 1.188rem 0;
(source: leftdeaf.com)
This two resources will answer all of your questions:
http://snook.ca/archives/html_and_css/font-size-with-rem
http://blog.typekit.com/2011/11/09/type-study-sizing-the-legible-letter/
With line-height, use the unit, but not the value:
body {
font:16px/23px sans-serif;
font: 1rem sans-serif;
line-height:1.438;
}
or
body {
font-size:16px/23px;
font-size: 1rem;
font-family: sans-serif;
line-height:1.438;
}
You can't use FONT and FONT-SIZE, just use one or the other. Otherwise the browser will attempt to use both.
After a lot of wasted time and confusion... It actually does render correctly in Google Chrome. feeling silly now... I overlooked the drop-down arrow to the sub-properties in the Chrome Tools. Image displays what I overlooked. Example shows multiple examples of shorthand properties and specific properties, more importantly it shows the font property working, it wasn't crossed out but it was still being overridden. Not sure why it doesn't comply with the strike through like everything else, probably due to the font-weight, variant, style properties remaining unchanged. But it works.
Trying to implement this gallery on my website.
http://coffeescripter.com/code/ad-gallery/
It is noted in the css file that the next and previous buttons won't show up in IE6 unless a nonexistent background image is applied to .ad-gallery .ad-image-wrapper .ad-prev, .ad-gallery .ad-image-wrapper .ad-next. The code they used is invalid, but it works. I have also tried using a color instead and it does work, but not what I wanted.
I don't want to point to a nonexistent image file or a blank.gif if possible. Does anyone know what causes this problem in IE6 and if there is a pure css workaround? zoom: 1 does not work in this case.
I presume your IE6 requirement is referring to the following snippet from the jQuery AD Gallery plugin's stylesheet, jquery.ad-gallery.css:
.ad-gallery .ad-image-wrapper .ad-prev, .ad-gallery .ad-image-wrapper .ad-next {
/* Or else IE will hide it */
background: url(non-existing.jpg)\9;
}
The \9 at the end of the background shorthand rule is actually a CSS Hack targeting IE6, IE7 and IE8 — not just IE6.
Note: Paul Irish wrote a Comprehensive List
of Browser-Specific CSS Hacks back
in 2009 which highlighted this
attribute parsing bug in IE/Win:
/* IE6, IE7, IE8 */
#diecinueve { color: blue\9; }
If you don't want to use a 1 pixel transparent spacer.gif or non-existent file for IE (which would throw a 404 error), just modify the CSS to re-use one of the existing images in the gallery but specify the background-position's X and Y property to be off the screen:
.ad-gallery .ad-image-wrapper .ad-prev, .ad-gallery .ad-image-wrapper .ad-next {
/* Or else IE will hide it */
background: url(ad_next.png) no-repeat -9999px -9999px\9;
}
This creative work-a-round will allow IE 6-8 to display the previous and next links, but won't actually show the specified background image file, since the X and Y values position the background completely off the screen.
Don't support Internet Explorer 6. It's over 10 years old. Recommend your users upgrade Internet Explorer or switch to a different browser. Problem solved!
I have a text item on a web page that appears too large in opera browsers. Is there a way to edit text size and other aspects of the css for only opera?
check out this link (scroll down to the part about Opera)
Here
(I never knew this but...) apparently you can use:
#media all and (-webkit-min-device-pixel-ratio:10000), not all and (-webkit-min-device-pixel-ratio:0) {
.operaSpecificStuff { }
}
Opera has a bug in font size defined by em or %. Just reset the font size like this:
body { font-size: 16px;}
Opera doesn't allow for font-sizes smaller than 10px – which results in having bigger fonts on small texts in Opera only. This is intended by design as this setting can be changed by the user only.
See the following thread: http://forums.devshed.com/css-help-116/force-opera-to-use-font-size-less-than-10px-or-763589.html