Re: CSSStyleDeclaration: Setting only a value or a priority

On Wednesday 2013-08-21 15:22 -0700, Tab Atkins Jr. wrote:
> 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.

The approach of treating them as shorthands doesn't really scale to
vertical; it explodes into too many properties.

The alternative is to preserve order, which is the approach current
drafts take.

> >> 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.

Agreed that use of !important is rare overall.

But I think the main use case for this API is "set this property on
this element/rule".  The intent is to make a specific assignment.
This assignment, due to the cascade, doesn't work all of the time,
but use of !important makes it work a little more often.

It seems really odd for that assignment to take place at totally
different levels of the cascade depending on whether *that rule*
happens to have a !important declaration of that property already.

> I don't think authors will really need to use the other argument anyway.

Right, which is why I think it makes more sense for omission of that
argument to behave the same way the empty string does today, since I
think that's the simple and understandable behavior (in so far as
the cascade is understandable).

> 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.

I don't think authors "not thinking about importance at all" should
get random importance as a function of what's already there.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)