Re: Our position on vendor prefixed css properties

I think we may need to expand the templates. Have a way of having an
"alias" section which we can associate vendor-prefixed rules under the
content of the primary (standard) name. From there the search functionality
can look through those as well so users are taken to the right page in a
search. Then under the/a Compatibility Notes section, we can decipher
between what vendor prefixed things may do differently than the standard
one if there is a difference in structure or output.

As far as I can think the only reason to have an actual page for a vendor
prefix or attribute is when it is not on track to be a standard (or the
standard is dropped in favor of something else, like the x-webkit-speech
attribute in Chrome which is now on its way out.)


On Sun, Mar 16, 2014 at 2:18 PM, PhistucK <phistuck@gmail.com> wrote:

> ​This sounds great.​
>
>
> ☆*PhistucK*
>
>
> On Sun, Mar 16, 2014 at 7:13 PM, Eliot Graff <Eliot.Graff@microsoft.com>wrote:
>
>> Thanks, Scott.
>>
>> This sounds good. If we are talking about creating separate topics for
>> each vendor-prefixed version, I have a couple of reservations.
>>
>> 1) Where we autogenerate the list of child topics, say, on the table in
>> the CSS Properties page [1], we'll have to find a way of keeping the vendor
>> prefixed items off of the table. Otherwise, the table will be fairly
>> useless if the hundreds of -moz, -ms, -opera, -webkit, items are at the top
>> of the table.
>> 2) I fear (and this may be unwarranted) that having border-radius,
>> -moz-border-radius, -ms-border-radius, -opera-border-radius, etc. all on
>> the same site may adversely affect search results for the unprefixed topic.
>>
>> Because of things like that, I wonder if we could not have the canonical,
>> unprefixed topic with a section for vendor-prefixed versions? It could be
>> as simple as:
>>
>> <h3>Vendor-prefixed use</h3>
>> The border-radius property was implemented as -moz-border-radius (Firefox
>> 1.7 and earlier), -webkit-border-radius (Chrome .2; Safari 3.0).
>> [[Include all prefixed versions, write about notable changes or variances
>> from the spec, mention continued support.
>> Etc.
>>
>> And can include all of the things you note below.
>>
>> Thoughts? If you're already suggesting that this be in the original
>> topic, then, in the words of Emily Latella, "Nevermind."
>>
>> Thanks,
>>
>> Eliot
>>
>> [1] http://docs.webplatform.org/wiki/css/properties
>>
>>
>>
>> From: Scott Murray [mailto:shm@alignedleft.com]
>> Sent: Friday, March 14, 2014 9:29 AM
>> To: Paul Verbeek
>> Cc: PhistucK; Rob^_^; public-webplatform@w3.org
>> Subject: Re: Our position on vendor prefixed css properties
>>
>> Yes, to provide a little more context to Paul's comment:  If the goal is
>> to provide comprehensive documentation, then all the (messy) vendor
>> prefixes should be included.  But, since the prefixed properties usually
>> behave the same as the "official" one, in most cases we could avoid
>> duplicating descriptions, and instead include a note like, for example:
>>
>>         -moz-border-radius matches the standard behavior
>> of border-radius, though it is only recognized by Mozilla-based browsers;
>> please reference documentation for border-radius.
>>
>> In cases when the vendor-specific does not sync with the standard, this
>> could read:
>>
>>         -moz-border-radius diverges from the standard behavior
>> of border-radius, and is only recognized by Mozilla-based browsers.
>>         …[full documentation of this implementation follows]…
>>
>> The actual language used can change; I just want to propose avoiding
>> duplication of documentation, while still aiming to be comprehensive.
>>
>> [P.S. This is my first post, and I am new to WebPlatform, so hello!  I
>> just met Doug, Paul, Jen, Julee, and others at the Fluent Doc Sprint on
>> Tuesday.]
>>
>>         Cheers,
>>         Scott
>>
>>
>>
>>
>> On Mar 13, 2014, at 11:23 AM, Paul Verbeek <paul@webinthehat.com> wrote:
>>
>>
>> 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
>> Sent: Thursday, March 13, 2014 7:38 AM
>> To: Paul Verbeek ; 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.
>>
>>
>>
>>
>