[webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)

[Adam Barth]

On Fri, Oct 4, 2013 at 1:37 PM, Dean Jackson <dino at apple.com> wrote:
> On 5 Oct 2013, at 6:22 am, Adam Barth <abarth at webkit.org> wrote:
>> On Fri, Oct 4, 2013 at 12:08 PM, Dean Jackson <dino at apple.com> wrote:
>>> On 3 Oct 2013, at 4:46 am, Christian Biesinger <cbiesinger at chromium.org> wrote:
>>>> On Tue, Oct 1, 2013 at 8:26 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>>>> On Tue, Oct 1, 2013 at 4:53 PM, James Craig <jcraig at apple.com> wrote:
>>>>>>
>>>>>> Follow-up question:  Since this hasn’t made it into the CSS4 spec yet,
>>>>>> should we temporarily use “-webkit-alt” for the property name? I know there
>>>>>> has been a push to move away from vendor prefixes lately, so if there are no
>>>>>> objections, I propose we use the unprefixed version.
>>>>>
>>>>> I think that's what Mozilla and Google are doing but I don't think we
>>>>> necessary have to follow the suit.
>>>>
>>>> FYI, because IMO this is an important clarification - Mozilla and
>>>> Google use unprefixed versions only *behind a (runtime) flag*, until
>>>> the spec is stable. That way experimental features are not exposed to
>>>> the web at large until it is unlikely that the spec will change, to
>>>> avoid cross-browser compatibility risks.
>>>
>>> We decided on a slightly different approach, which is to prefix things
>>> but enable them by default in nightly builds. That way a port must still
>>> decide at their shipping time whether or not to enable the feature.
>>>
>>> In the Moz + Google case, the experimental form is exposed unprefixed to a small
>>> number of users on the Web. In our case, the experimental form is exposed
>>> prefixed. We concluded that we’ve changed things enough times while prefixed
>>> that it was worth the extra “this is experimental and may change” notice.
>>
>> Does this imply that you'll remove the prefixes before shipping the
>> features in a production release?
>
> I can’t speak for anyone other than the Apple port, and even there I’m
> definitely not the official word on the topic, but I don’t think that is
> implied. It’s likely going to depend on perceived stability of the feature,
> testing, community feedback, etc.
>
> The important thing is that our goal is to get to the unprefixed stable form
> as soon as possible.
>
> Also, our prefixing/unprefixing rules are not set in stone. I think the community
> will evaluate them case by case.

I would encourage you (and others) not to ship new vendor-prefixed
APIs in production releases.  If the feature isn't stable enough to
ship without a prefix, it's also harmful to the web ecosystem to ship
with a vendor prefix.

Adam