Sliderpack CSS

[d.healey]

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?

[Oli Ullmann]

@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?

[Matt_SF]

@Oli-Ullmann what if you set the label to display: none, or at least color: transparent ?
I haven't tinkered with the css laf yet.

[Oli Ullmann]

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

[dannytaurus]

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/87541

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

[Christoph Hart]

try content: ''; (that‘s two single ticks not a quote).

[Oli Ullmann]

@Christoph-Hart
Thank you for your answer. I have tried it everywhere:

.scriptsliderpack
.packslider
.packslider::before
.packslider::before:hover
.packslider::before:active
label

Unfortunately, the text is still visible. Any other ideas?

[Christoph Hart]

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

[Christoph Hart]

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.

[dannytaurus]

@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?

[Christoph Hart]

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

[Oli Ullmann]

@Christoph-Hart
Yes, that worked! Thank you very much! :-)

[dannytaurus]

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

[Christoph Hart]

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

[dannytaurus]

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