- 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