W3C home > Mailing lists > Public > public-webplatform@w3.org > March 2014

Re: Our position on vendor prefixed css properties

From: Scott Murray <shm@alignedleft.com>
Date: Sun, 16 Mar 2014 10:21:12 -0700
Cc: Paul Verbeek <paul@webinthehat.com>, PhistucK <phistuck@gmail.com>, Rob^_^ <iecustomizer@hotmail.com>, "public-webplatform@w3.org" <public-webplatform@w3.org>
Message-Id: <A67FAB45-A420-4814-B81C-B1ADA6203C31@alignedleft.com>
To: Eliot Graff <Eliot.Graff@microsoft.com>
Thanks, Eliot.  That wasn't what I was suggesting, but I like your proposal better.  (I'm just not familiar enough with the system yet to understand what's possible and what isn't.)

I support your idea, and always support removing clutter in favor of simplicity, as long as someone searching for, say, -webkit-border-radius can still locate that information.  (Ideally, the page listing all CSS properties could also have dynamic filters so, for example, it could quickly show me all the properties that have -moz prefixes… but that could be asking for too much.)

	Cheers,
	Scott


On Mar 16, 2014, at 10:13 AM, 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.
> 
> 
> 
Received on Sunday, 16 March 2014 17:21:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:13:59 UTC