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

Re: CSSStyleDeclaration: Setting only a value or a priority

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 21 Aug 2013 14:58:23 -0700
Message-ID: <CAAWBYDDRFexO2rWaXac1RHorhHgpuZdTkGien_3t8NGRpWwW3A@mail.gmail.com>
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 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.

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.

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

~TJ
Received on Wednesday, 21 August 2013 21:59:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 August 2013 21:59:15 UTC