Re: Splitting background-position in two different attributes

Brian,

In general I agree with arguments about unnecessary features added for
the sake of it, but I think the features we're talking about pretty
much define the spec.

All these discussions made me think, if we're still contemplating on
how the CSS state should be represented, I think the "standard" simply
is NOT ADEQUATE.

We ended up arguing not the usefulness of these features, but how they
should be affecting the initial CSS system.

I think it would do us good if we forgot all about CSS3 / 4 and
instead focused on what we want to accomplish,
in a structured and well planned manner, instead of a standard sewn up
from different opinions...

All these years...and we haven't learned anything at all. Except maybe
getting browser vendors talk to each other. *sigh*




On Thu, Aug 18, 2011 at 4:36 AM, Brian Manthos <brianman@microsoft.com> wrote:
>
> >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 Sunday, 21 August 2011 03:00:09 UTC