Re: CSSStyleDeclaration: Setting only a value or a priority

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.

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

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

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