This question already has answers here:
Detecting IE version using CSS Capability/Feature Detection
(18 answers)
Closed 5 months ago.
So in my interweb travels of evaluating other programmer's CSS I've noticed a bunch of people using the underscore or asterisk hack that is vendor specific to IE browsers for debugging purposes though W3C does not parse this as valid CSS.
I personally prefer comment conditionals where you can at least defer to IE specific CSS that is valid but I guess the only issue with that would be addition of extra CSS.
So I'm curious about a consensus of what you prefer and the positive or negative implications of each method.
Comment conditonals or IE vendor specific hacks?
PS - Honestly this should be titled do you support IE layout or not :-)
Conditional style sheets are the way to go. The word hack itself implies that you're doing something that you shouldn't. But a few short words on both:
Conditional style sheets
(+) Cleaner CSS code
(+) Easier to manage
(+)Easiey to understand for other developers
(+) CSS validates
(-)More CSS files (thus more server load)
Hacks
(+) Faster (possibly)
(-) Messes up your CSS
(-) CSS doesn't validate
(-) Very unclear for other developers (especially non-experienced one's)
(-) Could cause problems with newer versions of IE
I prefer the conditional comments, because it makes your page still validate. I could imagine, however, that you use the vendor hacks, because you won't need an extra css file, saving a request per page loaded (if not for caching, of course). Then again, the css files are cached, and if you use your conditionals wisely, you can make a separate file per IE version, copying hacks if they are needed for more than one version. That way, you need at most one extra css per page, which is then cached as well, thus minimizing the extra load.
Related
This question already has answers here:
Do we have to use non-standard/browser specific CSS vendor prefixes anymore?
(3 answers)
Closed 8 years ago.
I was just wondering to what extent is it still necessary to specify vendor prefixes like 'webkit', 'moz', 'ms' or 'o' in CSS these days.
If I understand correctly, opera switched to webkit, so that drops '-o-', right? IE dropped the need for '-ms-' in IE10, but do you still need it for older versions? And I'm not sure what the story is with '-moz-' right now.
Basically all my CSS3 seems to work just fine across all (up to date) browsers without specifying any prefix, so I was just wondering what is necessary and what isn't necessary as of mid 2014.
EDIT: Basically I'm just wondering does anyone have an up-to-date list of what prefixes are necessary and under what conditions are they necessary.
You can build a filtered list on this web page and show all of the required prefixes.
http://caniuse.com/#comparison
for the most part, you may find things work great in the latest browsers without vendor prefixes. BUT I will point out 3 reasons why you might want to keep using them at least some of the time and then you decide for yourself when you think it is appropriate.
(as was mentioned already) Not everyone is using the most up to date browser.
You won't break anything by using vendor prefixes even in cases when you don't need to, so it can only improve your site and not harm it.
If your using prefixes (etc) from a service like http://www.colorzilla.com/gradient-editor/ then it's a trivial copy-paste and you gain nothing by not using it (except perhaps a smidgen of file space)
As I'm sure you all know, Internet Explorer can handle simple gradients. Here is a snippet from Twitter Bootstrap, for example:
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffff', endColorstr='#e6e6e6', GradientType=0);
However, I've seen some people use two CSS rules (one for IE < 8 and one for IE 8), like so:
filter:progid:DXImageTransform.Microsoft.gradient(GradientType=0, startColorstr='#7fbf4d', endColorstr='#63a62f'); /* For Internet Explorer 5.5 - 7 */
-ms-filter: "progid:DXImageTransform.Microsoft.gradient(GradientType=0, startColorstr='#7fbf4d', endColorstr='#63a62f')"; /* For Internet Explorer 8 */
My question is, is the second rule really necessary? Twitter Bootstrap is quite thorough, yet it doesn't use any "-ms-filter" rules. According to this page, the -ms-filter attribute is an extension to CSS, and can be used as a synonym for filter in IE8 Standards mode.
My suggestion:
Use CSS3Pie -- http://css3pie.com/
This is a JavaScript library for IE6, IE7 and IE8 that patches in support for several CSS3 features, including gradients.
Yes, you can use the horrible IE-specific filter styles if you want, but CSS3Pie allows you to use standard CSS styles for these features. Much easier.
To actually answer your direct question:
Yes, the -ms-filter style is usually required. IE8 will always us it instead of filter, which is used primarily for IE6 and IE7. In some cases filter will work in IE8, but not all, so it's best to use -ms-filter to ensure IE8 compatibility.
[EDITED]
Why did they change it? Because when they released IE8, Microsoft made a big point of trying to be "standards compliant".
For a browser to be standard-compliant, it should use a vendor prefix for any CSS property it supports that is not a finalized W3C standard. So by adding the -ms- prefix, Microsoft were trying to (belatedly) undo their pollution of the global CSS namespace.
In addition, the quotes were added, because the old filter syntax without the quotes was invalid CSS (mainly because of the colon after progid), and caused issues with some browsers. (I had an instance some time ago with Firefox 3.6 where it was dropping all styles following a filter style that rotated an element - took ages to work out what was happening).
The fact that Microsoft retained backward compatibility with the original filter syntax, was largely a matter of pragmatism. MS couldn't afford to break all the sites using the old syntax. But there was a strong implication from Microsoft that developers should use both because they would drop support for the old filter style in subsequent versions of IE. As it turned out, they dropped support for both filter and -ms-filer in one fell swoop, but the implications given at the release of IE8 were sufficient for it to become recommended practice to provide both syntaxes in your stylesheet.
At the time when IE8 was released, XHTML was the new flavor of the month, and writing code that validated perfectly was top of the list for a lot of developers. This was probably a strong driving force in the change of syntax to include the quotes. Because of the stray colons, it is impossible to write CSS that validates using the old filter style. Using the new -ms-filter styles instead allowed people to write valid CSS. As good ideas go, this one didn't really work out because of course people had to keep using the old syntax anyway, but the intent was good.
It's worth pointing out that other proprietary styles were given the same treatment. For example, you can use -ms-behavior in IE8 instead of the old behavior style. No-one uses it. Why? I don't really know.
Another fact worth knowing is that the W3C are in the process of standardizing a CSS property called filter. It will do a completely different job to the Microsoft filter style, and work completely differently. If/when it is standardized and browsers start supporting it, there will be an explicit clash between the two syntaxes.
Seems like you answered your own question. Yes they're needed. Microsoft trying to get more in line with the standards means that some versions of IE have their own slightly different syntax rules for the filter property.
In IE7 just filter: followed by the progid:DXIma... etc will work. But for IE8+ there is the IE7 fallback it may use in compatibility mode, and the more proper -ms- prefixed property for filter, denoting a vendor specific css property, and its value inside qoutes.
What harm would it do to leave it in?
If the browser doesn't understand the line of CSS it will just ignore it.
Those two lines of CSS are almost identical. I would hazard a guess that Microsoft decided to change the syntax for proprietary CSS from IE8 onwards utilising the - (hyphen) prefix which other browsers have been using for yonks.
Technically the CSS isn't W3C compliant either way, so another line of proprietary CSS can do no harm.
It's not worth trying to understand IE at the best of times!
I have two issues I have ignored so far, but I will really appreciate some light shed onto them.
First: how can I solve differences between Safari, Chrome and Firefox and the various tags that their engines render differently? Should I just write down the right attribute for each in the same css rule? Is there no better way?
Is there a way to separate the CSS sheets for these browsers as I am doing for IE? Is this recommended?
Second: What about CSS3 attributes? Should I just write them again in the same rule after the CSS2 attributes?
Will this cause problems validating the CSS with WC3?
Welcome :)
If you start without the prefixes, you should write the code, generally, with all the semantically appropriate tags, first.
Then, you can decide what your goals are.
If you want W3C compliant CSS files, then you'd need to strip out the vendor specific prefixes by default. This would then allow the latest browsers to pick up the standardised CSS properties if they support them.
This will target less of your market than you might wish, so then you should ask if progressive enhancement is a possibility. If you can reasonably enhance the visuals by using css applied after the page has loaded, such as applying styles with jQuery, MooTools or Prototype libraries AND these libraries are already serving a purpose in your website, then you could apply additional styles with those libraries (and possibly use them in conjunction with Modernizr to determine which elements you may want to additionally support.
However, it's likely that a browser will skip a property it doesn't understand and will render the ones that it does, so I'd suggest that if you code it to W3C Standards first and then add in your additional vendor prefixes 'before' the final (correct) one, then you'll likely have satisfied reasonable measures to be compliant and meet design needs.
Edit:
There is a little bit of confusion between validation results from:
http://validator.w3.org/
and writing valid code related to vendor prefixes to get CSS effects cross-browser:
List of CSS vendor prefixes?
for working on some cross-browser CSS, you might find http://csspie.com, for IE compatibility with some CSS3 properties, useful along with http://www.colorzilla.com/gradient-editor/ for cross-browser gradients and http://cssplease.com for code that gives you alternative vendor prefixes, including different versions of IE support for many different properties.
In terms of validation, here's what W3C says about it: (see comments here: W3 VALID cross browser css gradient,) and official docs here: http://www.w3.org/TR/css3-syntax/#vendor-specific
If you code according to the specifications first and test your code out against that and then add in your vendor prefixes to get the same effects on the browsers you want to support (see progressive enhancement: What is Progressive Enhancement?) then you can be more confident that your code is supporting the appropriate standards, adding value to those with more advanced browsers and still useful for those without additional features (see also WAI III compliance, 508 compliance and others if you want to write a more inclusive site).
Caveat: Web Apps may not always be inclusive or follow these guidelines depending on who the audience is.
If you are using jquery on the site you may want to look into PrefixFree. It's a script that adds the vendor prefixes for you, so for example your put border-radius:6px; in yor css and it reads the browser and adds the appropriate vendor prefix for you via js. I like it cause it keeps my css docs more readable.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why do /**/ comments work in stylesheets but // comments don't?
In CSS there is only one way to create comments: /* I'm a comment */
The problem is that it isn't nestable.
Why don't we have an alternative comment syntax like //?
I think the real answer is that CSS treats newlines like any other whitespace, so it wouldn't make sense to have comments that are terminated by a newline. This is from the CSS1 spec: http://www.w3.org/TR/REC-CSS1
A CSS style sheet, for any version of CSS, consists of a list of statements. There are two kinds of statements: at-rules and rulesets. There may be whitespace (spaces, tabs, newlines) around the statements.
Of course, this also makes a lot of sense in the context of minification, as mentioned here: Why do /**/ comments work in stylesheets but // comments don't?.
It's not in the specification, and because CSS is widely used and supported, adding it in is virtually impossible. You can't just publish a new specification and expect all browsers to magically support it.
Internet Explorer 6, a browser more than 10 years old, is still widely used, so you can safely assume that even if this addition to the specification were made, it'd take another 10 years to be supported enough to bother. The problem with //-style comments is that they don't scale - unlike new HTML tags, which can be safely ignored as long as the rest of the document makes sense, adding a //-comment will break unaware user agents.
So the short answer is, we don't have it because we don't.
If it really means that much to you, write a script or macro that converts //-comments into /* */-comments, and apply it before running your web application.
There is a way to have // comments in CSS. If you use Sass/Compass.
I really like using Compass, because it gives me everything I miss about CSS, like functions, variables and so on...
Here is the Compass home page and the underlying Sass-language.
Compass is very nice, because you just have a program running in the background that compiles your Sass-code into real CSS, so your workflow is exactly as normal, but in other files (SCSS or Sass) and with very extended functionality!
What is harmful in to use css hacks instead of IE conditional stylesheets. What is bad with css hack , will i get any problem in css management now or in future with hacks. I read many articles but haven't found any good reason.
adding extra external conditional stylesheet means one more HTTP request.
Relying on a CSS hack means two things could possibly happen:
A patch or update could fix the hack you're relying on, breaking your site until you find out about it
Future browsers could also have buggy reactions to the hack, making your stylesheets unstable - you would need to remove the hack to fix for the newer browser and find a new workaround for the old one. Again, your site would be broken until you find out about the problem.
Either way, the safest thing to do is use standards-compliant stylesheets and conditional comments. By definition, support for these will only get better with time, so you are essentially future-proofing your site.
If you're especially concerned about the overhead of an extra stylesheet for certain browsers, consider putting them inline. Your overrides should typically be minimal - 90+% of styles should be shared across all platforms.
Biggest reason: Hacks usually rely on some implementation flaw - but if MS fixes the flaw, your hack won't work (or at least not the way you intended.)
If you use proper conditional comments, it will weather the updates fairly predictably.
This is why there was such a furor over IE7 and IE8 - both fixed a lot of bugs and jacked up a lot of sites that relied on IE6 bugs.