- From: James Graham <jgraham@opera.com>
- Date: Wed, 04 Apr 2012 13:11:13 +0200
- To: Tobie Langel <tobie@fb.com>
- CC: "public-coremob@w3.org" <public-coremob@w3.org>
On 04/04/2012 11:36 AM, Tobie Langel wrote: > > > On 4/4/12 10:29 AM, "James Graham"<jgraham@opera.com> wrote: > >> I think it is clear that we should never test for prefixed things, >> including as an optional pass condition e.g. we shouldn't have tests >> that pass with either a correct implementation of a "foo" CSS property >> or of a "-o-foo" CSS property. >> >> Prefixed things are not supposed to be part of part of the interoperable >> web platform; they are in essence proprietary features. > > This isn't true. A feature isn't proprietary because of its prefix but > because it isn't available royalty-free. If it helps forget the word "proprietary". The point is that prefixed features are — excluding cases where all vendors cave to the pressure to implement another vendor's prefixed feature — not part of the interoperable web platform. They are inherently single-vendor even in cases where multiple vendors implement almost exactly the same thing with different names. >> When people use >> prefixed things in production, they become part of the de-facto platform >> (people can't drop the prefixes without breaking sites), thus causing >> fragmentation. When vendors fix this fragmentation by implementing other >> vendor's prefixes people get upset. None of this is beneficial to the >> platform as a whole. > > What's not beneficial to the platform is to keep sucking. Whether we like > it or not using prefixed features today makes it suck less. And developers > are relying on them on a day to day basis. No, people relying on prefixed features makes the platform suck more. It causes fragmentation and over the long term causes maintenance problems. It encourages people to write single-UA sites, thus foregoing a key advantage of the platform as a whole. The tension arises from the fact that using such experimental features can, in the short term, make individual sites suck less (or even make them possible at all) — but only in the specific UAs for which they were written. The way to relieve this tension is not to embrace the short term viewpoint and ignore the long term damage. It is to ensure that things that people want to use today are made into part of the interoperable platform asap. Historically the W3C has been extremely poor at doing this. Today it is getting a little better, but it is far from perfect. We can exert pressure to fix this, and ensure that the priority order of WGs and implementors matches that of authors. Embracing prefixes undermines this goal. >> If there is some technology that we think out to be part of the >> interoperable platform, but is only available prefixed, we should fix >> that by making vendors implement the unprefixed form. If there is some >> bureaucratic reason they are avoiding this e.g. WG Process issues, we >> should put pressure on the relevant people to fix those issues rather >> than endorse the brokenness. > > I argue we should do both in parallel. You said it yourself, prefixed > implementations have become a de-facto standard. And that is a bad thing. You must have noticed the outcry when multiple vendors announced their intention to accept that various -webkit- prefixed CSS properties have become de-facto required to work with the modern mobile-targeted web, and implement those features. I hope it is an explicit goal to make that something that never happens again. > Coremob level 0 is descriptive, it is therefore quite logical for it to > tolerate certain features (which ones exactly is TBD, but that shouldn't > be to difficult to agree upon) being available prefixed-only on some > platforms, as that is a correct description of the current state of the > world. I don't see any value in such a description; sites like caniuse.com already exist. In my opinion "level 0" should focus on interoperability of features that are actually part of the platform (i.e. have some non-prefixed implementations). > However, Coremob level 1 aims to be prescriptive rather than descriptive > and will explicitly require features to be available prefix-free. That sounds good. All levels should take the same approach. > Input from Coremob members, and especially from developers in the > trenches, would be very valuable information to bring back to the CSS WG > and to the various parties working on improving the W3C process. I entirely agree.
Received on Wednesday, 4 April 2012 11:11:53 UTC