- From: Zack Weinberg <zackw@panix.com>
- Date: Mon, 30 Sep 2013 20:42:25 -0400
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: www-style list <www-style@w3.org>
On Mon, Sep 30, 2013 at 8:05 PM, L. David Baron <dbaron@dbaron.org> wrote: > On Thursday 2013-09-12 12:36 -0400, Zack Weinberg wrote: >> >Understood. David Baron objects to setProperty(prop, value, "") >> >overriding an !important declaration, as I understand it. > > It's not the strongest objection I had in the discussion, but I do > indeed object. This is unfortunate; it means we have a genuine impasse. I feel strongly enough that setProperty(p,v,"") MUST replace a prior !important declaration that I will apply W3C process to block the spec from advancing as-is, if I have to. > (1) I think we should stick to the behavior we had interop on and > could easily get interop on again if Gecko changes back. I think this rationale is trumped by the code presented elsethread by Remy, demonstrating that there is code in the wild expecting the current Gecko behavior (whereas no one has presented code expecting the Webkit behavior). > (2) I think the behavior is most consistent with how the CSS > cascade works. ... and I think *this* rationale is trumped by the *inconsistent* API-level semantics it presents (see my original message in this thread for detailed explanation of this point). If you want me to change my position, you're going to have to convince me that the API-level inconsistency is acceptable, and that's going to be a really hard sell in view of Remy's demonstration that authors expect the current Gecko behavior. >> 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. > > No, I think the ordering side effects (or not) are going to be > horrible and probably non-interoperable anyway. (I think Gecko has > optimizations that change the ordering side effect as a result of > whether we can take the optimized codepath.) Yeah, I think we do right now, but weren't you just telling me (re bug 553456) we needed to change that in order to make the logical/physical box properties tractable in the presence of vertical text support? zw
Received on Tuesday, 1 October 2013 00:42:48 UTC