Re: [css3-background] New use case for background-position-x (&y!)

On 11/11/2010, Brad Kemper <> wrote:
> I think that the majority of the Working Group would probably disagree with
> that. There are implementation costs for every new property and/or value,
> and a lot of time spent considering how these might all interact with other
> properties in unexpected ways.

If you're suggesting that background-position-x would introduce issues
that would not be present with background-position, I find that hard
to perceive.  But I understand such consideration would be prudent.  I
didn't say there would be no cost, just that it would cost less.

In fact, I'm having trouble understanding why one would not create
individual properties first, and arrive at the shorthand syntax later,
rather than jumping straight into the shorthand first.

All instances of the shorthand properties that lack the individual
properties ought to have started out as separate properties, and
optimised afterwards.  Then you would have identified and resolved any
interaction issues with other properties up front.

> No, most of your objections were to the fact that we didn't consider
> spriting to be a worthy use case for the backgrounds spec, and our use of
> words like "unintended" to mean that it is not our intension to write a
> backgrounds spec in order to enable sprite use, and that we considered such
> use to be a hack.

All I'm saying is just because background-position doesn't fully
address all potential requirements for sprites, doesn't make it a
hack.  I look forward to the day I can use Media Fragments with the
same degree of excitement I look forward to working with a CSS
specification with unhindered/versatile properties.

A hack is for unexpected things, not unintended things.  If HTML >
BODY is expected to work in versions of IE that understand the child
selector, then yes, using it for such purposes would be a hack.

> I think we are all willing to listen to non-sprite reasons
> for splitting the property into two X/Y properties.

There was a suggestion from Behdad about using them independently in
CSS Animations.  That sounds good, what about that?

>> The insistence of a use case for this is a real faux pas, because I
>> feel you'd rather spend time 'bickering' about it, than providing a
>> complete API.
> Naw. Bickering has wasted chunks of my day, but specs and implementations
> take much longer. The working group always needs use cases.

As long as we’re not bickering just to avoid lengthy effort working on
the specification or implementations, that’s fine.  This issue seems
to have been raised a few times.  As an outsider, I can only (and
will) take your word for it.

(and I realized I meant analogy the minute I pressed send :( - waaay
past my bedtime!)


Received on Thursday, 11 November 2010 11:00:19 UTC