- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 21 Aug 2013 15:22:41 -0700
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>, Peter Sloetjes <pjs.nl@live.com>
On Wed, Aug 21, 2013 at 3:14 PM, L. David Baron <dbaron@dbaron.org> wrote: > On Wednesday 2013-08-21 14:58 -0700, Tab Atkins Jr. wrote: >> On Wed, Aug 21, 2013 at 2:46 PM, L. David Baron <dbaron@dbaron.org> wrote: >> > I think this is a really bad idea (which has apparently now made its >> > way into the spec according to comments in >> > https://bugzilla.mozilla.org/show_bug.cgi?id=903239 , although I >> > don't see any mention in this thread of it). >> > >> > The underlying mental model of setProperty has, I think, always been >> > "append declaration". The object model of declaration blocks was >> > designed without an idea of preserving order; setProperty appends a >> > declaration to the end. Thus setProperty with no priority being a >> > no-op if the declaration block already has an !important declaration >> > for that property. >> >> I don't think it's ever been clear that the mental model was "append a >> declaration". The style OM is, as you say, an unordered dict. The >> underlying data has an order, but we lose that detail, along with >> several others, in the translation to the OM. Preserving the ordering >> quality in one, somewhat hidden, way seems like a recipe for >> confusion. > > Also, we're going to need to change to preserving order in order to > support logical properties. Having things like margin-start, > margin-before, etc., requires preserving their order relative to > margin-left, margin-top. So all CSSOM operations on declarations > will need to define what effect on order they have. Wait, why? Why is margin-left/start any different from border-color/left? Both are two shortcuts that touch the same longhands. We don't need anything special for ordering the border-* properties. >> It would be easy to argue that many parts of our OM weren't designed >> well, but that's not what you're doing here. (For example, we could >> have exposed a list of declarations which is mutable, and a dict of >> all properties/values which reflects the cascade and which is >> read-only.) >> >> > I also think the use case is really obscure, and having to make an >> > extra function call to address it (as today) is fine. I don't see >> > strong evidence that we need to change the Web platform to address >> > it. >> >> I think it's quite reasonable to want an easy operation for "set this >> property to this value". When you're already in JS, the importance >> doesn't matter nearly as much. > > I'm not convinced. It's conceptually much more complex to depend on > what's already in the declaration in this way. It's just changing the value. I think you're mixing up your more intimate knowledge of what a declaration is composed of with what authors actually think of. As an author myself, I can tell you that saying "setProperty('color', 'red')" is me just saying "set the 'color' property to 'red'", not "if the property isn't currently important, set it to 'red'; otherwise, set it to 'red !important'. The fact that importance exists doesn't enter into my mind except in rare circumstances when I'm having cascade issues. I don't think I'm rare in this position. >> > Also, I think having a semantic difference between an omitted value >> > and an empty string value here is a really bad idea and incredibly >> > confusing. >> >> I don't have a problem with default values being different from other >> values. (Given recent WebIDL changes, you can even express it >> directly, by passing undefined, as long as you don't have one of the >> weird undefined-related extended attributes.) > > Just because we can do it doesn't mean authors are going to be able > to remember how the API works or understand code they're reading > that uses it. I don't think authors will really need to use the other argument anyway. More importantly, though, I think it's very natural for omitting an argument to mean "don't do anything special", which is what is happening here. You'd only give the third argument if you're specifically trying to set the importance to a particular value; if you omit it, you're just not thinking about importance at all, and don't want to be bothered by it. ~TJ
Received on Wednesday, 21 August 2013 22:23:28 UTC