- From: Zack Weinberg <zackw@panix.com>
- Date: Mon, 30 Sep 2013 19:47:19 -0400
- To: David Baron <dbaron@dbaron.org>, www-style list <www-style@w3.org>
On Thu, Sep 12, 2013 at 12:36 PM, Zack Weinberg <zackw@panix.com> wrote: > On 2013-09-12 3:59 AM, Simon Pieters wrote: >> >> On Wed, 11 Sep 2013 16:38:26 +0200, Zack Weinberg <zackw@panix.com> wrote: >> >>> I object to this resolution >>> >>>> RESOLVED: setProperty's handling of importance logically behaves same >>>> as appending a declaraiton (like IE/WebKit) >>> >>> >>> for the following reasons: >>> >>> 1) At the level of script-author-visible behavior, this resolution >>> means that setProperty establishes a new value and priority for any >>> property, *except* when there was already a value for that property >>> with priority !important. In that case it silently has no effect. >>> This is surprising and inconsistent. > > ... > >> >> This information was already known before the resolution. > > > Yes. It was repeatedly stated as a key issue, by me and others. However, as > far as I can tell, this point was ignored in the actual decision-making > process, which seems to have been mostly about choosing between two internal > algorithms based on perceived elegance and desirable side effects for other > scenarios. I reiterate that no amount of internal elegance excuses > inconsistent behavior in the visible API. > > >>> 2) If we add more priorities in the future, the author-visible >>> inconsistency will become worse. The above table will have to be >>> expanded with new rows and columns for each priority, specifying under >>> what circumstances setProperty will actually do anything. >> >> >> That's true with the alternative proposal as well, no? > > > No. With the alternative proposal (always removeProperty first), there is > only one possible outcome: the value and priority passed to setProperty are > always applied. > > >>> 3) There is an alternative internal semantic that avoids the >>> author-visible inconsistency while preserving the "style rules are >>> ordered lists of declarations" behavior that seems to be dbaron's >>> primary concern. >> >> >> The order is preserved and exposed in the spec and in implementations, >> so I don't understand that concern. > >> >>> >>> That semantic is: setProperty behaves as if it first >>> calls removeProperty, and then proceeds to append a new declaration to >>> the style rule with the specified value and priority. >> >> >> That would mean that the set declarations are always moved to the end, >> which is different to what all implementations do today. > > > Always moving a set declaration to the end is exactly what the spec was just > changed to require! setProperty is now defined in terms of "append a CSS > declaration", which, like the name implies, _appends_ the declaration; that > may or may not cause an old declaration to be superseded, depending on their > relative priorities. (Close reading of the new text suggests that the new > wording may not actually entail this, but - for reasons given below - I > think the _intent_ was always-move-to-end.) > > Further, my understanding of dbaron's issue with "always replace in place" > semantics for setProperty is that it _doesn't_ always move set declarations > to the end. From related discussion with him offline, I am under the > impression that the main thing he cares about is > > selector { > margin-left: 10px; > margin-start: 5px; > } > > being rewritten as > > selector { > margin-start: 5px; > margin-left: 10px; > } > > after `setProperty("margin-left", "10px", "")`, so that order can control > which of these related properties actually applies. > > >>> This is >>> consistent with the current Gecko/Presto behavior, >> >> >> Not quite, as Gecko/Presto don't move the declaration to the end if one >> is already in the list. > > > For Gecko, true but irrelevant, as _at present_ there is no semantic > dependence on the order of declarations; the logical box properties > (specifically, the explosion in the number of logical box properties due to > vertical writing, rendering our current method of disambiguation > impractical) are about to change that. (In the six-months-to-a-year > timeframe, AIUI.) > > >>> and still permits in-place update where browsers can >>> prove it is semantically equivalent. >> >> >> I don't follow. > > > If moving an existing declaration to the end of the property has no effect > on the rendering (== if moving the declaration to the end does not change > whether it is trumped by a related property, as in the case of the > physical/logical box property pairs), then browsers can avoid doing so; it's > a pure optimization. > > >>> For avoidance of doubt, I do not object to setProperty(prop, value) >>> === setProperty(prop, value, "") nor to the addition of >>> setPropertyPriority and setPropertyValue with always-update-in-place >>> semantics. >> >> >> Understood. David Baron objects to setProperty(prop, value, "") >> overriding an !important declaration, as I understand it. > > > This is the crux of the issue. > > 1) I specifically object to setProperty(prop, value, "") > _not_ overriding an !important declaration. All else is negotiable. > > 2) I don't think David's position is actually incompatible with mine. > I don't wish to put words in his mouth, but as I said above, I am > under the impression that what he actually cares about is the > always-move-the-new-declaration-to-the-end side effect. Hence my > alternative proposal of behaving as if removeProperty() were always > called first. > > I think we need to hear directly from David at this point. Two weeks later, we're still waiting to hear directly from David. (I should have cc:ed him on the quoted message, my apologies.) zw
Received on Monday, 30 September 2013 23:47:41 UTC