-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
**kwargs
keys that start with --
should not be upgraded within css()
or Tag
attributes
#69
Comments
I do not know of a clean solution for the Taking the extreme position... I don't believe A possible work around would be to supply a class for attributes that should be treated "as is". Ex: Possible solution for Almost like a |
For reference, this is how we handled the same (or similar) problem in htmltools: rstudio/htmltools#402 |
I like R htmltools approach. Hate to throw the baby out with the bathwater here, when the common case surely is things like @schloerke are there HTML attributes that have |
I'd be ok with not upgrading keys that start with 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 |
**kwargs
supplied to css()
or as Tag
attributes should not have their key's transformed**kwargs
supplied to css()
or as Tag
attributes that start with --
should have their keys upgraded
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... |
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 |
**kwargs
supplied to css()
or as Tag
attributes that start with --
should have their keys upgraded**kwargs
keys that start with --
should not be upgraded within css()
or Tag
attributes
Thank you both! I believe we have a clear path forward. (... Use non-standard evaluation within python. 😜 ) |
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>
The text was updated successfully, but these errors were encountered: