Rounded corners and gradient background with CSS on IE9

Same here, except for the scaling but personally haven’t run against that need. I keep it simple and this likely keeps FF scrolling :slight_smile:

We lazy. Image editor make more work. Jane not pleased. Typing, faster. Grunt.

At first I would feel sorry for FF users, and then I’d realise their CPU would breath a sigh of relief if they switched to… something else.

Then again I’m still using it because I need NoScript, text-enlarge, some missing properties from Chrome dev that are in Firebug, Web Dev ToolBar, and most importantly, the ability to run the browser and turn JS off. Big turnoff for Chrome. Plus I know Chrome is spying on me, because it’s Chrome and not Chromium. Spy browser vs glutton browser… hm…

Off Topic:

Unfortunately the site was a Photoshop Web 2.0 + Gradients and Glow special. =p

Luckily, I’ve since convinced them that we should do it the “right” way (styling markup instead of marking up pictures).

I like the ability to control gradients through text though. It makes it a lot more easy to create dynamic colors, which is easier and quicker than creating dynamic images.

Normally I’d agree with that - code over image; but does it really take that long to go “pick colors, floodfill, save”? I mean we’re talking a 1px by whatever other length image here… Not exactly a big deal to change. Just choose gradient for color, foreground to background as the type, opacity to 100% and tolerance to 100%… poof, floodfill gradient. Most of that is my default floodfill state anyways. (talking in PSP terms, shouldn’t be that different in Photoshop, Gimp, whatever).

That and colorstops are a PITA… one of the few things I’d prefer to do in a paint program.

Yes, it takes quite a bit longer for me - and you don’t get to tweak the values directly in the browser til they’re in the sweet spot.
You also have other tools like rgba which I find much easier to work with than gradients with transparency in Photoshop.

Color stops are easy as pie with Compass.


@include background(linear-gradient(top #fff, #ccc 50%, #000))

Well I disagree. ( Guess I am agreeing with DS60 again) Is there some sort of Photoshop fear amongst coders? Aside from saving the HTTP request, the main advantages is the dynamic nature of UA generated gradients. In other words they can stretch with the element, you can use EMs as measurements , do quite a few neat placement tricks… etc. However, as it has been mention before , this is putting quite a load on the browser. So it is key not to slap around css3 gradients merely because you ‘can’ if a few 600byte gradients could do the job. But if for some unfortunate reason you end up needing two dozen gradients … or gradients which must adjust to content… then I’d start leaning towards generated gradients.

No Photoshop phobia here, the reason I and others use them are for the numerous benefits of CSS gradients that we’re talking about here.

Which is something I try to avoid on websites BECAUSE FF is so painfully slow at handling them in CSS… just as I wouldn’t use alpha transparency in images either due to the ridiculous filesizes. Alpha blending takes five to twenty times longer to be rendered, and if the page has lots of reflows or dynamic events mixed in, you can kiss off Firefox being usable on anything slower than 2.4ghz. Alpha transparency SUCKS on websites, and it’s probably going to continue to suck for a LONG time – in terms of bandwidth use for images and in terms of rendering speed on generated gradients. (which already start out painfully slow).

Both fall into the traps of “not viable for web deployment” and “but I can do it in photoshop” that are on my **** list of what’s wrong with most of the garbage vomited up by PSD jockeys who have the cojónes to claim they know anything about designing for the web.

Side note though – I have lately used CSS3 to generate what I want on page, then screencapped and clipped out what CSS3 made into an image. That way I get the faster to render image while letting me play with values directly on the page during development.

Now that’s cool.

No. It’s not.

That is a complete abuse of what the standards are for and is a big waste of time.

ds, what you explained simply isn’t true for me at all.
I run a 2.26GHz computer with firefox by default, I use gradients, shadows, alpha transparency extensively - It doesn’t skip a beat.

It doesn’t bother me if you choose not to use these tools.
My reasons are clear, it saves a lot of time, allows for more flexibility, requires less images.

I think you often solve problems that aren’t really problems.

Ok, where do you get that from?!?

Try this page:
http://www.cutcodedown.com/for_others/FFCSS3Sucks/template.html

Do those hovers fire instantly like they do in Opera or Chrome, or do they have a second and a half delay? make the window wide enough to see the side gradient effects while short enough to scroll up and down – is it jerky to the point of being unusable with starting to scroll having a two to four second delay? Because it sure as shine-ola does here and that’s on a i7 870… Hell, just trying to resize the window has massive delays, lag, tearing and jerky unresponsive control.

I’d suspect if you are using those effects without it ‘skipping a beat’ you’re either not making pages big enough to need scrolling, not scrolling the page, or not using any dynamic interactions like hovers with them.

Kind of like that cicada background crap that’s useless in Opera or Safari with it flickering on and off during the redraw for scrolling… they’re cute effects, but unusable on production pages.

Which is where CSS3 gradients are at for me – which is why occasionally I’ll use them to make the layout, then slice them into images so they work everywhere and run without the rendering headaches on the production pages. It’s just another tool in the toolbox.

Though I’ll admit I’ve never had anything but bad luck with firefox in terms of stability, usability, or speed… These days I lump it with IE on it’s backwards half-assed behaviors and things never being fixed.

Ok, where do you get that from?!?

It’s an abuse of the standards to take a screenshot and *******ize what can be done in CSS with images…

That’s an interesting test case you have there, have you submitted it to them?

I do see a small delay when you hover the images / spans but it’s close to 200ms to be fair, but, it’s still more noticeable than anything I’ve seen before.
I don’t do that type of thing on :hover

The text-shadows seemed to cause more delay than anything - removing them fixes the scrolling for me.
You were also using the fourth box-shadow value for ‘spread’ which I didn’t know existed either - removing it fixed the delay on :hover
0 0 8px 2px #0088FF

You are right, that if that’s the sort of effect you want to achieve the performance will be shabby.
For me, that’s not the type of effect I am after :wink: What you shouldn’t do is use that extreme example as a reason never to use CSS3 text-shadow / gradients / box-shadows.

Here it’s more than a second and a half, and removing the hover effects has ZERO impact on the painfully slow scrolling if you put gradient on anything taller than 32pixels.

Out of curiosity, what’s your video specs and OS? I’m actually trying to narrow down where it works and where it doesn’t – a simple body { background:linear-gradient blah, blah, blah makes pages painful to the point of not wanting to use them on ALL of my machines in FF, but I’m hearing from other people it isn’t… About the only difference I’m finding is that it’s worse on linsux than it is in windblows, in OSuX you’ve got a good chance of crashing the browser, and for some reason SOME AMD/ATI video cards are immune to the problem. (pretty much anything labelled 6xxx HD)

Odd, they’re unrelated to the scrolling issues here which seem entirely tied to the box-shadows… doesn’t show the gradient problem though – but again just set a linear-gradient on body and try scrolling it. It’s renders the page useless. More of them you use, the worse it gets – sucks so much cpu that just hitting ‘page-down’ on my media center nettop in FF ends up taking around 20 seconds to respond (with windows saying FF is “not responding” for the latter half of that time). Admittedly that’s only a 1.6 Single core hyperthreaded Atom, but it’s got ION so there’s little excuse; especially when it’s fine in Chrome and Opera. (Kind of like how VLC and Netfix can’t play HD on it when Hulu and Media Player Classic handle it just fine)

Which is funny since the fourth number is the solid color – and one that any of the fancier effects (like the ones shown in some of the recent articles off site-points home page) rely upon. Solid color should be EASIER than blending, not harder.

Sorry, if that’s your idea of extreme…

But seriously:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	lang="en"
	xml:lang="en"
><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=utf-8"
/>

<meta
	http-equiv="Content-Language"
	content="en"
/>

<title>
	Template Design CSS
</title>

<style type="text/css">
body {
	background:#000; /* Old browsers */
	background:-moz-linear-gradient(top,#F00,#000);
	background:-webkit-linear-gradient(top,#F00,#000);
	background:-o-linear-gradient(top,#F00,#000);
	background:-ms-linear-gradient(top,#F00,#000);
	background:linear-gradient(top,#F00,#000);
	filter:progid:DXImageTransform.Microsoft.gradient(
		startColorstr='#FF0000',
		endColorstr='#000000',
		GradientType=1
	);
}
</style>

</head><body>

	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>
	<p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p><p>Test</p>

</body></html>

Are you able to scroll that up and down smoothly? Because I sure as shine-ola can’t on any of my good machines… For some reason it runs great on my old P3 intel Express 2 dell laptop I keep in the garage; when my i7 desktop and T9400 laptop can’t handle it in FF… while every other browser that supports it runs just fine.

Still one ugly mess of code for background:#000 url(images/redToBlack.png); background-size:100% 100%; with that png being around 192 bytes… especially since unlike gradient, all modern browsers support it without those stupid malfing vendor prefixes. (even IE9) – legacy browsers just let the gradient fade to the black… oh noes, not that :smiley:

Seriously:


background:#000 url(images/redToBlack.png);
background-size:100% 100%;
73 bytes code + 192 byte image.

vs.


background:#800; /* Old browsers */
background:-moz-linear-gradient(top,#F00,#000);
background:-webkit-linear-gradient(top,#F00,#000);
background:-o-linear-gradient(top,#F00,#000);
background:-ms-linear-gradient(top,#F00,#000);
background:linear-gradient(top,#F00,#000);
filter:progid:DXImageTransform.Microsoft.gradient(
	startColorstr='#FF0000',
	endColorstr='#000000',
	GradientType=1
);

402 bytes code…

Splitting hairs really on choice/method… excepting that the image version doesn’t drag geckotard browsers into the circles of hell on performance.

I have yet to see a page that uses the dynamic gradients, shadows or other effects that aren’t a buggy slow and annoying mess in FF unless you magically have that perfect combination of hardware it seems to want… said combination being from my experience brand spanky new ATI or decade out of date Intel…

That page ran fine for me (though I am on a bit of a beefy machine).

Also, I think it’s certain types of gradients. As you mentioned, it’s usually larger gradients or dynamic events. Both of those are things I avoided on the site I mentioned earlier (which runs flawlessly on every FF browser we’ve tested, on a wide spectrum of machines). I don’t think that’s a reason to avoid ALL of them.

That’d be like never using a loop in programming because if you have a loop of a billion entries it may slow down the machine. =p Just because you can’t do anything doesn’t mean you should cut it off completely.

However, your CSS3/image cutting technique is interesting. I may use a variant of that (where I just deliver the images to browsers which can’t handle the CSS3). I don’t agree it’s a violation of standards, though it’s not a universal technique either. CSS3 is being created so we can have faster pages. The rendering may be slow now, but that’s only because they haven’t developed it well enough yet (hence why most of them are still browser prefixed).

That’s not too bad in my Firefox but by the end of the day it probably won’t be so smooth as Firefox gets slower as the day wears on.

However this page (that page is just for fun only and was an example for an old sitepoint competition so no comments please) is very jerky in Firefox when scrolled because of the diagonal gradients and the table rollovers are desperately slow compared to Chrome and even ie9. Granted the page is an extreme but we really should be able to use these things without having to worry that the browser will slow down.

Paul – I’m hesitant to open that in FF here given what a disaster it is in Opera… which usually handles those types of things well… though I suspect it’s opera’s limited/early transition support causing the most problems here.

Oh wow, there’s a body background on it in FF… didn’t include the -o version I guess.

Great example of how bad things can get in FF when you actually start using the CSS3 properties.

Yes Opera wasn’t on the list for the demo so there was no catering for it. However I was a little disappointed that Opera still has the same bug since about opera 5 (or probably before) where it fails to redraw elements properly when they have been moved. It leaves the shadows and other artefacts behind which is a similar problem that plagued drop down menus for years (although I guess that was partly because at the time the specs said that browsers didn’t have to redraw the screen if in the case of hover elements were moved).

Great example of how bad things can get in FF when you actually start using the CSS3 properties.

Yes, it shouldn’t be that we have to worry about these things as well - but such is life :).

Oh, side note on the ‘extreme examples’ bit – I’d point out these are EXACTLY the types of things being advocated in recent articles here on Sitepoint… Konstantin has been posting some really good examples of using the various CSS3 effects – for example:

All of which would have the problems in FF if used on an actual site – especially the combined/layered effects…

Out of curiosity, what’s your video specs and OS?

Macbook Pro, 2.26 GHz Intel Core 2 Duo, NVIDIA GeForce 9400M 256 MB

Your example full page gradient works fine for me.

Your examples are biased again, here’s the comparison for me using those tools.


background:#000 url(images/redToBlack.png);
background-size:100% 100%;
+ open up photoshop
+ generate & save image
+ extra request

vs


@include linear-gradient(top,#F00,#000);

Oh, side note on the ‘extreme examples’ bit – I’d point out these are EXACTLY the types of things being advocated in recent articles here on Sitepoint… Konstantin has been posting some really good examples of using the various CSS3 effects – for example:

No, they are not promoting adding multiple text-shadows and box-shadows to every element in the page. They are explaining how they work.
Your bias is unbelievable.

Admit defeat :wink: there’s nothing wrong with these tools unless you use them for Really Goofy ****.

Great example of how bad things can get in FF when you actually start using the CSS3 properties.

When you start using them incorrectly, I agree with that.

With Javascript you can make a real mess of the page too - there’s no point throwing out the baby with the bathwater.

Yes, it shouldn’t be that we have to worry about these things as well - but such is life :slight_smile:

For what it’s worth, I don’t need to worry about this - the effects I use don’t cause these problems.

It’s akin to using tables for layout if you found out that tables rendered faster in the browser.
We should use the tools designed for specific tasks. If any reasonable effect can be accomplished with CSS3 with little effort it’s wrong to use an image for it.

However, some of the effects he’s talking about aren’t reasonable, and aren’t reasonable in all browsers.

For example, I usually use a stacked background technique so I can hit everything all the way back to IE7.

Say I want a gradient. The stack looks something like this:


background: url(grad.png); /* backup */
background: url(grad.svg?autogen); /* IE9 */
background: -webkit-gradient(blah);
background: -moz-gradient(blah);
background: -o-gradient(blah);
background: -ms-filter(blah);
background: filter(blah);
background: linear-gradient(blah);

(Yes, I know that’s not a perfect stack, bad syntax and there is a redundant image loaded for those that use the gradient… ignore that… it’s a quick example =p).

That stack let’s me hit just about everything, and let’s the browser use it’s most appropriate.

However, with really complex gradients (and you can get really complex), if it’s slowing down the browser substantial, that isn’t letting it work well, I could remove it and let it use the backup images.

Also, you say reasonable… but what about the unreasonable (which is more what we’re talking about). Even if it’s a simple two color linear gradient, if it’s lagging firefox to pieces, it’s unreasonable in Firefox.

We’re not saying you should start replacing normal stuff with a graphic, but as a development technique it is very interesting, especially if you already have to generate a background image anyways.

It’s not an end-all, be-all solution, it’s just another tool for your toolbox. I have a lot of those. Most I rarely use, but they’re handy when you have that weird problem you need it for. =p

I’ll add it to the list… Hmm. I’ll dig out my Ge9500GT and see if it has the problem or not. DX11 level card specific perhaps?

Plus the extra step of precompiling it with whatever tool you are using, and the massive bloated browser unique version that gets sent to EVERY firstload since you would STILL be sending the full non-shortcut version to users – pretty much putting it on a even footing again. Don’t try to catch me with card stacking friend; I don’t fall for it.

Nor am I, NOR do I say that anyways – but I should be able to apply them to one or two elements in the manner outlined on said pages without dragging a browser on a multi-ghz computer into the circles of hell. Simply doing the neon example (4.1) from that ‘mastering text shadows’ page thus:

text-shadow: 0 0 0 3px white, 0 0 0 4px gray; color: magenta;

On even just one element should not be enough to send JUST one browser off into la-la land; and currently it is. A simple gradient on one element is same; when I can do background-size and not have that problem.

Pot, kettle. Your propensity for stuffing words in other peoples mouth is unbelievable… That or you’re just failing to comprehend what I’m saying.

You seem to think that using them properly – aka “actually following the rules and specificaion for them then SHOCK declaring them on elements” is somehow “incorrect”… Seriously, whiskey tango foxtrot hotel india tango sierra…

For you on your hardware… I suspect your sample pool probably isn’t large enough.

There seems to be this tendency of late to think that the be-all end-all of CSS3 is to try and do everything without images; which is ALSO missing the point since all sorts of powerful new image effects that are quite often MUCH more useful are in there too… like background-size, border-image, etc. When CSS3 is NOT ready for prime-time, using a tried and true method that SHOCK works back over a decade or more of browsers that consumes little to no extra bandwidth and OH NOES one handshake… jumping the gun on technologies the bugs aren’t worked out of yet is NOT exactly what I’d call a rational choice.

Which is NOT to say I don’t agree that for gradients, it would be really nice to stop using images leaving background-size for other things – but it’s just not there yet in terms of reliability or performance, especially with all the browser specific prefixed crap you end up having to send to the user.

… and while a precompiling tool like SASS with @include does simplify maintaining the code when it comes to all this stupid idiotic browser prefix crap (I’ll give you that) you’ve just introduced as many extra steps for deployment as the twenty seconds it should take to make the image and you’re still sending the full version with all the prefixes client-side - making it a wash.

When the difference is splitting hairs on bandwidth and effort, and both approaches rely on CSS3 properties (background-size vs. linear-gradient), picking the one that doesn’t have problems in any browsers seems the more logical choice. Anything else is just irrational “Wah, wah, is not”.

Plus the extra step of precompiling it … Don’t try to catch me with card stacking friend; I don’t fall for it.

Well, Compass actually watches for changes and compiles automatically. Ace in the hole.

Come on, admit it, that is pretty hot :wink:

My reasons for calling you on your biases are that you fail to acknowledge any of the benefits, while consistently claiming none of it is usable - you’re wrong on both counts.

You seem to think that using them properly …

I hold up your example and Salmon as incorrect uses of CSS3. At a glance both have crammed every box-shadow, text-shadow, border-radius, transition, transform and linear-gradient you could lay your hands on.
I have very little understanding of how the browser processes these rules but I can appreciate that it would take a lot of processing power to achieve. You shouldn’t expect you can throw anything at a browser and it can hold up.

Coda:
It’s time for you to buy a mac.

samanime, I agree with what you are saying.
If you have performance issues you address them using any method that works.
I haven’t run into the bottlenecks because I don’t use these browser crashing effects.

No, but you should expect reasonable requests to be handled efficiently.:slight_smile:

For example a simple border-radius on its own will slow down large applications that use many round corners. There’s an interesting article here that confirms it.

It’s always been known that certain selectors are expensive in terms of speed (universal selector I’m looking at you) but in most normal applications they are largely irrelevant. However on complex pages you do need to be careful what you use and that will vary from browser to browser.

There is no real answer and to be honest I think browsers should be able to handle most of what you throw at them without “us” having to have an in depth knowledge of how efficient each selector is and in which browser version it will slow down. Common sense should prevail but it is clear that some css3 properties do need to be optimised more efficiently by the UA.