When using CSS Background Gradients in the Admin UI, begin to use IE Filters to mimic in IE (7, 8, 9)

[georgestephanis]

Code Demonstration: ​http://webdesignerwall.com/tutorials/cross-browser-css-gradient

Example Usage: ​http://www.colorzilla.com/gradient-editor/

Ran this by koopersmith, said to post a ticket, so here you go. May be worth including in future releases to improve cross-browser aesthetics for IE.

[ocean90]

Related: #16461

I don't know if we really want to support this hacky filters.

[georgestephanis]

Does it really count as hacky any more than using browser-prefixed css properties? They're both using browser-specific code in your CSS that the browser in question is designed to accept.

[ocean90]

Since more and more browsers are accepting properties without a prefix, even IE 10, I vote for yes.

[helenyhou]

My feeling here is that we shouldn't be bloating stylesheets (even IE-specific ones) just to support non-crucial visual enhancements in outdated browsers. We're only supporting browser prefixes for current browsers / specifically targeted devices - I don't think it's an equivalent situation. Graceful degradation or progressive enhancement is perfectly acceptable, especially IE7/8. Suggest that we not do these gradient filters and close the ticket.

[azaozz]

I'm 50/50 on this. Adding

filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ffffff', endColorstr='#000000', GradientType=0 ); /* IE 6-9, no shorthand colors */

works in (the current) IE9 as well as 8 and 7.

On the other hand IE10 (and Windows 8) will be released on October 26 (​more info). So when 3.5 is released IE9 will be "old IE" :)

However IE10 will only be available for win7+, meaning a lot of IE users would not be able to upgrade...

[emiluzelac]

I personally don't like or use IE, but it's still on my VirtualBox for design/development purposes.

Anyways, things don't add up here, "we" want to avoid stylesheet bloating and "switch" over to new syntax and standard-compliant browsers by removing only what's IE related, correct?

So does this mean that we can safely remove support for older versions of Safari, Chrome and Opera as well?

Example:

background-image: -webkit-gradient(linear, left top, left bottom, from(#fff), to(#000));

and/or all other prefixed and deprecated syntax's?

Let's either support this equally or take down all that's prefixed completely.

Please think about it just for a sec :)

Thanks,
Emil

[helenyhou]

Replying to emiluzelac:

Anyways, things don't add up here, "we" want to avoid stylesheet bloating and "switch" over to new syntax and standard-compliant browsers by removing only what's IE related, correct?

I looked into this some more - I thought IE9 was using the -ms- prefix but apparently uses the filters instead. It is the current, but won't be as of the anticipated release date of 3.5. However, because of their upgrade path, I have the same conflicted feeling as azaozz. I'm not always correct, hence only the suggested close from me :)

So does this mean that we can safely remove support for older versions of Safari, Chrome and Opera as well?

We discussed why we have to keep the old -webkit- syntax in IRC (basically, Kindle Fire, since it's a targeted device): ​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2012-07-31&sort=asc#m430274 . Do you see something else that should be removed after [21459]?

Please think about it just for a sec :)

I think about it plenty, thanks. No need for that kind of commentary. :)

[wonderboymusic]

IE7, IE8, IE9 all have way more usage than Opera. Like, Opera isn't in the top 10 browsers used, but IE7 is. If those browsers can be supported by filter:progid:DXImageTransform.Microsoft.gradient(), however ghetto it might make you feel, why not do it? An extra line of CSS here or there to support another browser is not code bloat.

If anyone wants to argue: ​http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

[dd32]

IE7, IE8, IE9 all have way more usage than Opera.

I don't think the original intention comes down to browser usage, rather, it comes down to browser support.
If a browser supports the CSS3 "standard" in use, even if through prefixed rules, then the support was added, knowing that those browsers which don't support it natively will fallback to a more ugly, but still not-broken interface.

The Microsoft filter CSS stuff isn't following any kind of standard, and newer versions are upgrading to support standards, We could simply use Images to get rounded corners and gradients, but it was chosen to stick to standards, giving web browser manufacturers a reason to upgrade their stuff.

We already have a ​ie.css file in wp-admin which we could leverage for adding hacks such as filters if we wanted to keep it out of the main stylesheets.

also worth noting, that I believe IE7, 8, and 9 all require different values for filter: as well as filter being prefixed in at least one of those browsers. I recently pushed someone to use ​CSS3Pie for IE CSS3 stuff after attempting to get rounded corners and background gradients working consistently in IE.. it was a pain in this case, but that may have been specific to the site as well.

[emiluzelac]

When I said think about it, that wasn't implied that you guys don't do that, it was referring only logic and anything bad at all, if that sounded differently, please forgive me.

-ms-filter was introduced in IE8, however -ms-filter and filter are basically the same thing and yes IE9 gradients can't work without filters if we're relying strictly on stylesheets.

I can't agree more about Opera, browser is basically "dead" but everyone* still use Opera specific prefixes. filter: is "hacky" as much as anything else that's prefixed.

[helenyhou]

Still don't see why we should be adding to our CSS for non-current browsers, especially given that it's the aesthetic. I think that's the real difference here between prefixes and IE filters.

[emiluzelac]

Sounds good :)

Emil