Hi David,
> Currently, a control has a default style-class. For example, you can use
> .button in a style-sheet to style a Button. I propose to move the default
> style-class from the control to the skin (RT-32186). The impetus for this
> change is two-fold.
>
> Firstly, it can be argued that setting the style-class of a control should be
> left to the developer, that imposing a default style-class is implementation
> detail leaking into the public API. Moving the default style-class from the
> control to the skin addresses this concern.
>
> The second motive has to do with CSS processing itself. When a skin is set on
> a control, the control adopts the styles of the skin and css is reapplied to
> the control in order to pick up the new styles. Thus, it takes two CSS passes
> to fully style a control. By moving the default style-class to the skin, the
> control no longer has to adopt the skin's styles. Styles still have to be
> applied to the skin, but this can be done from the skinProperty's invalidated
> method. These subtle changes - not adopting the styles and applying css to
> the skin from skinProperty's invalidated method - will simplify the code in
> Control.
It seems like removing the built-in style classes would be quite a breaking
change. One pattern used today in order to "turn off" the default styles
(without having to wholly replace the skins) is to clear the styleClass list.
But if the styleClass list is already empty, this pattern won't work and
existing code will break. Another problem is that existing CSS styles just say
.tool-bar { -fx-orientation: vertical; }, and those would no longer work.
Is there another way to accomplish your second motive?
I need more time to work through the rest of this, maybe we can chat offline to
get me up to speed, but my initial concern is that removing the style class
will break people fairly substantially.
Richard
