Re: Our position on vendor prefixed css properties

I just discussed this with Doug and Scott Murray, and we came with the
following:
Some vendor prefixed pages have a different behavior than the standard
version, others have special notes on it (like the -ms-radial-gradient is
only implemented in IE preview versions). So we leave all the prefixed
pages, linking to the standard page and adding notes and examples when
necessary.

This is probably the most useful for people searching for information on
the prefixed version of a css property.


On 13 March 2014 00:34, PhistucK <phistuck@gmail.com> wrote:

> Maybe we should include this information in the page of the standard
> property. Having a compatibility table that reads "prefixed" next to a
> version might not be enough, especially for properties that are still not
> supported in their standard version across the board, or that older
> browsers with a lot of market share still do not support their standard
> version.
>
> I think a page should exist for every vendor prefixed feature (be it CSS,
> JavaScript or HTML) - but it should not contain any information and only
> redirect to the standard version, where information regarding all of the
> versions of that feature (prefixed and standard) would be available.
>
>
> ☆*PhistucK*
>
>
> On Thu, Mar 13, 2014 at 3:52 AM, Rob^_^ <iecustomizer@hotmail.com> wrote:
>
>>   Hi Paul and Eliot,
>>
>> I think its important that they are not only left in, but that they are
>> expanded to include webkit and moz prefixes...
>>
>> for interoperability and backwards compatibility website developers are
>> required to use vendor specific prefixes in their css.
>>
>>
>> eg.
>>
>>
>> .pop.in{     animation-delay: 0s;     animation-duration: 1s;     animation-name: popin;     -webkit-animation: popin 1s 0s alternate both;     -o-animation-delay: 0s;     -o-animation-duration: 1s;     -o-animation-name: popin;     -webkit-transform: scale(1);     tansform: scale(1);     -moz-transform: scale(1);     -o-transform: scale(1);
>> }
>>
>> commonly in support forums...developers will declare... ‘it works in browser X but not in browser y’
>>
>> the stock answer may be ‘you haven’t included the vendor prefixed rules for your version of the browser’ or ‘you haven’t included the standard rule’ for compliant browsers.
>>
>> Perhaps as with depreciated html elements, the documentation should state the Standard css property that replaces the vendor prefixed property rule.
>>
>> I have a full listing of vendor prefixed css rules if you wish... or you can query a browser support by typing
>>
>> document.body.style
>>
>> in the console tab of the browser’s DOM inspector (Page inspector, IE f12 or Dragonfly or FireBug).
>>
>> Regards.
>>
>>
>>
>>  *From:* Eliot Graff <Eliot.Graff@microsoft.com>
>> *Sent:* Thursday, March 13, 2014 7:38 AM
>> *To:* Paul Verbeek <paul@webinthehat.com> ; public-webplatform@w3.org
>> *Subject:* RE: Our position on vendor prefixed css properties
>>
>>
>> Remove.
>>
>>
>>
>> These were likely left over from the original import of the content on
>> MSDN, where they are appropriate. They don’t really apply to Webplatform
>> docs.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Eliot
>>
>>
>>
>> *From:* verbeek.p@gmail.com [mailto:verbeek.p@gmail.com] *On Behalf Of *Paul
>> Verbeek
>> *Sent:* Wednesday, March 12, 2014 1:29 PM
>> *To:* public-webplatform@w3.org
>> *Subject:* Our position on vendor prefixed css properties
>>
>>
>>
>> I was looking through the site and found a few css properties that are
>> vendor-prefixed, like
>> http://docs.webplatform.org/wiki/css/properties/-ms-radial-gradient.
>>
>>
>>
>> Are we adding are this vendor prefixed pages or removing them? I would go
>> for the latter. Especially in this case because, as far as I know, there
>> was never a stable IE version that had this property.
>>
>>
>>
>> Paul.
>>
>
>