Re: [lots] -webkit prefixed properties and values

On 12/10/2015 01:44 PM, Tab Atkins Jr. wrote:
> On Thu, Dec 10, 2015 at 10:14 AM, Dean Jackson <dino@apple.com> wrote:
>> It’s the vendor prefix that I don’t want in a main specification, especially
>> when there is now a standard deployed solution without the prefix.
>> I’m not denying their place in the Web.
> 
> They're not vendor prefixes anymore, tho, at least on these
> properties.  They've been implemented by other vendors, so they're
> just aliases which happen to resemble the old vendor-prefix system.
> That's the point.

One important caveat here: not all of these prefixed features are
identical or even similar to their modern versions.  So, their emulation
may be imperfect & may vary across implementations.

One simple example is "-webkit-gradient(radial, ...)" -- see details
below[1] on differences between that feature & its modern incarnation.
One other example is "display: -webkit-box" -- we're planning on
emulating that by mapping its syntax to use modern flexbox properties,
which is pretty good but not perfect.

For features like these which can't be 100%-faithfully emulated using
modern equivalents, my preference would be:
 * I'd rather that the spec text be non-normative; I'd like to give
browsers room to experiment with different emulation strategies &
different levels of support.
 * I'd rather the spec mark these features as deprecated/discouraged.
Since UAs (Mozilla at least) implement them imperfectly -- purely in the
interests of rendering something reasonable (but not necessarily the
exactly-right thing) for legacy content -- we don't want to encourage
authors to build new web content on top of them and make strong
assumptions about browser support.

So, I tend to agree with Dean here; I'd rather keep webkit-prefixed
features out of "official" CSS specs (except maaaaybe in cases where
they can be true trivial aliases), and I'd like to guard any mentions
that do exist with deprecation/legacy notices of some sort.  While these
features *are* part of the current web, I don't want to encourage
authors to rely on these features in new content, given that they have
better-supported modern options which are just as easy to use & which
have better compatibility going forward.

~Daniel

[1] Details on -webkit-gradient(radial, ...) and Mozilla's plans for
imperfectly emulating it:
 * The -webkit-gradient(radial,...) syntax requires the web developer to
specify *two arbitrary circles*, and webkit renders a gradient that
progresses from one circle's edge to the other circle's edge.
 * In contrast, modern "radial-gradient()" syntax only uses a *single*
circle (or ellipse), and the gradient always progresses from that
circle's center to its edge.
 * For simplicity/code-sharing, Mozilla's emulation of this prefixed
feature (in Nightly, preffed off) works by converting it to a
hopefully-similar modern radial-gradient() expression. We choose the
smaller of the two circles that the author provided, and we pretend that
smaller circle is just a point at the center of the larger circle.
Then, we create a modern radial-gradient() expression to represent that
result. This seems to be "good enough" for usability, on the sites that
we've seen which depend on this feature.

Received on Thursday, 10 December 2015 20:08:27 UTC