Sliderpack CSS
-
Hello to all,
I have styled my sliderpack based on Christoph's example using CSS. Everything works great. That is the current status:
I just can't get rid of the value being displayed. Does anyone have any idea what I need to add or change?
No text overlay should be displayed.
This is my code so far:
arpSliderPackLAF.setInlineStyleSheet(" .scriptsliderpack { background-color: rgb(73,73,73); border-radius: 3px; } /** Style the individual sliders. */ .packslider { margin: 0.5px; background-color: rgba(0, 0, 0, 0.1); } /** The ::before element will be used to display the value rectangle. */ .packslider::before { content: ''; background-color: var(--itemColour); /** We'll use the CSS variable with the normalised slider value to calculate the height of the value rectangle. */ height: calc(100% * var(--value)); width: 100%; border-radius: 0px; /** This sticks it to the bottom so that the slider behaves like a normal vertical slider. */ bottom: 0%; } /** Now add some state customizations using a transition for smooth hover effects. */ .packslider::before:hover { background-color: color-mix(in srgb, var(--itemColour) 50%, white); transition: background-color 0.2s; } .packslider::before:active { background-color: color-mix(in srgb, var(--itemColour) 80%, white); } /** Style the text overlay. label { color: rgb(163,160,160); background-color: rgb(73,73,73); margin: 3px; padding: 2px; text-align: right; vertical-align: top; border-radius: 3px; box-shadow: 0px 0px 4px black; } */ /** Style the right click line. */ .sliderpackline { background-image: var(--linePath); border: 2px solid white; box-shadow: 0px 0px 5px black; border-radius: 50%; } ");
Thank you
Oli -
I can't figure it out either, it's some weird combination of selectors but I can't pin it down.
And I don't understand what the CSS debugger is trying to tell me. What do I do with this?
-
@d-healey
Good to know that not even you can do it! :-)My workaround now would be to style the pack “normally” using the conventional LAF. But I think that would be a shame, as everything else is actually in place.
@Christoph-Hart can you help us here?
-
@Oli-Ullmann what if you set the label to
display: none
, or at leastcolor: transparent
?
I haven't tinkered with the css laf yet. -
@Matt_SF
Thanks for the idea. However, the label refers to the floating text overlay (see image).However, I would like to remove the dark text over the sliders.
-
I had a similar issue when styling a knob with CSS.
Not all the elements of the control are targetable with CSS selectors.
These replies might be relevant:
https://forum.hise.audio/post/87527
https://forum.hise.audio/post/87536
https://forum.hise.audio/post/87541Sounds like CSS will take us some of the way to simple customization but not all the way.
Coming from a web dev background I can imagine CSS being used extensively in the HISE UI system but it doesn't sound like that's the plan.
-
try
content: '';
(that‘s two single ticks not a quote). -
@Christoph-Hart
Thank you for your answer. I have tried it everywhere:.scriptsliderpack
.packslider
.packslider::before
.packslider::before:hover
.packslider::before:active
labelUnfortunately, the text is still visible. Any other ideas?
-
@Oli-Ullmann Oops, sorry, the correct value is not an empty string, but a space (an empty string is treated as no entry so it will render the default text - so in order to overwrite it you have to give it a non-empty string without characters:
.packslider { background: blue; content: ' '; }
You'll need the empty string to make the
::before
/::after
elements visible, that's what I'm doing most of the time. -
Sounds like CSS will take us some of the way to simple customization but not all the way.
Oh and I was referring to the task of styling a knob where the CSS system hits its limitations (because there is too much to customize). The slider pack is fully customizable with CSS.
-
@Christoph-Hart said in Sliderpack CSS:
Sounds like CSS will take us some of the way to simple customization but not all the way.
Oh and I was referring to the task of styling a knob where the CSS system hits its limitations (because there is too much to customize). The slider pack is fully customizable with CSS.
Good to know
Are knobs the only UI element that isn't fully CSS'd up? Or are there others?
-
@dannytaurus I would say the knob is the most out there because you easily hit the limitation of the two pseudo elements (most of the other complex UI elements can be addressed through multiple selectors, eg. the table has these selectors:
.scripttable {} .tablepoint {} .label {} .playhead {}
so you're not likely to run out of elements.
-
@Christoph-Hart
Yes, that worked! Thank you very much! :-) -
@Christoph-Hart said in Sliderpack CSS:
@dannytaurus I would say the knob is the most out there because you easily hit the limitation of the two pseudo elements (most of the other complex UI elements can be addressed through multiple selectors, eg. the table has these selectors:
.scripttable {} .tablepoint {} .label {} .playhead {}
so you're not likely to run out of elements.
I think I'm just misunderstanding how CSS is implemented in HISE.
If a table can have all those custom selectors, why can't a slider have custom selectors for all of its elements too?
I appreciate you wanting to do as much as possible with native selectors like div, label, etc, and the pseudo-elements
::before
and::after
, but I don't understand why you can add.tablepoint
and.playhead
to a table but you can't add a.valuetext
or similar to a knob. -
@dannytaurus because this would make it the only UI element which then has a separate selector for its text, so it's not consistent with the rest. Also this is a black hole of feature requests: what if you want an additional selector for the value ring? No problem, let's add a
.knob-value-ring
class selector. Now the next guy comes along and wants to display the modulation value with another ring, so.knob-mod-ring
needs to be added. Would be great to have another text label to statically show the name. No problem, slap a.knob-static-text-label
class on it...You see all this can already be done with a few lines of HiseScript code and it doesn't require any specialised CSS selectors that I have to prethink for you and add in the hope that you're use case does not deviate from my intentions in the slightest way, or you're back at square one where you ask me to add Just One More Class Selector.
All the other elements have a predefined amount of sub elements which can be addressed pretty easily and cover 99% of the usage, but with the knob (and not the slider, I really mean knob), the options are basically endless - plus you have to script the mouse logic & path creation anyways so from there to writing the paint routine in HiseScript too is not a big leap.
-
@Christoph-Hart Feel free is skip over the rest of this reply since I don't think I'll ever come to terms with this
However, that's exactly my fundamental disconnect with this - I don't get why all other elements have "a predefined amount of sub elements" while the knob doesn't?
The stock HISE knob has a predefined amount of sub elements, and two of those elements are the name and the value. So why can't we address all those stock elements with CSS?
I totally get the 'one more lane' reasoning and that's why I'm only talking about the stock decisions you've already made with the knob control.
Let us style what's already there in the stock control with CSS, anything else we have to go full LAF.