All I ever see is linear and radial (radius to centre).

A gradient which ran around a circle would be really useful i.e. the colour changes follow the circumference
of the circle. Also a gradient which allowed you to specify a path for the colours to follow would be awesome.

Seriously? Those includes are so difficult to maintain from the server, right? Not.

Discussion about prefixes is old thought and does not really fit this post.

traq: different implementation = different prefix (as in my second example), same implementation should be same prefix

mdriftmeyer: I thought more code = more code to maintain, but I guess it’s not your case?

Now, do us all “web designers who are tired of nonsense” a favor and take your great opinion and go put it in the Internet Explorer/Trident developer blog. It makes much more sense there. 🙂

However, you’re complaining about adding a few lines of code which if you put in a master .css file and import your custom files specific to your site development [a normal process] this somehow puts undue levels of work on your part?

I’d rather have vendor specific prefixes for functionality that may or may not even be working when one is developing and testing across multiple platforms. It’s much easier to comment out those areas and continue testing than to hope every vendor is up-to-speed for specific areas of CSS functionality.

The only way -gradient will ever work is if they are all using the same backend code to produce the desired result.

I agree with your frustration (especially about having multiple properties / syntaxes for a _single_ browser — I don’t see _revised_ vendor properties being practical at all), but asking all “beta” implementations support the same property name “{first-vendor-prefix}” or “-beta”) is even less practical.

The whole reason there is a prefix in the first place is that the vendors are quite likely to have different implementations. Major or minor differences, it’s hardly an “ego” issue. Without vendor prefixes, we’d be forced back into using browser sniffing to get just about _anything_ to display correctly.

filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr=’#FFFFFF’, EndColorStr=’#000000′);
-ms-filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr=’#FFFFFF’, EndColorStr=’#000000′);
background-image: -webkit-gradient(linear, color-stop(0, white), color-stop(1, white))
background-image: -webkit-linear-gradient(white, black);
background-image: -moz-linear-gradient(white, black);
background-image: linear-gradient(white, black);

Don’t you just realize this is ridiculous?
Can’t you just support mozilla’s prefix rather than adding yet another function that you (developers) and us (css coders) will have to support for years to come?

Many other CSS3 features have the same syntax in multiple browsers, still we have to write the same identical crap over and over, RATHER THAN doing like so:
-(the prefix of the vendor who introduced this first)-border-radius: 10px;

Or just
-beta-border-radius: 10px; /* A List Apart’s idea */

No – you just have to use custom-named functions to support your ego.

If YOU VENDORS didn’t make such ridiculous mistakes, we could “just” use:

filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr=’#FFFFFF’, EndColorStr=’#000000′);
background-image: -beta-gradient(linear, color-stop(0, white), color-stop(1, white))
background-image: -moz-linear-gradient(white, black);
background-image: linear-gradient(white, black);

Those might just be 2 lines you saved, but then repeat that for every function for every elements that uses it in your page and you’ll realize that 10% of your CSS is redundant.

– a web designer who’s tired of nonsense