is it possible to Workaround for display:inline-flex in IE 9
<div style="display:inline-flex"> Test </div>
I understand from your question, that you are aware of the fact that IE9 does not support flexbox.
A polyfill for flexbox, named flexie.js, does exist (not maintained afaik), but it works using the old 2009 syntax of flexbox.
Using the old syntax is of course not recommended, since the 2009 syntax is really outdated and many browsers won't recognize it anymore. But, you can try to use Autoprefixer, which transforms new-syntax rules to old-syntax rules (while preserving the new-syntax for browsers that do support it).
There are caveats - You won't be able to use inline-style, you would have to write your styles in CSS files, and I don't think it supports dynamic changes to the DOM.
Disclaimer: I haven't tried that method with IE9 + flexie.
Related
Was searching a bit to see if there was any parsers to handle flexbox for older versions of IE and stumbled upon this bad boy. My question isn't in regards to backwards compatibility of flex it is simply what does this syntax mean/do:
-js-display: flex;
That is a non-standard property that is only intended to work with the Flexibility Polyfill script, which emulates Flexbox support for older IE. The link you provided is a plugin for PostCSS that automatically adds that bit of custom syntax—there is a link to the Flexbility polyfill from the page you linked to as well.
I've been looking around StackOverflow and even else where to find if display: inline-flex; works in IE9. I posted a question before this when I had trouble with expanding a width dynamically, question here.
The answer helped me out, thank you who ever you are! Now that I've fixed the issue and it works fine in Chrome, Opera, Mozilla, Safari, IE10+, I still have trouble making this work in IE9.
I've also tried to add pre-fix for display: inline-flex; such as display: -webkit-inline-box, -ms-inline-flexbox, and so on.
The problem I had which fixed the whole deal was width: auto; and display: inline-flex;
Working fiddle here
How can I make this to work in IE9?
As you can see here: Can I use FlexBox? Flexbox is not supported in IE9
EDIT : Based on OP comment to answer:
if there's any way to make it work in IE9, with prefix or something?
here is a SO users' answer from another related question:
I understand from your question, that you are aware of the fact that
IE9 does not support flexbox.
A polyfill for flexbox, named flexie.js,
does exist (not maintained afaik), but it works using the old 2009
syntax of flexbox.
Using the old syntax is of course not recommended,
since the 2009 syntax is really outdated and many browsers won't
recognize it anymore. But, you can try to use Autoprefixer, which
transforms new-syntax rules to old-syntax rules (while preserving the
new-syntax for browsers that do support it).
There are caveats - You won't be able to use inline-style, you would have to write your styles in CSS files, and I don't think it supports dynamic changes to the
DOM.
Disclaimer: I haven't tried that method with IE9 + flexie.
Our website looks great in all browsers except IE 6-8. We're not even using many CSS3 features. These are just plain old IE rendering bugs (like margins and padding). Before trying to apply a bunch of IE specific fixes, I was wondering if anyone knows of a javascript library that I could apply to fix a bunch of these typical bugs?
Update: Like I mentioned, we're not necessarily using any "modern" CSS3 features nor HTML5, so these are just typical IE 8 bugs where IE renders things differently than all the other browsers.
Go for excellent normalize.css reset that takes care of most of it (also used by HTML5 Boilerplate)
Normalize.css is a customisable CSS file that makes browsers render
all elements more consistently and in line with modern standards. We
researched the differences between default browser styles in order to
precisely target only the styles that need normalizing.
As for getting support of CSS3 for browsers that don't support it, check out CSS3Pie
You don't need JavaScript; just use a CSS reset file: http://yuilibrary.com/yui/docs/cssreset/
That will work across most browsers to not only fix IE issues, but also make your site render more uniformly over different browsers.
You might wanna take a look at this one: https://code.google.com/p/ie7-js/
or this: https://code.google.com/p/html5shiv/
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!
As of right now I believe only Firefox support -moz-border-radius property. I am surprised that twitter uses it.
Are any other browsers planning on supporting this or does CSS3 have something like this in the works?
Edit: I also found -webkit-border-top-left-radius and then the CSS3 version
So when is CSS3 coming out?
CSS3 has border-radius.
For now, Mozilla- and WebKit-based browsers have experimental support, -moz-border-radius and -webkit-border-radius. It's not bad to use them now, as long as you understand they are temporary measures until they are properly implemented. I would expect it's not too long before you see full support for border-radius in Mozilla, Firefox and IE. (Well, hopefully IE.)
Update: as of August 2016, with border-radius being natively available in all native desktop browsers (and most mobile browsers, not to mention), the stringency of using -moz-border-radius, -webkit-border-radius and similar is being slowly relaxed.
Because the CSS3 spec hasn't been finalised, Mozilla and Webkit decided to implement their own method of rounded corners, doing it in the correct way, by adding the vendor-specific tag at the front.
This is done so that when the CSS3 is FINALLY released, should they change how border-radius is supposed to work (eg: the order of the parameters), then none of the sites using the vendor-specific methods will be broken. Mozilla and WebKit can just go ahead and implement the W3C style and developers can slowly move over to that.
It's not too surprising that you're seeing some websites using it, especially for something like rounded corners where it's not going to make a massive difference to the user experience. And I mean, it's just IE users who are missing out, and they deserve everything they get.
It bugs me when people talk about CSS3 coming out. It's not a complete spec like the previous ones. It has been broken up into separate modules that may increment their versions independently.
So Selectors Level 4 may make Recommendation before CSS Backgrounds and Borders Level 3 does.
So, will CSS3 arrive? Eventually, but not all a once. So don't wait for it, start using it now (where applicable).
CSS3 has something like this in the works.
According to this, IE 8 will not support border-radius.
Any CSS property that starts with a dash (e.g. -moz, -webkit) is a browser-specific property.
This allows browser vendors to experiment with new CSS properties. Doing so is a common part of the process for writing new CSS specs, to allow web developers to see how the properties work and raise issues.
Hence you’ll find a lot of CSS 3 properties, like border-radius currently implemented in some browsers with vendor-specific extensions.
There’s nothing particularly wrong with using these on production sites, as long as you’re aware they’ll only work in the one browser.
CSS 3 should be out any decade now :)
Browser-based properties are only meant for interim fixes for that particular browser, and are supposed to be deprecated when either the W3C adopts them into CSS, or not. I wouldn't rely on them to be cross-browser or even be kept for the particular browser.