RE: Our position on vendor prefixed css properties

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.

Received on Sunday, 16 March 2014 17:14:50 UTC