CSS3 gradient replacements for images and rework existing

[cyberskull]

I've created a patch that replaces the images used in colors-classic.dev.css with the correct CSS3 gradients understood by WebKit, Gecko et al.

It sets up the gradients with a fallback to the image if the gradient is not understood, thus it will still look pretty with IE or other browsers that don't understand gradients.

Other work done is a small amount of code cleanup, just a bit of housekeeping.

Tested in Firefox 3.6.13, Safari 5.0.3, WebKit Nightly, Opera 10.63 on Mac OS X 10.5 PPC. It all worked ok for me.

diff file of the changes to colors-classic.dev.css

The updated CSS file itself.

IE9 supports gradients
if it works in opera 10 it works in IE9

Should this patch land I will port these changes to the rest of the admin CSS.

We'd also want to do this in colors-fresh. Ideally the files should be pretty closely synced.

Replying to nacin:

We'd also want to do this in colors-fresh. Ideally the files should be pretty closely synced.

That is easy enough to do. I've made the CSS-equivalent gradients for almost all the gradient images in wp-admin/images. From there it's just a matter of copy and paste.

If I do that, do I submit them in a separate ticket?

Here is fine. We're indeed looking to replace gradient images with CSS gradients.

Should be the complete CSS gradient replacement.

Replying to nacin:

Here is fine. We're indeed looking to replace gradient images with CSS gradients.

OK. I have attached a file with what is hopefully all the gradient images used in wp-admin/images replaced with CSS. Please inform me if I missed anything. ;)

I did the same for the admin bar in trac #16726.

Surprisingly, patch still applies cleanly.

@cyberskull: please make patches relative to the wp root directory, not relative to wp-admin/css/ etc.

I was thinking of removing the images altogether, but I guess there's no rush.

We should remove them. I have read an article that some browsers will load the image too, which will be no positive perfomance, but I can't find the article anymore.

Replying to ocean90:

We should remove them. I have read an article that some browsers will load the image too, which will be no positive perfomance, but I can't find the article anymore.

That behavior is being phased out, at least in WebKit. So no need to worry.

I want to use this ticket to rework all existing CSS3 gradients to support more browsers (see #17222) and to have one standard code for all gradients.

So their are two questions:

• Do we want the filter code for the IE < 9?
• Should the image still be there as fallback or is a color, like we did for the admin bar, enough?

My suggestion based on ​http://ie.microsoft.com/testdrive/Graphics/CSSGradientBackgroundMaker/

background-color: #xxx; /* Fallback */
background-image: -ms-linear-gradient(...); /* IE10 */ 
background-image: -moz-linear-gradient(...); /* Firefox */ 
background-image: -o-linear-gradient(...); /* Opera */ 
background-image: -webkit-gradient(...); /* old Webkit  */ 
background-image: -webkit-linear-gradient(...); /* new Webkit */ 

+1 from me.

Replying to ocean90:

+1 from me too. Perhaps we can also add the standard CSS3 property at the end. Was thinking: didn't CSS3 offer a way to define a style property once and then use a reference to it? Not sure if that's supported in any browser yet (or maybe it was dropped).

+1 and I'd be happy to see the fallback be a color rather than an image. Getting rid of images also fits with the "make 3.2 faster" mantra.

Personally I'd like to see the proposed standard in there too (background-image: linear-gradient(...);), but I honestly have a hard time justifying it since as far as I know no browser currently supports it.

Similar: #17226

Replying to aaroncampbell:

Personally I'd like to see the proposed standard in there too (background-image: linear-gradient(...);), but I honestly have a hard time justifying it since as far as I know no browser currently supports it.

True, but that makes it more futureproof. When we introduced border-radius none of the browsers supported the proposed standard, now some of the latest browsers support it (and won't work without it like Opera 11).

The patch I submited doesn't have the -o or -ms versions (as Opera only announced the feature a week or two after I submitted it). As for the -ms, I can toss it in. The prefixless version is included in the patch.

I always include the standard version when I do CSS coding, as then I don't have to re-edit the CSS when it is adopted by someone. The only times I change the standard version is to match what I am doing in the others or if the standard was revised.

I'll update the patch this week to include the prefixes for all the major layout engines then.

I have a question, is there a consensus on whether to keep the images or not?

There is already no image in the head, footer, login head and admin bar, so get rid from the other images too.

#16726 has a patch for the admin bar with the new code for gradients.

Gradient update for login.css

Gradient update in fresh and classic stylesheet for head, footer and favorite.

16461.complete.patch and 16461_login.patch include now my proposed standard (complemented with the proposed W3C Markup).

Removing the images is harmful for plugins which uses core images.

The images that would be removed should not be used by plugins directly. They should just use the 'button' class etc.

I'm definitely for removing the images. If we don't use them we might as well shrink the package site. Like scribu said, people should be using the css classes not the images directly.

Past freeze. UI style update hit some of this along way. Will punt instead of close so can review anything else that can be improved here in 3.3.

editor menu: #17720 (has patch)

btw. it it possible to make arrows with css, so we could replace this:
http://core.trac.wordpress.org/browser/trunk/wp-admin/images/menu-arrow-frame.png?rev=17871

example of imageless arrow:
​http://helpdesk.wpseo.de/

Related: #19233

Quote by duck:

Per ​http://dev.w3.org/csswg/css3-images/#linear-gradient-syntax should the "proposed W3C Markup" rule use "to top"?

Replying to ocean90:

Related: #19233

Quote by duck:

Per ​http://dev.w3.org/csswg/css3-images/#linear-gradient-syntax should the "proposed W3C Markup" rule use "to top"?

I am personally against using that syntax. More syntax means it will be more prone to breaking.

Let's do this 3.5-early. Looks good.

It's time for this one. Is 16461.complete.patch​ everything, and ready to go?

We should be mindful to keep any images for which plugins may have a legitimate use.

Patch needs a pretty serious refresh. Would also like to see prefixed properties use the ​"koop-shiny" method of spacing from now on.

It turns out that a lot of this was done in the 3.2 refresh, and this ticket just wasn't referenced at that time: [17862] [17924] and possibly a couple of small bits and pieces that I haven't tracked down yet.

Working on a new patch.

After a chat with helenyhou and sabreuse our prefred syntax is:

.grad-to-top {	
	background: #fff;
	background-image: -webkit-gradient(linear, left top, left bottom, from(#fff), to(#000));
	background-image: -webkit-linear-gradient(top, #fff, #000);
	background-image:    -moz-linear-gradient(top, #fff, #000);
	background-image:      -o-linear-gradient(top, #fff, #000);
	background-image: linear-gradient(to bottom, #fff, #000);
}

.grad-to-bottom {	
	background: #fff;
	background-image: -webkit-gradient(linear, left bottom, left top, from(#fff), to(#000));
	background-image: -webkit-linear-gradient(bottom, #fff, #000);
	background-image:    -moz-linear-gradient(bottom, #fff, #000);
	background-image:      -o-linear-gradient(bottom, #fff, #000);
	background-image: linear-gradient(to top, #fff, #000);
}


.grad-to-bottom-with-color-stops {	
	background: #fff;
	background-image: -webkit-gradient(linear, left bottom, left top, color-stop(0, #fff), color-stop(1, #000));
	background-image: -webkit-linear-gradient(bottom, #fff 0%, #000 100%);
	background-image:    -moz-linear-gradient(bottom, #fff 0%, #000 100%);
	background-image:      -o-linear-gradient(bottom, #fff 0%, #000 100%);
	background-image: linear-gradient(to top, #fff 0%, #000 100%);
}

​http://jsfiddle.net/wFKYm/1/

References:

• ​developer.apple.com/library/safari/#documentation/…
• ​https://developer.mozilla.org/en/CSS/-moz-linear-gradient
• ​http://blogs.msdn.com/b/ie/archive/2012/06/25/unprefixed-css3-gradients-in-ie10.aspx
• ​https://developer.mozilla.org/en/CSS/-moz-linear-gradient#Browser_compatibility
• ​http://make.wordpress.org/core/handbook/coding-standards/css/#property-ordering
• ​http://www.css3files.com/gradient/
• ​http://dev.opera.com/articles/view/opera-mobile-emulator-experimental-webkit-prefix-support/#onlywebkit

Replying to ocean90:

Small correction: seems that both the -moz- and -o- rules don't work...
Edit: disregard that :) Was just a typo in the above example.

Small correction: seems that both the -moz- and -o- rules don't work...

Glad to see it was just a typo. However, for reference, I thought I'd post this link, short story: Opera is aliasing -webkit- to -o- prefixes in the next release, they've got a suggested casscade for the properties listed in the help document related to it, and strangely enough, they're suggesting using the same order as suggested above: ​http://dev.opera.com/articles/view/opera-mobile-emulator-experimental-webkit-prefix-support/#onlywebkit

@azaozz: Oh, sry. thanks for fixing it.

@dd32: Thanks for the info and the link.

I think I get the patch ready by the end of the day.

Gradients with 16461.patch​.

Changed files:

• wp-includes/css/editor.dev.css
• wp-includes/css/admin-bar.dev.css
• wp-includes/css/wp-pointer.dev.css
• wp-admin/css/colors-classic.dev.css
• wp-admin/css/colors-fresh.dev.css
• wp-admin/css/install.dev.css
• wp-admin/css/wp-admin.dev.css

Obsolete images:

• wp-admin/images/blue-grad.png
• wp-admin/images/button-grad-active.png
• wp-admin/images/button-grad.png
• wp-admin/images/gray-grad.png
• wp-admin/images/white-grad-active.png
• wp-admin/images/white-grad.png

In [21459]:

Replace last remaining gradients with css, standardize the gradient css cascade, props ocean90, fixes #16461