W3C home > Mailing lists > Public > www-style@w3.org > August 2011

Re: Splitting background-position in two different attributes

From: Christian Sciberras <uuf6429@gmail.com>
Date: Sun, 21 Aug 2011 04:59:41 +0200
Message-ID: <CAD6s_Xvr1OUSZCGuur0=81kNhBG+CR-LnveXvAGTez97uTNm3w@mail.gmail.com>
To: Brian Manthos <brianman@microsoft.com>
Cc: Jonathan Snook <jonathan@snook.ca>, "www-style@w3.org" <www-style@w3.org>

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

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:49 UTC