RE: [css4-background] background-position-x and background-position-y or logical directions


[Florian Rivoal:]
> 
> On Mon, 25 Jun 2012 23:41:33 +0200, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> 
> >> If the plan is to solve this use case (spriting), we should do a
> >> better job than using background-position hacks.
> >
> > I'm with fantasai.  The only use-case I've ever seen for
> > background-position-x/y is image spriting, but bg-pos is really shitty
> > for spriting.  The right way is to either use Media Fragments, or come
> > up with something else in CSS that accomplishes the same thing.
> 
> I understand the sentiment, but not implementing background-position-x/y is
> a difficult position to maintain when it is supported by browsers with a
> combined market share of maybe more than 70% (ie + chrome + safari).
> Content is being written for it, and lacking support causes issues.

I think it is being suggested that a very large fraction of the content that 
does depend on these properties targets background spriting. If that is true 
then it is imo legitimate to suggest that we would be better off addressing 
the scenario with better tools so as to deprecate these properties. Yes, I 
understand just adding support for them may be the cheaper engineering solution 
at the moment; still, I am not aware of any evidence that suggests these properties
were designed for spriting i.e. this approach may be relatively cheap, fast and 
compatible with conotent *and* also suboptimal for implementors and authors alike.

If it isn't true true that spriting is the primary/main use-case then we need to make 
sure we understand the other use-cases so that we can in fact standardize these
properties properly for everyone.
 
> If you're willing to drop support for it, the question will be much easier
> to settle. Until then, the temptation to add support for it in Opera (and
> maybe Mozilla, but I can't speak for them) will remain.
> 
Speaking for ourselves I think we have established we are willing to drop features to 
the extent there is a standard equivalent e.g. see the legacy IE filter property in 
IE10 [1]. I cannot say whether or when we would flip this particular switch at the 
Moment but in principle we have no opposition to dropping support for legacy features 
given solid interoperable standard alternatives.

[1] http://blogs.msdn.com/b/ie/archive/2012/06/04/legacy-dx-filters-removed-from-ie10-release-preview.aspx

Received on Tuesday, 26 June 2012 15:51:15 UTC