- From: Christian Sciberras <uuf6429@gmail.com>
- Date: Sun, 21 Aug 2011 04:59:41 +0200
- To: Brian Manthos <brianman@microsoft.com>
- Cc: Jonathan Snook <jonathan@snook.ca>, "www-style@w3.org" <www-style@w3.org>
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