Hi I guess it's understand the consequences and use at your own risk. I doubt a vendor will change the spelling and if they do, I'm pretty sure they'd maintain BC by allowing both to work. Using the example of *-radius, the vendor differences are more to do with what the values selected will render as rather than the naming, for instance webkit allows elliptical curves while moz only allows regular curves: http://www.css3.info/border-radius-apple-vs-mozilla/ Apparently, webkit more closely resembles the CSS3 spec. Mozilla may change their interpretation leading to possibly unexpected results (which you can then fix).
Opera is apparently going to be supporting 'border-radius' in an upcoming Presto release. The end-goal is for all the major browsers to switch to border-radius and then ignore their vendor specifc version, to avoid conflicts. There are plenty of options to create curve-edged boxes but the CSS method is the easiest programatically to implement, followed by creating PNG quadrants on the fly with Imagick or similar and positioning them using CSS. Opera allows SVG backgrounds, so they can be created on-the-fly as XML. Plenty of designers cap a box top and bottom with two curved slices but that's a pain to implement in flexible layouts. To answer a question further back, yes border-radius should be last in the list after the vendor extensions. Cheers James > They aren't "guaranteed future-compatible". > > Vendor: We propose this feature and have implemented this as -vendor-foo > > Other Vendor: Well, it has these problems, what if ... > > Vendor: OK. We've changed the way it works. > > All the slightly older clients supporting the original implementation > promptly break. > > > How would this be implemented anyway? > > Anything that looks like a vendor prefix works? > > -moz-bowder-wadius: > > Congratulations! It is "valid"! > > "But why doesn't it work?" > > Or does someone try to maintain a list of all the different extensions? The > CSS 2.1 specification lists 12 known vendors who use the vendor prefix. Who > is going to maintain a central list of all proprietary extensions and the > values they accept? How would they be versioned? > > ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *******************************************************************
