- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Sat, 18 Feb 2012 02:45:15 +0000
- To: Marat Tanalin | tanalin.com <mtanalin@yandex.ru>, fantasai <fantasai.lists@inkedblade.net>
- CC: "www-style@w3.org" <www-style@w3.org>
[Marat Tanalin:] > > 15.02.2012, 20:26, "fantasai" <fantasai.lists@inkedblade.net>: > > 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 > > Since this is not a new feature, but a feature that already have multiple > implementations, maybe just documenting these implementations would not be > too hard or destabilizing? Thanks. > No thanks. The risk of delaying B&B back to WD may be low but there is no benefit in taking it. This can wait for Level 4.
Received on Saturday, 18 February 2012 02:46:00 UTC