I tried to validate my site's CSS using the W3C CSS Validator. Unfortunately, reset-min.css from YUI framework produced parse error on the string " {*font-size:100%; ".
The validator results.
On further investigation I noticed the following error on Firefox's error console:
Warning: Expected declaration but found '*'. Skipped to next declaration.
I couldn't find any explanation for the meaning of the '*', nor references for a problem in this popular reset CSS.
What am I missing?
This is a hack for IE7 and lower. IE7 and lower will skip the asterisk and continue to parse the CSS as normal. Other browsers will just ignore the entire rule.
As an example, since CSS will use the last declared version of a rule, doing the following will cause IE7 and below to use a font-size of 113%, while other browsers use a font-size of 100% for paragraphs.
p { font-size: 100%; *font-size: 113%; }
There is a little more information at webdevout.net.
Personally, I think that it is acceptable to use such hacks for the purposes of working around the brokenness of IE. Apparently, Yahoo! feels the same way.
It's probably an IE compatibility hack.
There are many CSS syntax errors that some browsers (notably IE 6) will ignore and others won't. Some CSS files will use the errors to make a rule that one browser will see and another browser won't.
EDIT: For a full list, see here. In your particular case, that rule will be seen only by IE 7 or lower.
Related
I am refactoring some CSS and figured I would review based on this helpful best practices reference. One thing that is mentioned in using - instead of _ in naming types, and of COURSE I named all my types with _! The reference mentions doing this for "older browser" compatibility, but not what this means exactly. Is this IE6 level stuff, where I can (in my opinion) safely ignore anyone still using that junk? Or is this IE9 level stuff, where I know a ton of my readers are still in IE9? And, what are the implications with Android browsers? Knowing that Android basically stops getting updates the moment you buy the phone in some cases, am I gimping myself there as well if I don't bother to refactor?
Those naming used to override CSS attributes for specific browsers, and they are bugs/hacks in browsers that allow you to style browser with that found bug to behave as intended. check browserhacks for more information about this, also browser specific css hacks
example
body {
background-color: red;
_background-color: blue;
}
this CSS will be apply red background to the body and they will ignore _background-color: blue; because its invalid CSS attribute, but for IE6 it will recognize it as a valid CSS attribute (because IE6 CSS validator will sanitize it and remove the leading _) and will override the background-color: red;
Is it necessary to have valid CSS? I am using Twitter Bootstrap for rapid web development and after running the two main Bootstrap style sheets through the W3C CSS Validator, I noticed about 600 errors.
My question is, my site looks good so why is it so important for the CSS to be valid?
Yes, it is absolutely necessary to have valid CSS. CSS is a programming language and as such, you must follow its language rules. Just because browsers tend to accept invalid HTML and try to render it, it doesn't make generating ill-formatted HTML a good practice. The same is true to CSS, although - fortunately - CSS rules are quite a bit stricter than HTML rules.
Another reason is that valid CSS has guaranteed behavior - if you write a rule, you can expect that rule to behave a certain way. (Buggy browsers, like all versions of IE aside.) If your CSS is invalid, any behavior you get is undefined and it may break when a patch release is issued for any of the browsers that you use for testing. Your CSS won't necessarily break but when you write invalid CSS, you get no guarantees of any behavior - you simply get some behavior that may seem correct to you but that may change any time.
If you have correct CSS mixed in with incorrect CSS, browsers tend to ignore the invalid parts (just how the specification tells them to) but each browser does it slightly differently. Similarly, while many people advise to use CSS hacks, I'd say not to, for the above reasons.
The CSS doesn't have to be valid to work. Browsers simply ignore the CSS that they don't understand.
Validating the CSS is a method to test if it follows the specification. If it does, any browser that is up to date with the specification used will understand the CSS.
It's somewhat of a debated topic really. The W3C tools are certainly good to use, but they tend to not account for a lot of modern code. Naturally, it's difficult for them to not only advance standards, but also make sure the tools they offer are accountable to new and inventive code.
In order to get websites to look good in all browser and across all platforms requires people to maybe stretch outside of the norms that otherwise would be "valid". It's tough to argue against a site that works perfect cross browser and platform even if the CSS isn't 100% spotless. That's my two cents.
Your CSS doesn't need to be valid (depending on who you ask), but if it is invalid, you should have a reason for the invalidity:
audio,
canvas,
video {
display: inline-block;
*display: inline;
*zoom: 1;
}
The validator has a parse error here because of the asterisk at the beginning of property. This is a obscure but recognized hack for targeting Internet Explorer. Other browsers will ignore the properties that it won't recognize but IE6/7 will read properties with asterisks.
input:-moz-placeholder,
textarea:-moz-placeholder {
color: #999999;
}
input:-ms-input-placeholder,
textarea:-ms-input-placeholder {
color: #999999;
}
input::-webkit-input-placeholder,
textarea::-webkit-input-placeholder {
color: #999999;
}
The validator error here is a result of vendor-specific pseudo-classes. Note than unlike unrecognized properties, if a browser doesn't recognize the selector the entire rule will be ignored so the vendor placeholder extensions need to be separate rules. This happens even when using the comma operator so:
input::-moz-placeholder,
input::-ms-input-placeholder,
input::-webkit-input-placeholder, {
color: #999999;
}
would be ignored in all browsers unless they recognized all three vendor prefixes.
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#fffbb450', endColorstr='#fff89406', GradientType=0);
This is the old-style IE extension for gradients. It ripples and causes a number of errors in the validator even though IE follows it and other browsers will not quietly ignore it.
width: auto\9;
The \9 is another IE hack that targets IE<=8
The bottom line is that if you are doing something non-standard, make sure you know why you are doing it.
Now a days there are different number of browsers with different number of versions.Some supports lot but some are not.So when you include styles it is always not possible to fit 100 % perfect.If your style works without any problem ok.But when it goes to different browsers if you get problem related CSS , You have to take care otherwise no problem.
yes its important, most of browsers follows the w3c standard when they load the html page. if your page don't have the valid css, in different browser it might appear different ways. Old internet explorers didn't followed the W3c standards which cost alot to the developers result in developer need always extra css for the IE to display page properly.
today I hit F12 in FF to load FireBug to see what my site was thinking. Then saw this:
The facts showing from above:
My site likes using them "rounded", alot of them...;
My site is loaded with errors, at least as FireBug sees it.
Is FireFox right and should I assess this and if so how do I change it since I think this is crucial for IE and is the default CSS3 spec, right? Or is there something else happening thats causing all this things to show up in FireBug? I would be happy to hear what I should do to make all this disappear again, really.
Open the drop down in your console tab and un-tick stuff like "show CSS errors".
Also, it's not a bad thing. If Firefox comes across a property it doesn't know (such as border-radius at the time this question was asked) it will just ignore it and continue with the next property. This is why for instance -webkit-border-radius: 2px; -moz-border-radius: 2px; border-radius: 2px; works. Firefox will ignore the -webkit- prefixed one, it would recognize the -moz- prefixed one and ignore the non-prefixed one because the non-prefixed one had not yet been implemented in the version of Firefox you used. (It is now no longer needed to prefix border-radius unless you're supporting an ancient browser)
You might want to pop the IE-specific properties (filter and zoom) into an IE-specific stylesheet, and include that with conditional comments.
As for the rest, you’ve just got an older version of Firefox that doesn’t recognise the newer properties. That’s fine, it won’t do any harm. (Somewhat odd that moz-opacity isn’t recognised, as I thought that had been around for ages, but it’s fine.)
Check this
I think you need to use -moz-border-radius:... declarations for FireFox :)
That title isn't quite as crazy it seems. I promise!!
While researching for another question, I noticed the following in Stack Overflow's stylesheets:
...
width: auto;
...
width: 650px!ie7;
padding-bottom: 20px!ie7;
...
Is this an odd type of conditional styling? Is this a mistake? Assuming it isn't a mistake, does this work with all IE versions? Is there a way of specifying that a given rule should only be applied to versions of IE greater than – say – 7?
I have never encountered of this before – I've always used conditional comments for IE-specific styles (and for what it's worth, I prefer keeping all IE-specific styles completely separate).
I have heard of this before, but not with the exact text !ie7.
I found a reference here: http://www.javascriptkit.com/dhtmltutors/csshacks3.shtml
!ie
Internet Explorer 7 fixed one of the
issues with the !important identifier,
but it still has problems when the
identifier has an error in it. If an
illegal identifier name is used in
place of important, Internet Explorer
7 and below will handle the property
normally instead of failing.
Therefore, in any style declaration
block, you can include properties
intended to only apply to Internet
Explorer and add an !ie identifier.
Almost any word can be used in place
of ie.
The !ie identifier allows the property
to be applied in IE 7 and below. It
may or may not work in future
versions. Warning: this uses invalid
CSS!
So, width: 650px!ie7; will be applied in only IE 7 and below.
The actual text ie7 is not required, but it's a sensible string to use, to remind people of the purpose behind the hack.
I'm wondering if there's any way to write CSS specifically for Safari using only CSS. I know there has to be something out there, but I haven't found it yet.
I think the question is valid. I agree with the other responses, but it doesn't mean it's a terrible question. I've only ever had to use a Safari CSS hack once as a temporary solution and later got rid of it. I agree that you shouldn't have to target just Safari, but no harm in knowing how to do it.
FYI, this hack only targets Safari 3, and also targets Opera 9.
#media screen and (-webkit-min-device-pixel-ratio:0) {
/* Safari 3.0 and Opera 9 rules here */
}
There are some hacks you can use in the CSS to target only Safari, such as putting a hash/pound (#) after the semi-colon, which causes Safari to ignore it. For example
.blah { color: #fff; }
.blah { color: #000;# }
In Safari the colour will be white, in everything else it will be black.
However, you shouldn't use hacks, as it could cause problems with browsers in the future, and it may have undesired effects in older browsers. The safest way is to either use a server side language (such as PHP) which detects the browser and then serves up a different CSS file depending upon the browser the user is using, or you can use JavaScript to do the same, and switch to a different CSS file.
The server-side language is the better option here, as not everyone has JavaScript enabled in their browser, which means they wouldn't see the correct style. Also JavaScript adds an overhead to the amount of information which needs to load before the page is properly displayed.
Safari uses WebKit, which is very good with rendering CSS. I've never come across anything which doesn't work in Safari, but does in other modern browsers (not counting IE, which has it's own issues all together). I would suggest making sure your CSS is standards compliant, as the issue may lie in the CSS, and not in Safari.
So wait, you want to write CSS for Safari using only CSS? I think you answered your own question. Webkit has really good CSS support. If you are looking for webkit only styles, try here.
You'd have to use JavaScript or your server to do user-agent sniffing in order to send CSS specifically to Safari/WebKit.
#media screen and (-webkit-min-device-pixel-ratio:0) {}
This seems to target webkit(including Chrome)... or is this truly Safari-only?
This really depends on what you are trying to do. Are you trying to do something special just in safari using some of the CSS3 features included or are you trying to make a site cross browser compliant?
If you are trying to make a site cross browser compliant I'd recommend writing the site to look good in safari/firefox/opera using correct CSS and then making changes for IE using conditional CSS includes in IE. This should (hopefully) give you compatibility for the future of browsers, which are getting better at following the CSS rules, and provide cross browser compatibility. This is an example.
By using conditional stylesheets you can avoid hacks all together and target browsers.
If you are looking to do something special in safari check out this.