Hiding options in select (drop down list)

[nimble0]

With HTML/CSS it's possible to hide options with a display: none rule.

In RmlUi, display: block is set directly on the option element, so no display rules work:

RmlUi/Source/Core/Elements/WidgetDropDown.cpp

Line 455 in 8f11e0f

element->SetProperty(PropertyId::Display, Property(Style::Display::Block));

[mikke89]

Yeah, would be a nice little convenience enhancement. I think it works already to set the display style directly after the option has been added. However, toggling visibility using a class, or with an initial style, won't work right now because of the display property being set internally on the element.

Not sure how best to solve this though. We want block display by default, because that's the natural layout of the options. We could ask users to add it to their default style sheet, but that would be a breaking change. And not commonly done for built-in elements.

A design question is how to handle indices when there are hidden elements, tree index or display index? I see we already handle visibility in terms of navigation, so that part should be good.

[nimble0]

I think adding an internal base stylesheet is the best option. I agree a breaking change that requires everyone to add a rule is a bad idea.

A design question is how to handle indices when there are hidden elements, tree index or display index? I see we already handle visibility in terms of navigation, so that part should be good.

RmlUi's behaviour seems to be consistent with Javascript (doesn't change selection index when elements are hidden), so I see no reason to change anything there.

[mikke89]

Thanks for checking against the behavior in Javascript.

An internal stylesheet would be a significant change, and would require a larger discussion around what should be included there. I also quite like the idea of a blank sleet to style everything to your liking, without being surprised about built-in styles. But it would be nice sometimes like here to have some overridable (weak) styles for the built-in elements. I'll keep it in the back of my mind for now.

For now, it's possible to remove and add items, so I don't think it's a blocker for any particular behavior. Data bindings could also help to do this dynamically.

[jamarr81]

Every browser has its own "default" stylesheet, aka "User-Agent Stylesheet". Many web-projects utilize assets like css-reset or normalize.css to enforce a cross-browser compliant baseline.

It would seem sensible for RmlUI to also have its own default/baseline stylesheet. Not only for the selection/option styling, but another good use-case would be the documented table-styling. I'm sure there are other preferable use cases as well. Having reasonable defaults and having this baseline styling baked into the library helps to reduce the learning curve and improve adoption rates.

It's difficult to imagine, but if there are conceivable use-cases for which the baseline stylesheet should be disabled (instead of overridden), surely the baseline stylesheet could be removed from their project or disabled at the RmlUI-engine layer?