- From: Jon Rimmer <jon.rimmer@gmail.com>
- Date: Thu, 17 Nov 2011 17:10:42 +0000
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Alex Mogilevsky <alexmog@microsoft.com>, "www-style@w3.org list" <www-style@w3.org>
On 17 November 2011 16:03, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> We already co-cascade, except that the unprefixed version always wins.
> What benefit does this change bring? If you want to support
> down-level clients who don't yet understand the unprefixed version,
> that happens automatically if you just use both the prefixed and
> unprefixed property.
Seems to me that the difference is that right now authors are
*required* to include, for example, -moz-transition-property,
-o-transition-property, -webkit-transition-property and
-ms-transition-property, even if all the actual property value on each
is the same, because the browsers won't recognise the unprefixed
value.
With this suggestion, the browsers would start supporting unprefixed
properties as soon as the property was vaguely stable. That way
authors would have the choice to use prefixes when necessary, to work
around incompatibilities between implementations, but wouldn't *have*
to duplicate properties when behaviour is cross-compatible and hasn't
changed for years.
I did consider suggesting something like this myself, but I foresaw
the objection that it would weaken prefixing as an indication that the
feature is technically considered unstable. Maybe you could add some
kind of explicit opt-in, like...
@compatibility {
unprefix-experimental-properties: true;
}
...or whatever. Yeah, it'll just end up getting added into
boilerplate, but that's no worse than what already happening.
Jon
Received on Thursday, 17 November 2011 17:11:10 UTC