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

Re: CSSStyleDeclaration: Setting only a value or a priority

From: L. David Baron <dbaron@dbaron.org>
Date: Thu, 22 Aug 2013 16:39:26 -0700
To: Zack Weinberg <zackw@panix.com>
Cc: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>, Peter Sloetjes <pjs.nl@live.com>
Message-ID: <20130822233926.GA20122@crum.dbaron.org>
On Thursday 2013-08-22 17:00 -0400, Zack Weinberg wrote:
> Simon Pieters <simonp@opera.com> wrote:
> > L. David Baron <dbaron@dbaron.org> wrote:
> >> Simon Pieters wrote:
> >>> setProperty with no priority was *not* a no-op in the previous spec.
> >>> Instead, it would set the value and unset important. This is what
> >>> Gecko (and Presto) implements also.
> >>>
> >>> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2472
> >>
> >> OK, I guess it was originally implemented that way but changed in
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=556661 .
> >
> > The reporter of that bug clearly has a different mental model about what
> > setProperty should do.
> 
> Since that was me ...
> 
> David, I think you've let the guts of Gecko's implementation color
> your thinking a little too much.  Specifically, the fact that Gecko
> maintains separate "declaration blocks" for !important and normal
> properties from the same style rule is an artifact of the
> implementation that should *not* IMNSHO be visible to style authors.
> Style authors should be presented a unified view in which any given
> rule has only one value for any given property, which may or may not
> have its !important bit set.

I don't think the mental model is at all related to the storage;
I've had that mental model since before we took that approach for
storage.  And I also dislike that approach for storage and would
prefer to have them stored together.

> As such, setProperty(prop, value, "") should be thought of *not* as
> "appending a new property-value pair to the style rule, which may then
> override an earlier pair" but as "*replacing* the existing value for
> 'prop', if any, otherwise setting it anew". I believe this is the most
> natural mental model.

It's pretty odd once you have margin-left interacting with
margin-start, though, since then (in LTR),
setProperty("margin-left", "...") will override a margin-before in
the same declaration block *unless* there was a pre-existing
margin-left declaration that was before the margin-before
declaration.  That's pretty odd.

> (Relatedly, I think the behavior of
> 
>    p { color: green !important; color; red }
> 
> is surprising and inconsistent with the rest of CSS, and should
> probably be changed so the textually-last property clobbers the
> !important one.)

I think CSS1 and CSS2 are both pretty clear that:
  p { color: green !important; color: red }
is intended to simply be a shorthand for:
  p { color: green !important }
  p { color: red }

http://www.w3.org/TR/CSS1/#grouping
http://www.w3.org/TR/CSS2/syndata.html#declaration

While what you propose is perhaps a consistent model, it's
inconsistent with the stated intent of declaration blocks in CSS.

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

Received on Thursday, 22 August 2013 23:40:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:33 UTC