W3C home > Mailing lists > Public > www-style@w3.org > February 2012

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

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>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178290342A9B0@TK5EX14MBXC295.redmond.corp.microsoft.com>

[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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT