RE: Splitting background-position in two different attributes

>Brian:
>> From a W3C perspective:
>> Please point me to the specification and section that explicitly indicate what the correct answer is for CSS3.  I cannot find it.
>I can't find an explicit indication but elsewhere in the spec, it
>seems to indicate that omitted values should default to their
>initial value. The initial value for background-position is 0% 0%.
>Therefore, I would expect the default values for
>background-position-x and background-position-y to be 0%.
>In your original example, I would expect the omitted value to be 0%. 

This breaks round-tripping, and doesn't properly represent the state of the DOM.

DIV.A {
	background: blue;
}
DIV.B {
	background-color: blue;
}

These are different internal states.  For A, all 8 properties are set.  For B, only blue is set.  A query for background is not constructible for B because answering anything implies that the other 7 properties were set to something rather than being unset.

Continuing with the example...

DIV {
	background-image: url(http://www.microsoft.com/favicon.ico);
}

Now compare the computed style for these two elements:
<div class='A'/>
<div class='B'/>

The background-image for the first (div with class A) is 'none'.
The background-image for the second (div with class B) is 'url(http://www.microsoft.com/favicon.ico)'.


>>I think getting the serialization addressed before throwing
>>more into the entanglement that is background is preferred.
>If the expectation is to push the current spec beyond CR with
>these serialization issues unaddressed, then why not add
>background-position-x and background-position-y and
>continue to leave these serialization issues unaddressed?

Because we have interoperability and predictability in the current CSS3 B&B.  Adding in unnecessary new features that (IMO) are lower property seems like a step in the wrong direction -- instability and unpredictability -- rather than progress.

Adding in new toys during CR just because "we can" seems wrong-headed and potentially puts tons of things in turmoil unnecessarily.

What makes you afraid of moving it to CSS4?  Is it because CSS3 is taking too long to progress?  Isn't it counterintuitive to add *more* to CSS3, thus making it even *slower* to progress?  Instead the model (IMO) should be more discipline about keeping things scoped so that they *can* move more quickly and so that CSS.Next isn't multiple decades away.

>If the issue is to address them within the current spec,
>then I would expect that it would be trivial to address it
>for background-position-x/-y on top of addressing it for
>the other shorthand properties.

I'm saying serialization troubles under control is more important (IMO) than adding background-position-x and background-position-y.  Can they progress on parallel tracks?  Sure.  But making serialization harder by adding more complexity just seems like, again, the wrong path to take.

>(That's not to say that
>addressing it will be trivial but that once you've solved it
>for one, I would assume the same would apply to the other.)

It's not always that simple.  Back-compat makes everything hard.  And yes, we care about back-compat impact of every approved and rejected check-in.

Received on Thursday, 18 August 2011 02:36:52 UTC