hopefully someone with CSS skills can fix this. chrome and FF do work perfectly !

thanks Eric for this nice coding ! :)

I wanted to make a comment, but kept thinking of Remy Sharps post http://remysharp.com/2012/02/09/vendor-prefixes-about-to-go-south I think the section detailing Who’s guilty is telling.

Here’s hoping for the best

that once vendor extensions are implemented in other browsers we are stuck with them forever, just like the User Agent string

That’s a paraphrase, but it was a great example.

Therefore, it’s very difficult for a browser to implement properties found in another browser, even if it is open source. See how the .doc format took ages to be supported by Open Office (granted, Word is not open source).

“border-radius:5px” means “border-radius as defined by the CSS spec”. As long as the spec is final and everyone agrees on what it says, developers can use this and browsers can implement this.

“-webkit-border-radius:5px” means “border-radius as defined by the Webkit implementation”. As long as this implementation is final and everyone agrees on what it is, developers can use this and browsers can implement this.

There is no difference between a CSS property that is defined “officially” and one that is defined by a browser, provided that the two criteria above hold. If they don’t then it would be a bad idea for browsers to copy another browser’s implementation, but I’m sure they will only do this for features that are considered stable enough.

This does bring up a new problem, which is that it almost condones browser vendors coming up with their own fancy features outside of the standards process. After all, if webkit implements -webkit-blink and it catches on, other browsers can simply copy the implementation. However, this is a completely separate problem and I hope browser vendors remember enough about history that they will avoid doing that.

1. “Oooh! Shiny things!”

This is an oversimplification, but close enough to the reality all the same. When developers take this tack to their non-vanity-slash-non-skills-dev projects, they’re doing an awful disservice to those of us who actually need to make a living outside of hothouse environments. This is doubly true for the people who then proceed to leap onto forums and scream and holler until they get what they want.

2. “I saw {x} on Somebody Else’s site, and I want you to implement it on mine.”

It’s hard for me to be upset with these people, at least until they utterly fail to understand the constraints, caveats, and cost concerns that usually attend such requests when done right.

…And as for commitment: people in general are wired to maximize their return on investment of effort. When that return is measured in dollars, I imagine that Web developers are no different in their differences and similarities than other professionals.

Abusing vendor prefixes is a great way to pander to that reality, and a lousy way to keep the Web from breaking. I’d rather face something like this than the “to hell altogether with the other vendors’ implementation of this feature” attitude that was prevalent until ten or so years ago… but it will have the same effect: product will take more time to build and test than if we stick with the status quo. Frameworks can help with that problem, but only so much.

Beyond that, it feels like the responsible authorities are trying for a repeat of HTML 3.0. That wouldn’t end well at all.

So, for example, Webkit’s syntax for gradients is different than Mozilla’s. If Mozilla, in addition to their own -moz- syntax, decided to support the -webkit- syntax it doesn’t seem like it hurts anything. As long as the -moz- syntax takes precedence over the -wekit- syntax in the Mozilla browser, and as long as Mozilla commits to match the Webkit -webkit- behavior as closely as possible, then it seems like developers get the best of both worlds.

For developers who didn’t care to optimize both, the Mozilla browser will look better than nothing. For developers who do care, they can continue to target the Mozilla browser as they do today. If inconsistencies arise between the Mozilla -webkit- implementation and the WebKit -webkit- implementation then it’s Mozilla’s responsibility to try to address those as bug fixes, but they can continue to leave -moz- as is. This means that any change in the behavior of the -webkit- prefixed properties in a Mozilla browser will be to move those properties to more closely match the behavior that the developer actually tested against (it would be crazy for a developer to test only in firefox, but use only the -webkit- property).

What am I missing?

It should not be the responsibility of the browsers to avoid “breaking” the web due to legacy code hanging around. Doing so will paint all the developers that code responsibly into a corner again.

In the case of border-radius or background gradients, how would that work. There was a lot of churn early on on how -webkit, for example, handled those. Which version would Mozilla pick up on that?

My gut and my mind both say this stinks of a a really bad idea.

Leave things like -webkit- or -moz- for features that really are limited to those rendering engines.

Is there any known workaround to keep the inner div fixed?