- 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