Re: CSSStyleDeclaration: Setting only a value or a priority

Mike Sherov
Chief Technologist
SNAP Interactive, Inc. | Ticker: STVI
http://snap-interactive.com | http://ayi.com

On Aug 21, 2013, at 11:12 PM, Peter Sloetjes <pjs.nl@live.com> wrote:

 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.


+1. Removing importance by not providing it was unexpected and seemed
counterintuitive to me as a first time reader of that part of the spec.


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).


+1. Undefined vs. empty string is well understood in JS. As a library
maintainer myself, I can say users of jQuery are not bitten by any
perceived confusion here. On the contrary, an argument can be made that
part of the perceived ease of use of jQuery comes from understanding that
$.css(property) is a getter, and that $.css(property, "") is a setter.

The only confusing bit would if there was a distinction between explicitly
passing undefined vs providing no argument (because it would change the
behavior of a function if incorrectly duckpunched or delegated to). In
jQuery's case, its a bit confusing that $.css(property, undefined) is a
noop setter.


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.


+1, there is something to be said for API symmetry. Sure, it increases
surface, but it also avoids this whole discussion of author intent by
expressing the intent in the name.


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