i need to add come CSS data
attributes to some Perspective elements. would i do this in props
, meta
, or custom
(via the Add Property
button, i presume)? i'm not sure which section renders out the the actual HTML. thx gang!
We don't expose a route to set any HTML attributes aside from the id
attribute, which can be set by adding the domId
property to the meta
category.
well, that sucks. any plans to enable that in the future? this ruins my tooltip fix for dynamic tables. no hero cookie for me today...
Allowing custom data attributes would be very nice.
It's also really scary from our side. While allowing for users to set arbitrary HTML attributes would allow for some really powerful customization, it also would provide routes to overwriting attributes the application (session) is heavily dependent on to function correctly. Additionally, such capabilities would be inherently limited to the top-most component level (wherever you see a data-component
attribute), reducing their usefulness.
true. perhaps allowing a select few, though, would mitigate that? so attrs like data-text
or data-flag
would be supremely useful while still keeping things from going full drunken rodeo. there's a ton of usefullness in those two attrs that would provide solutions for things like the tooltips i was trying to build on dynamic tables. (shameless plug). i do NOT envy the challenges on your end, for sure, but i think a middle-ground should be sought after because you ARE generating HTML/CSS and people with designer backgrounds are going to be chomping at the bit to use as much of that scope as they can. speaking personally, i've run full-tilt into glass walls that completely frustrate concepts i'm trying to develop simply because some bog-standard web techs aren't supported. so while i quietly curse this limitation, i also pray for you poor bastards who get to try and implement this
.
Wouldn't a forced namespace solve this problem? Style classes already have their psc-
prefix, a namespace for custom data could be data-pcd-*
.
And then have power users curse us for forcing a naming prefix on something we should just emit? That is a trap, good sir, and we will not fall into it.
Joking aside, that would be acceptable on our end - but likely a god cause of consternation from devs who do expect us to just emit the attribute as they configure it. I'll bring it up internally, but this is really something that should go through the ideas portal.
I do see your point, that was the whole motivation behind my postcss-perspective-style-class plugin, handling the psc-
prefix is annoying.
Will do.
can't you guys, just, you know, use your telepathy and press that magical computer button that does everything for you?
you can add properties with js injection... but thats a bit overkill for a tooltip i think xd
and opens up a whole lot of other problems.
what exactly are you trying to do for you tooltip?
i am fluent in JS, so that's not outside my acceptable scope of options. unless the setup, maintenance, and the like is lugubrious. then no.
i'm trying to add tooltips to the column headers on a table with dynamically generated content.
lugubrious is the big word of the day...
well its mainly dangerous with...
if this content has any input from users.
there might be an easier way tho, how dynamic does it have to be though?
someonething computed using a script or one of 10 possible tooltips?
oh, no. the headers are fixed. the table contents require user interaction, but the tooltips are for the headers ONLY. the headers are pulled from the dataset headers, but they are always the same value and order.
idk if this will suffice for your usecase, you'll need some lines for each possible header
.psc-tooltipClass:before{
content: "Basic tooltip";
}
body:has(.ia_table__head__header__cell[data-column-id="city"]:hover) .psc-tooltipClass:before{
content: "City";
}
body:has(.ia_table__head__header__cell[data-column-id="country"]:hover) .psc-tooltipClass:before{
content: "country";
}
(note the style class and there has to be a text which will always display, though i guess you can use css to make it invisible)
if thats not enough you'll have to use some markdown js injection
that could actually work, but i'd have to expose the id
attr for the HTML. we have multiple auto-generated tables throughout the project and each has different columns. but if the id
attr works in conjunction with this, then, bingo. solution!
id attribute? instead of the class, or as a means to fill in the content?
Dont think attr() can access content from a different component.
Edit: nah thats not possible, the tooltip is a seperate component not related to the table at all, which is why i had to use :has on the body
what i mean is, your solution is a blanket for all tables. it should be able to be more specific by targeting the id
of the table, no? and i meant CSS attribute, not Java attr()
.
this css will only work by placing the class on the tooltip,
i would work with the classes, since i assume the headers should be quite static and some might be common among other tables
css has attr() too