4 ms·

> When the feature is standardized the prefixes are dropped. More accurately, when the feature is standardized most browsers recognize both the the prefixed an

> When the feature is standardized the prefixes are dropped. More accurately, when the feature is standardized most browsers recognize both the the prefixed and unprefixed versions. This is still a significant competitive advantage for Webkit since there will be a lot of legacy content out there that uses only the -webkit prefixed name. This situation is an incentive for Webkit contributors Apple and Google to delay disclosure and standardization of these features as long as possible, and the W3C discussion above indicates they are doing just that. > What you are proposing is to strip developers of the ability to test out non-standard features. If it's only the developers we're inconveniencing, then sure let's have the W3C dictate that prefixed features are available in preview/beta/canary builds but disabled in builds intended for non-developer release. That would create some healthy pressure to get things standardized quickly, eh? > If you want to only support standardized features then only support standardized features. Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them.

MatthewPhillips 15y ago
> More accurately, when the feature is standardized most browsers recognize both the the prefixed and unprefixed versions. This is still a significant competitive advantage for Webkit since there will be a lot of legacy content out there that uses only the -webkit prefixed name. This situation is an incentive for Webkit contributors Apple and Google to delay disclosure and standardization of these features as long as possible, and the W3C discussion above indicates they are doing just that. I think you're misattributing malice here. This isn't a WebKit only issue, this is a first-to-market issue. When some new css or js feature is proposed and vendors implement it with the prefix, some developers rush to hack on it, submit their demos to HN, and then forget about it weeks later. They don't bother to go back and update the css later with other prefixes. The same issue exists when WebKit isn't the first to market. WebKit doesn't support calc() yet. Mozilla does. Plenty of abandoned webpages will never be updated with other prefixes. But are these serious websites/businesses? Is Facebook or Twitter sticking in -webkit and never bothering to go back? >Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them. Legacy content would still be broken because sparkle will likely be changed in the process of standardization. IndexedDB has seen some dramatic changes in the course of its development; all those sites that implemented an earlier version will be broken when the standard is finalized. The vendor prefix sends a warning to the developers. Browser sniffing is a far bigger problem than vendor prefixes. Google is one of the worst offenders, especially in mobile where they send UAs not equal to iOS or Android to some poorer version.

MatthewPhillips 15y ago

> More accurately, when the feature is standardized most browsers recognize both the the prefixed and unprefixed versions. This is still a significant competitive advantage for Webkit since there will be a lot of legacy content out there that uses only the -webkit prefixed name. This situation is an incentive for Webkit contributors Apple and Google to delay disclosure and standardization of these features as long as possible, and the W3C discussion above indicates they are doing just that. I think you're misattributing malice here. This isn't a WebKit only issue, this is a first-to-market issue. When some new css or js feature is proposed and vendors implement it with the prefix, some developers rush to hack on it, submit their demos to HN, and then forget about it weeks later. They don't bother to go back and update the css later with other prefixes. The same issue exists when WebKit isn't the first to market. WebKit doesn't support calc() yet. Mozilla does. Plenty of abandoned webpages will never be updated with other prefixes. But are these serious websites/businesses? Is Facebook or Twitter sticking in -webkit and never bothering to go back? >Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them. Legacy content would still be broken because sparkle will likely be changed in the process of standardization. IndexedDB has seen some dramatic changes in the course of its development; all those sites that implemented an earlier version will be broken when the standard is finalized. The vendor prefix sends a warning to the developers. Browser sniffing is a far bigger problem than vendor prefixes. Google is one of the worst offenders, especially in mobile where they send UAs not equal to iOS or Android to some poorer version.