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

On Jun 26, 2012, at 3:34 PM, Sylvain Galineau <sylvaing@microsoft.com> wrote:

> [Brad Kemper:]
>> 
>>> 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.
>> 
>> I think webkit never drops anything though. I suspect that would cause them
>> drag down the advancement of logical sides in background-position (start,
>> end, head, foot), unless a way can be found for them to peacefully coexist
>> with background-position-x and background-position-y.
> 
> Past/current WebKit policies should not really be a decision factor. The reason
> we suspect WebKit folks might object should be though: a large amount of existing 
> content.

Well, sure. I thought that went without saying. They have all kinds of content besides just Web pages (and Web pages too) that they don't want to break. So they don't. I assume that is their primary motivation for never dropping support for a prefixed property. 

> If a new proposal were to extend the syntax that is already supported in 
> a backward-compatible manner - i.e. existing content remains valid and renders the 
> same - I don't see why anyone should object. Now, if the proposal involves a 
> compat-breaking syntax makeover I suspect I would agree with such objections. 

Right. That was the concern that Florian started with, that one could not easily/elegantly support both the x/y longhands and the logical keywords.

> But if we do need to break compatibility - e.g. because there is no good way to 
> align the feature with current CSS requirements -

I'm not convinced of that yet.

> then, as fantasai and Tab noted, 
> why not address the use-case properly? 

The case of spriting is best accomplished via image fragments, I agree. I think there is still something to be said for supporting logical keywords AND standardizing a couple properties that are in widespread legacy use in multiple UAs already. I think they are probably also useful even when not used for spriting, times when it is slightly more convenient to just set horizontal or vertical without setting the other. Animating backgrounds is an example, whether just for effect or for a game with a background that scrolls in two dimensions. 
 
> Either we do not want to leave content behind and we must be backward-compatible.
> Or we want a long-term standard solution to spriting 

I don't see why we can't have both. 

> and we should not shoe-horn ourselves into background-position hacking. Wouldn't spriting be useful in non-background scenarios?  

Sure. I'm not against a better way to sprite.

Received on Wednesday, 27 June 2012 05:09:05 UTC