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.