**kwargs keys that start with -- should not be upgraded within css() or Tag attributes

[schloerke]

css()

Currently, css() upgrades all instances of _ to -.

This makes it impossible to create a css variable of --_foo. css(**{"--_foo": "bar"}) will get transformed to ---foo:bar;.

Tag Attributes

Similarly, you can not create an attribute that contains _. Ex: div({"data-foo_bar": "baz"}) returns <div data-foo-bar="baz"></div>

[schloerke]

I do not know of a clean solution for the TagAttrDict to not upgrade some keys while continue to upgrade others as all keys are strings.

Taking the extreme position... I don't believe TagAttrDict should upgrade any attribute keys. If a user wants to provide difficult to define attrs, they can use div({"impossible-attr": "value"}) or div(**{"impossible-attr": "value"}). Unlike R's list(), there isn't a convenient/pretty way in python to supply keys to a dictionary.

A possible work around would be to supply a class for attributes that should be treated "as is". Ex: div(TagAttrsRaw(**{"_impossible-attr_": "value"})) which would give <div _impossible-attr_="value"></div>

---

Possible solution for css() is to add a new method of css_raw() which will not update the keys and only concatenate the values. I believe we could drop collapse_= arg as I haven't used anything other than "".

Almost like a css(upgrade_keys=False)... However, I do not want to add this argument to the css() function.

[gadenbuie]

For reference, this is how we handled the same (or similar) problem in htmltools: rstudio/htmltools#402

[jcheng5]

I like R htmltools approach. Hate to throw the baby out with the bathwater here, when the common case surely is things like css(background_color="#F0F0F0").

@schloerke are there HTML attributes that have _?

[schloerke]

I'd be ok with not upgrading keys that start with --. (R htmltools approach)

I don't know of any legitimate HTML attrs that have a _.

---

I guess I was in a "R is magical" and "python should not perform magic" mood. With python having a way to supply arguments that would not need to be upgraded, I wanted to keep that mindset as much as possible. And adding the R htmltools change seemed like it was adding more confusion as to what is being upgraded when.

I'm ok if we just ignore CSS variables (or keys that start with --).

[jcheng5]

I'm ok if we just ignore CSS variables (or keys that start with --).

That's what makes sense to me. I think we might have different definitions of "magic" in any case... to me this is just convenience, whereas "magic" means the user has no reasonable way to form a mental model for what's happening (like if you introduced NSE to Python, THAT would be magic).

Edit: I don't mean to imply that there are any hard and fast rules about when we should do these kinds of features versus not, or any kind of objective way to decide--feels like a matter of taste on a case-by-case basis...

[gadenbuie]

It's also helpful (and makes things less magical) that the spec for CSS custom properties defines them as a property whose name starts with -- and is following by anything else except a space.

[schloerke]

Thank you both! I believe we have a clear path forward.

(... Use non-standard evaluation within python. 😜 )