CSS, Internet Explorer and the magic !ie - css

I came across this strange bit of CSS tonight...
display: inline !ie;
Now I've created and seen a lot of CSS and I have never seen this before or its magical powers.
You can add "!ie" at the end of any rule and it will only be applied by M$ Internet Explorer 6 & 7
Can anyone shed any light on this WTF?

Internet Explorer 7 and below have a few quirks related to the !important declaration, which is supposed to give a value higher importance than normal.[3] IE7 and earlier accept virtually any string in place of important and process the value normally, while other browsers will ignore it.
Taken from !Important Quirks section in CSS Filter - Wikipedia

At a guess, I would say that Internet Explorer tries to recover from what is quite clearly an error. The following would also work:
display: inline !pudding;
The specification says that if an invalid value is specified or an error occurs in a rule it should be ignored. It looks like most browsers stick to this but IE recovers for this specific situation.
In some cases, user agents must ignore part of an illegal style sheet. This specification defines ignore to mean that the user agent parses the illegal part (in order to find its beginning and end), but otherwise acts as if it had not been there.
http://www.w3.org/TR/CSS21/syndata.html#parsing-errors

Related

google chrome inspect element - invalid property name - browser specific?

I'm currently using google chrome to inspect the elements of a bigger project I am working on and noticed that it gives very neat hints (e.g. striking through properties that are later overwritten). It also gives the hint that a property is invalid with a yellow exclamation mark. Is this information browser specific and it is only not valid in google chrome or can I assume that this property will not work anywhere? (of course I could look up every property for which I get this warning, but if I knew definetely these were unnecessary I could get rid of them without much hassle)
Striking through properties that are overwritten should generally reflect general CSS rules, i.e. be browser-independent. But the browser’s code for that might be buggy. Moreover, a potentially overriding rule might use a nonstandard value for a property, and then it would depend on browser whether it really overrides.
Indicating properties as “invalid” in browser tools should be taken just as saying that the browser does not recognize (support) the property. So it would be very much browser-dependent. It may also depend on browser version.

Is it necessary to have valid CSS?

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.

Bang IE7 - What does it mean?

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.

Why YUI Reset CSS doesn't pass Validation?

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.

Purpose of asterisk before a CSS property

The following is taken from the Yahoo CSS reset. Can someone please explain the purpose of the asterisks?
body {
font:13px/1.231 arial,helvetica,clean,sans-serif;
*font-size:small;
*font:x-small;
}
It is a browser specific CSS hack for versions 7 or below of Internet Explorer.
*property: value
Although Internet Explorer 7 corrected
its behavior when a property name is
prefixed with an underscore or a
hyphen, other non-alphanumeric
character prefixes are treated as they
were in IE6. Therefore, if you add a
non-alphanumeric character such as an
asterisk (*) immediately before a
property name, the property will be
applied in IE and not in other
browsers. Unlike with the hyphen and
underscore method, the CSS
specification makes no reservations
for the asterisk as a prefix, so use
of this hack could result in
unexpected behavior as the CSS
specifications evolve.
*property: value applies the property value in IE 7 and below. It may or may
not work in future versions. Warning:
this uses invalid CSS.
From: http://www.javascriptkit.com/dhtmltutors/csshacks3.shtml
It's an Internet Explorer hack. If you add a non-alphanumeric character such as an asterisk (*) immediately before a property name, the property will be applied in IE7 and below, but not in other browsers.
http://www.javascriptkit.com/dhtmltutors/csshacks3.shtml
All browsers but IE ignore the rules. It's known as the star hack. I think IE7 will ignore the rules in standards mode.
In this case, the font rule is set and then overridden for IE 6 and sometimes 7.
Placing characters like that is a hack/workaround for getting IE 6 to use a style's property, while hiding it from more "sane" browsers.
From here:
To cut a long story short, the Internet Explorer CSS parser is overly
aggressive at trying to discover the names of properties and will in
fact ignore leading non-alphanumeric characters. From my testing this
appears to be the case from at least IE5 onwards.
As far as I know, asterisk prevents Firefox to read the attribute, but is valid in IE.
It's a CSS hack, that rule will only be applied to IE7 and below.
I wouldn't recommended using it though, there's better ways to fix IE incompatibilities.

Resources