I put some css through the w3 validator (I know it's kind of pointless since it balks at css3) but I found a couple things that I was trying to fix that could have been wrong.
This was one of the errors that it found, but I don't see anything wrong with it. Maybe you guys can see something I don't.
The error that it's giving is...
Value Error : font / is not a font-family value : bold 3.7em / 0.82 Impact,Charcoal,sans-serif
The code is...
font:bold 3.7em/0.82 Impact, Charcoal, sans-serif;
JJ
I think am fairly sure this must be a bug in the validator (you're not the only one with the problem) since I pulled one of the examples off from the official specifications on this, and it got the same error.
I validated this:
* { font: bold 3.7em/0.82 Impact, Charcoal, sans-serif; }
p { font: x-large/110% "New Century Schoolbook", serif } /* from specs */
And got this:
Sorry! We found the following errors (2)
URI : TextArea
1 * Value Error : font / is not a font-family value : bold 3.7em / 0.82,Impact,Charcoal,sans-serif
2 p Value Error : font / is not a font-family value : x-large / 110% "New Century Schoolbook",serif
Sources:
http://www.w3.org/TR/CSS2/fonts.html#font-shorthand
http://jigsaw.w3.org/css-validator/validator
The jigsaw css validator is not perfect. It's software, so it contains bugs. Best thing to do in these cases is to inspect the specifications on the subject and try to validate sample code and if it does validate in that case, try and see how it is different from your own.
The bug was reported May 3, 2012, in the W3C CSS Validator’s mailing list. No response yet, and I would expect it to take several days, maybe weeks, before the bug gets fixed. It is probably related to their rewriting some parts of processing property values related to fonts, in which process some other bugs have arisen too (now fixed).
Either wait for the developments and check this kind of parts of your CSS code manually, or use individual font properties instead of the font shorthand. CSS shorthands are generally risky, not due to browser bugs (any more) but due to conceptual difficulties and people’s tendency of making mistakes with such constructs with complicated semantics and syntactic specialties.
It is hardly useful to rewrite bulks of existing code for such reasons, but for individual rules and for new code, it is probably better to avoid ´font:bold 3.7em/0.82 Impact, Charcoal, sans-serif;´(even though it is conforming) and use individual properties instead:
font-weight: bold;
font-size: 3.7em;
line-height: 0.82;
font-family: Impact, Charcoal, sans-serif;
The main reason why people use font shorthands is probably that they use the same settings in many places, in several rules. It is generally possible, and better for maintainability and code readability, to write the settings once and use a suitable list of selectors in the rule, covering just the elements needed.
Related
I've browsed the other posts on this subject here, and still can't seem to figure this out. Why is this syntax showing up as invalid and being ignored in Chrome?
a, a:active, a:visited {
font: uppercase 400 1.175em "Lato", sans-serif;
}
From the W3 Spec
The 'font' property is, except as described below, a shorthand property for setting 'font-style', 'font-variant', 'font-weight', 'font-size', 'line-height' and 'font-family' at the same place in the style sheet. The syntax of this property is based on a traditional typographical shorthand notation to set multiple properties related to fonts.
I've tried almost every variation of this I can think of. I've tried simplifying it down to just 3 properties with no dice.
What's going on? I'd love to use the shorthand and save a little load time, but I'm starting to think it's a best practice to just avoid it altogether.
UPDATE: The problem was "uppercase". Can't set 'text-transform' properties in the font: shorthand. I confused 'font-variant' with 'text-transform'.
The quote from the W3C doesn't mention text-transform.
Remove the uppercase from the property and the syntax will be valid.
I was wondering if someone could point me in the right direction. I am looking to display the Google Font Orbitron at consistent weights at every given font size. Sounds pretty easy, right? Not in my scenario. At certain font-sizes, some characters have multiple weights within the same character.
Note: I am testing this in Windows 7, Chrome v27
The Code:
<link href='http://fonts.googleapis.com/css?family=Orbitron:400,500,700,900' rel='stylesheet' type='text/css'>
.sixteen{
font-family: Orbitron;
font-weight: 400;
font-size: 16px;
line-height: 22px;
}
.nineteen{
font-family: Orbitron;
font-weight: 400;
font-size: 19px;
line-height: 22px;
}
<h4 class="sixteen">Home of Front End Developer and</h4>
<h4 class="nineteen">Home of Front End Developer and</h4>
Here is a fiddle to explain my issue. If you take a look at the fiddle, you'll see in the first line that the top line of the uppercase F, E, and D characters have more weight/thickness than the rest of the characters in that line. But as you'll notice on the next line, that
In case you cannot replicate what I'm seeing, here's a screenshot:
My question is two-fold:
What would the best way to technically describe this? 'Multiple font weights in one given character' lacks brevity, and isn't likely to have any valuable Google results.
Is there a way to fix this and make the weight consistent in every character at every font-size?
What you describe is as such just variation of the visible width of strokes in glyphs, or stroke width variation to put it briefly. Such variation is normal in serif fonts and also appears, at least to some extent, in many sans-serif fonts. However, in this case, the font is designed to have a rather constant stroke width, so the visible effect is caused by font rendering differences.
There is no way to remove the font rendering differences. Font rendering is a complex issue, and although some proposed or experimental CSS settings might affect some aspects of it, it’s basically outside your control. For example, font smoothing (also known as anti-aliasing) depends on the operating system and its settings as well as the browser and its settings.
I've found this issue with a bunch of fonts used online when you go down to a certain size. It's the way the font is being anti-aliased.
You can see the same issue from Google showing off that font: http://www.google.com/fonts/specimen/Orbitron
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.
I would like to use different fonts in my web application. As their size are not equal, I want to do something in CSS like this pseudo-code:
if (exists(font1))
{
font-size: 9pt; font-family: font1;
}
else
{
font-size: 12pt; font-family: font2;
}
Is it possible? What's the best and correct solution for it? How can I define font-size for a certain font and define another font-size for the next one ?
CSS generally does not have conditions or other dynamic structures.
Your problem is solved through the use of so called "font stacks". You declare font-family with a list of comma separated fonts-names. The client browser now picks the font from that list which he has available. That's why the creation of good font stacks is a tricky task (because they should look similar or at least have similar letter spacing / line-height). If you google for Web font stacks you will get some good articles about that topic from professional font-guys who already did the work for you creating nice font-stacks.
An alternative nowadays is to provide the font you want as downloadable font via the #font-face declaration. However keep in mind that:
you need several formats to support all browsers
they add additional weight to the page load which might be relevant for mobiles
You need the right to use the font or use a free font (Google offers a service where you can pick from a variety of free fonts)
You can use javascript statements for that.. or you can assign different id's for your text. For Eg:-
<div id="font1"><p>Some Text</p></div>
and then in your css file :-
#font1 p{
font-family:sans-serif;
font-size:10px;
}
so you can assign different fonts to different texts in your web application pretty well...
My site displays just like I need it to in IE and Opera, but in Firefox I can't use CSS to get font sizes smaller than Firefox's default minimum-font-size. Of course, I can go to Tools → Options and remove this value, but some users will see some of the elements displaced.
I have tried using !important, but it doesn't work, and I can't substitute the images for the text since they are dynamic fields.
Okay. I'm going to explain how you do this, but you need to know a few things first.
1. You shouldn't be doing this.
There is a reason, and a very good one, that the minimum font size setting exists. Simply, with most fonts, it is already a struggle to read anything below 12px, never mind below the default minimum of 9px. If your design calls for such font sizes for anything but an extremely restricted set of circumstances¹, then your design is just bad and excludes a huge category of users.
2. You really shouldn't be doing this.
The web is an intrinsically flexible medium, and a good design must take account of this. Designs that require a fixed font size to work are suitable for print, but they are not suitable for the web. Any designer who cannot work with this requirement does not understand the medium, and no decent PM should prioritise a designer's bad decisions over practicality and usability. You have far bigger, more fundamental problems to deal with if you can't argue against this decision.
3. You really, really shouldn't be doing this.
Depending on your jurisdiction, you may be wandering on a legal grey area. Tiny font sizes are difficult to read, and will make it very easy for your users to miss information—which is especially troublesome if the text at hand is legally significant, such as opt-out information or a disclaimer. You are also treading on thin ice with respect to the accessibility of your site by causing serious problems for people with visual impairments.
How to do it anyway
It is quite easy to make Firefox display fonts at less than the minimum specified size: just use the font-size-adjust property.
Here comes the science bit
Every font has something called an aspect value, which is the ratio between its x-height (the height of a letter x)² and the actual font-size you set. In Comic Sans, for example, this is really big (0.55), as you can tell by how big the shorter letters (a, c, e…) are compared to taller letters (b, d, h…), whereas in Courier New it is a lot smaller (0.43).
This variability can cause some problems. For example, let's say you specify a super-fancy font for your body text, but because you're a good designer you provide several fallback fonts. That's great, but because some of those fallbacks have different aspect values, letters might be smaller and less legible at the size you specified. font-size-adjust allows you to make sure that any fallback has the same x-height as your super-fancy font.
Unfortunately, we can also use it to make text less legible. Let's say your body copy is Segoe UI at 12px:
body {
font-family: "Segoe UI";
font-size: 12px;
}
The aspect value of Segoe UI is almost exactly 0.5, so if you specify that as the font-size-adjust value, your font size doesn't change:
body {
font-family: "Segoe UI";
font-size: 12px;
font-size-adjust: 0.5; /* x-height = 12px × 0.5 = 6px */
}
What happens if we set it to something smaller? Well, the browser will adjust the font size to use an x-height equal to font-size × font-size-adjust. The below, for example, will result in an effective font-size of 6px:
body {
font-family: "Segoe UI";
font-size: 12px;
font-size-adjust: 0.25; /* x-height = 12px × 0.25 = 3px */
}
This forms the basis of our attack. It turns out that Firefox will honour font-size-adjust even if it overrides the minimum font size. (It goes without saying that this is a bug.)
The demo
Try this out in Firefox with a minimum font-size set. It exploits two bugs: the aforementioned font-size-adjust issue and a separate issue with reporting the rendered font size via getComputedStyle.
You need to know the aspect value of the font you are using for this to calculate the right font-size-adjust value, for which this list of aspect values might help you. (Alternatively, try an estimated x-height for fonts installed on your system.)
But wait! There's worse!
The above technique only works in Firefox. It's even easier to override the minimum font size on an element in Webkit, including Safari, iOS Safari and Chrome—just use the non-standard -webkit-text-size-adjust property:
-webkit-text-size-adjust: none;
This is another bug, by the way. text-size-adjust is a non-standard proposal intended to limit the extent to which text-size is automatically inflated on mobile devices. It isn't meant to work on desktop UAs, much less prevent manual text resizing.
Last word: it won't last forever
Bugs get fixed eventually. You are not meant to be able to override the browser's default font size, no matter how much your irresponsible designer and PM want you to. Sooner or later, people will figure out that these properties are being exploited to make the web worse for everybody, someone will land a patch and the fun will be over.
That said, if you are being forced into this, I wholeheartedly advocate a solution that will eventually force the parties involved to rethink their decision.
¹ Hint: if your text conveys any information that is meant to be readable by anyone, ever, then you shouldn't be messing with browser accessibility settings. Legitimate cases include purely decorative effects (complex ASCII art, shape poetry) and document previews.
² More correctly, the distance from the baseline to the median height, which is the height of a letter x in most fonts.
You cannot do it. It's a setting that Firefox provides so that people like us cannot override it with some CSS settings.
You can effectively shrink text below the minimum size using CSS3's transform: scale(x) syntax, where x < 1. This is guaranteed to work in future browsers (as that's the point of scaling), but does come with its own challenges/caveats.
Just in case it might help anyone, I ended up replacing the small text areas, initially in HTML, with SVG zones. I fill these zones with the Raphaël JS library, with code like
logo_text = $j("#logo_text").val();
logo_text_preview_paper.clear();
logo_text_preview_paper.text(0, 4, logo_text).attr({"font-family": 'Helvetica', "font-size": 7, "text-anchor": 'start'});
I did not use an HTML canvas, because of its lack of availability on certain browsers, and because SVG offers a much better user experience on Retina displays.
It might seem overkill to do that, but I was not able to find an easier solution to the Minimum Font Size problem of FF.
In some cases you can use <canvas> element and fillText().
If you set the default CSS font size in your web pages to a percentage ... then through em sizing you can provide cross-browser scalability ... Setting the font size to 62.5% is a basis for rescaling fonts base hx sizes to 10px.
body {
font-size: 62.5%;
}
p {
font-size: 1em;
}
So if you really wanted to make your standard paragraph text say 10px ... You would just state it in your CSS as 1em and it would render as 10px. Please note that if you really want to do this correctly ... you need to do a CSS reset too as you want your display to be consistent ...
Eric Meyers CSS Reset
HTH
you can try the following code
body {
min-font-size: 15px!important;
}
If you set the the font size attribute on the body it should set it as default font size.
body
{
font-size: 12px;
}