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.
Related
In CSS it is possible to style placeholder text within an input using a combination of vendor-specific pseudo-classes and pseudo-elements (to get the best cross-browser coverage).
These all share the same basic properties (ie: text styling and color declarations).
However whilst I inevitably want to apply the same styles irrespective of browser vendor, it doesn't appear to be possible to combine these together into a comma-separated selector (as you would with any other piece of CSS where you want two selectors to share the same styles).
As an example, I tend to target placeholder styling using the four following selectors:
input:-moz-placeholder
input::-moz-placeholder
input:-ms-input-placeholder
input::-webkit-input-placeholder
(although :-moz-placeholder is being deprecated in favor of ::-moz-placeholder this only occurred with the release of FireFox 19 so at present both are needed for better browser-support).
What's frustrating is that declaring and giving each (the same) style leads to a lot of repetition within the CSS.
So, to make sure that placeholder text is right-aligned and italic, I would end up with:
input:-moz-placeholder{
font-style: italic;
text-align: right;
}
input::-moz-placeholder{
font-style: italic;
text-align: right;
}
input:-ms-input-placeholder{
font-style: italic;
text-align: right;
}
input::-webkit-input-placeholder{
font-style: italic;
text-align: right;
}
What I really want to do is to combine them as one single comma-seperated rule set like this:
input:-moz-placeholder,
input::-moz-placeholder,
input:-ms-input-placeholder,
input::-webkit-input-placeholder{
font-style: italic;
text-align: right;
}
However, despite trying this on a fair few occasions, this never seems to work. It makes me concerned that there's some fundamental part of CSS that I'm not understanding.
Can anybody shed any light on why this happens?
CSS2.1 states:
The selector (see also the section on selectors) consists of everything up to (but not including) the first left curly brace ({). A selector always goes together with a declaration block. When a user agent cannot parse the selector (i.e., it is not valid CSS 2.1), it must ignore the selector and the following declaration block (if any) as well.
Note that since CSS2.1 pre-dates CSS3, "it is not valid CSS 2.1" is written under the assumptions that a user agent is fully CSS2.1-compliant and that CSS3 does not exist in theory. In practice, wherever the spec says "it is not valid CSS" or something to that effect, it should be taken to mean "it is not understood by the user agent". See my answer to this related question for a more in-depth explanation.
Namely, since one vendor's browser doesn't understand other vendors' prefixes, it has to drop any rules that contain those unrecognized prefixes in pseudo-class and pseudo-element selectors.1
For some insight as to why such a rule was put in place, see this answer.
1 Note that WebKit is notorious for partially flouting this rule: it has no trouble parsing rules whose selectors have unrecognized prefixed pseudo-elements (which in this case is ::-moz-placeholder). That said, the :-moz-placeholder pseudo-class in your combined rule will cause it to break anyway.
The specs say that if a user agent doesn't recognize part of a selector, it has to ignore the whole selector and its block.
http://www.w3.org/TR/css3-syntax/#rule-sets
The selector (see the Selectors module [SELECT]) consists of everything up to (but not including) the first left curly brace ({). A selector always goes together with a {}-block. When a user agent can't parse the selector (i.e., it is not valid CSS3), it must ignore the {}-block as well.
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 need to set the font to "strong", but can't work out how to do this with CSS? I tried
font-weight: 'Strong';
And I also tried it without the marks and it didn't work either. I'd like to set it to strong and not just bold as I've heard it helps disabled people while they are browsing your website (but that may be rubbish?!)
You probably mean:
font-weight: bold;
There is no strong weight, try bold (which is usually the default browser style for a <strong> element.
more about font-weight at MDN
I just solved this exact problem based off the post I read here. Bold is not what you want as bold is not the equivalent of strong.
For me using a polymer custom component.
Strong = font-weight: 400
Bold starts at font-weight: 500 or greater.
Looking into it a bit further reveals that this is dependant on browser version and display and sometimes things don't get rendered how you want.
More details can be found at the MDN link posted above by steveax and Ryan
bold is the only way. You're confusing the accessibility aspect with the HTML tags <b> and <strong>, which have a bold style by default.
<b> versus <strong> has less to do with accessibility, too, and more to do with semantics and the separation of styles from content. After all, you can style all <b> tags to be non-bold, and that’s just confusing.
font-weight:bold; is the equivalent of 'strong' font. You can also try
font-weight:900; (using numeric values).
strong is a html tag. css is for visual.
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.
Is this valid? font: bold 10px/13px inherit;
According to my reading of the specs that should mean a font-weight of 'bold', a font-family of 'inherit', a font-size of '10px', and a line-height of '13px'.
It appears to work correctly in Internet Explorer 8 (8.0.6001.18702).
It works correctly in Safari 5.0.4 (7533.20.27) on Windows.
Opera 11.01 (build 1190) and Firefox 3.6.16 both log errors about it.
I haven't tried Chrome or Firefox 4 yet.
If this is indeed supposed to be valied is this parsing bug a known issue?
A couple extra points:
The W3 validator also reports this as being invalid.
None of 'font: bold 10px inherit;', 'font: bold 10px/13px;', or 'font: bold 10px;' work correctly in firefox here either.
Update
As pointed out by Adam Wagner in his answer my attempted value is in fact not valid (despite what my naive reading of the spec suggested) due to § C.3.1 of the CSS2.1 spec.
I think the issue is with the "inherit" addition to your value.
Per the specs:
[ [ <'font-style'> || <'font-variant'> || <'font-weight'> ]? <'font-size'> [ / <'line-height'> ]? <'font-family'> ]
| caption
| icon
| menu
| message-box
| inherit
I think the bold section I listed above is one option, and "caption", "icon", "menu", "message-box", and "inherit" are the remaining options.
In short, try: font: bold 10px/13px
Update:
It appears webkit has an outstanding bug report on this very problem. Not sure about firefox. (https://bugs.webkit.org/show_bug.cgi?id=20181)
Also, as someone in the ticket mentions, the 2.1 spec addresses this:
"Shorthand properties take a list of subproperty values or the value 'inherit'. One cannot mix 'inherit' with other subproperty values as it would not be possible to specify the subproperty to which 'inherit' applied. The definitions of a number of shorthand properties did not enforce this rule: 'border-top', 'border-right', 'border-bottom', 'border-left', 'border', 'background', 'font', 'list-style', 'cue', and 'outline'."
http://www.w3.org/TR/CSS21/changes.html#q142
According to the standards, you can't use inherit along with other options in the font composite style.
Both the font-size and font-family values have to be specified (if you don't use any of the forms where they are not used at all).
So, you can't use it to only set the weight, size, line-height, but inheriting the family.
It's obvious that the keyword inherit causes trouble. Maybe because CSS is trying to make it work even if you didn't follow the prescribed order of options (seems not to be the case because different order doesn't work either) and it cannot decide to what directive does inherit belong to.
It works fine if you explicitly set the font family: font: bold 10px/13px serif;
My solution follows (to create as little CSS overhead as possible when using a large composite font-family declaration for your site):
.my-class {
font: bold 1.167em/2 Helvetica;
font-family: inherit;
}
Tested (and working) in FF where I was having the above issue.
No.
the font shorthand property is
font: 12px normal Arial;
Font shorthand is size, weight, font-style. Line height in font is a very very new addition in css and I wouldn't recommend using it just yet. Just add
line-height: 13px;
It is no real extra effort in including the line-height seperately, and until it is cross browser including the line-height in shorthand hand font I would not use it at all.