RE: CSSStyleDeclaration: Setting only a value or a priority

As the instigator of this discussion, I'd like to make the following comments:

1) Personally, I like the chosen solution, having been bitten several times by the wrong assumption 
that not providing a valid string argument to the priority argument of setProperty would leave the priority alone.

2) I don't see how interpreting "s.setProperty(p, v)" as "s.setProperty(p, v, s.getPropertyPriority(p))" 
instead of as "s.setProperty(p, v, "")" could lead to any complex interpretation issues. Most users and the underlying type system are perfectly able to distinguish between undefined arguments and empty strings. (I would agree that the empty string should be replaced by "normal" or that the whole priority state should be removed, but I would not dare to start a discussion about that at this location).

3) I'd like to inform those new to the thread that I have also proposed to add functions "setPropertyValue(p, v)" and "setPropertyPriority(p, i)". Perhaps that simple, fast and symmetric solution deserves some discussion as well (even if it would completely re-open this discussion). The original purpose was to remove some complexity from JS code, if necessary by moving it into native code. After all, processor time is still expensive, but memory is not.

PJS, Firefox add-on developer.

> From: jackalmage@gmail.com
> Date: Wed, 21 Aug 2013 16:26:04 -0700
> Subject: Re: CSSStyleDeclaration: Setting only a value or a priority
> To: dbaron@dbaron.org
> CC: simonp@opera.com; www-style@w3.org; pjs.nl@live.com
> 
> On Wed, Aug 21, 2013 at 4:09 PM, L. David Baron <dbaron@dbaron.org> wrote:
> > On Wednesday 2013-08-21 15:59 -0700, Tab Atkins Jr. wrote:
> >> This is getting rather tangential, but which drafts?  (We were unaware
> >> of this when drafting Cascade, which treats everything from cascaded
> >> value onward as unordered.)
> >
> > Well, I think they've been removed from all WG drafts, but I think
> > it's what the last copies that were in WG drafts said.
> 
> Okay.  That's something that we should discuss in more detail in another thread.
> 
> >> >> More importantly, though, I think it's very natural for omitting an
> >> >> argument to mean "don't do anything special", which is what is
> >> >> happening here.  You'd only give the third argument if you're
> >> >> specifically trying to set the importance to a particular value; if
> >> >> you omit it, you're just not thinking about importance at all, and
> >> >> don't want to be bothered by it.
> >> >
> >> > I don't think authors "not thinking about importance at all" should
> >> > get random importance as a function of what's already there.
> >>
> >> There's your problem!  The cascade's not really understandable to most
> >> people in the first place, so making them think about when using an
> >> API that *actively hides the important parts of the cascade* (the
> >> ordering aspect) probably isn't a good idea.
> >>
> >> It's not about "[getting] random importance", it's about just changing
> >> the value of a declaration *without touching the importance*.  You
> >> don't care about the importance 99% of the time - you're in JS, the
> >> cascade is unimportant, you're just trying to set a value.
> >
> > That's an argument for making it always set "!important".  But I
> > don't see how it's an argument for preserving existing !important or
> > lack thereof.
> 
> My hope is that it's an argument for "don't mess with data the author
> isn't specifying", and "the OM is an unordered data structure, so
> don't expose ordering details in confusing ways - just paper over them
> instead".
> 
> But more importantly, no, the use-cases actually presented (going
> through the stylesheet and modifying some properties) definitely do
> *not* want !important auto-added.  Once again, they're just trying to
> set a value.  They're *not* trying to set the importance, so dont'
> tweak it.
> 
> ~TJ