Re: [css3-background] background-position-x background-position-y

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.

Received on Wednesday, 15 February 2012 22:08:40 UTC