- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 15 Feb 2012 17:26:23 +0100
- To: www-style@w3.org
On 02/15/2012 04:56 PM, Florian Rivoal wrote: > On Wed, 15 Feb 2012 16:04:26 +0100, Sylvain Galineau <sylvaing@microsoft.com> wrote: > >> [Florian Rivoal:] >> >>> Three browsers / two engines (trident and webkit) support background- >>> position-x and background-position-y, and do so unprefixed. >>> >>> If people against it can convince people shipping it to drop support, I'd >>> be satisfied, as that would force authors to move back to standard >>> compliant ways of doing the same thing. >>> >>> Since I doubt this will happen, I'd like to have it specified. >> >> If it does cause breakage then that does sound reasonable. Do you have examples? > > Sure. All mobile gawker properties are affected (m.gawker.com, m.gizmodo.com, > m.lifehacker.com...). The smartphone version of google's search page used it > for a while too (it appears to be gone now). In both cases, it is used for > spriting purposes, and not supporting it makes the page ugly and > dysfunctional. > > I have also pasted at the bottom of this mail a list of sites out of alexa's > top 10000 that grep positively to background-position-(x|y). Not all of these > are broken due in browsers that don't support the properties, but it illustrates > that the cat is out of the bag. > >> Also, does your subject line header indicate you want to address this in the current level? > > I have no strong opinion about this. If it can be done in the current level > without delaying it, why not. Otherwise, next level is fine. It may or may not delay REC, but it will certainly delay CR. CSS3 Backgrounds and Borders is feature-complete, and has been stable since 2010. Adding this will destabilize it again. I do not care whether it delays REC or not, I do not want to pull this module back to Working Draft. ~fantasai
Received on Wednesday, 15 February 2012 16:26:57 UTC