- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 9 Dec 2015 15:17:39 -0800
- To: Dean Jackson <dino@apple.com>
- Cc: www-style list <www-style@w3.org>
On Wed, Dec 9, 2015 at 2:15 PM, Dean Jackson <dino@apple.com> wrote: >> On 10 Dec 2015, at 08:19, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> Per the Compat Spec <https://compat.spec.whatwg.org/>, there's a >> decent-sized list of CSS at-rules, values, and properties that need to >> be supported with a -webkit- prefix in order to be web-compatible: >> <https://compat.spec.whatwg.org/#css-compat-section>. >> >> Since implementors have to support these in order to realistically >> support web content, they should be listed alongside the features in >> the relevant specs (rather than sidelined into an easy-to-miss errata >> document like they currently are). > > I disagree. The existing implementors (obviously) know about > these properties. New implementors are unlikely to start from > scratch. And even if they do, the number of new implementors > that appear each year can be rounded to about zero. As Ms2ger responded, new implementations *do* show up, and when they do, this knowledge is *not* obvious or ingrained. Servo is a new project *within Mozilla* and they've had to do a lot of work to transfer over some of this "implicit knowledge". > Honestly, I don’t think it’s worth advertising these properties > any more than they currently are. The sooner we stop talking > about them, the sooner we can remove support (even if that > is many years away). It would be listed as an "implementors MUST, authors MUST NOT" sort of thing. Pretending they don't exist isn't helping existing implementors. >> I'm planning to do this for all the specs I control. Would others >> please do the same? The specs in question are: >> >> * Images > > I assume here you’d have to describe the legacy gradient > syntax that WebKit implemented before the specification > changed? According to the Compat spec, yes. Edge and Nightly Firefox have both implemented that. Servo would have to as well, as would any other new implementor. > This is another example of why I think they > shouldn’t be in the primary specification: I don’t want any > Web authors discovering them. The specification should > only talk about the correct way of doing things. The compatibility > specification seems like the right place for old/incorrect > or deprecated stuff. This is not our general policy for errata and legacy stuff. We usually put them in an appendix with a strong warning for authors not to use them, like I'm proposing. ~TJ
Received on Wednesday, 9 December 2015 23:18:28 UTC