RE CSS: inheriting styles in the OO sense (was: Are more font variants in the pipeline?)

Felipe Heidrich felipe.heidrich at oracle.com
Fri Aug 24 10:23:29 PDT 2012


Hi,

There is a CSS pattern I have seen for this problem:

.superclass {
	whatever: blah;
} 

.subclass1.superclass {
	whatever2: meh;
}

.subclass2.superclass {
	whatever2: doh;
}


--->Note: ".child2.superclass2" != ".child2 .superclass2" !=  ".child2, .superclass2" 



Now we have:
node.styleClass = "superclass";  - Works (node gets whatever blah)

node.styleClass = "superclass subclass1"; - Works (node gets whatever blah and whatever2: meh)

node.styleClass = "subclass1" - Node gets nothing, it doesn't matter if node is a descent of parent.styleClass=="superclass" or not.


This trick works (maybe not great but that is what people do). Maybe something better is needed but I think that fight should happen at W3C, adding something -fx-base-class feels wrong IMO.

Felipe



On Aug 23, 2012, at 3:56 PM, Daniel Zwolenski wrote:

> I will raise a jira for this when I get a chance. 
> 
> If it was done as an attribute then it shouldn't violate any standards (ie -fx-base-class). 
> 
> The challenge in my mind would be how to interpret this from a logical sense. The thing is, there aren't actually named 'classes' in CSS. 
> 
> Ie this:
> 
> .my-class {
> }
> 
> Is not declaring a class it's defining a matcher for any node that declares itself as being of class 'my-class'. The actual existence of 'my-class' is implicit by the fact that it is used on a node (yuck).
> 
> In practice, nearly everyone conceptualizes the css above as a class definition and tends to use it this way by creating a set of base 'class styles'. 
> 
> But if we were to have this:
> 
> .my-class {
> }
> 
> .my-section1 .my-class {
> }
> 
> .my-section2 .my-class {
> }
> 
> And then we have 
> 
> .my-special-class {
>  -fx-base-class: my-class
> }
> 
> Which 'my-class' should be used as the base class. Does it matter if the node flagged as 'my-special-class' is inside a node with class my-section1, etc. 
> 
> This sort of selector stuff (and it exists in spades even before we go adding base classes) is where CSS starts to lose its predictability and is my main gripe against it. 
> 
> Basically the base class thing would be my way of avoiding the arbitrariness of CSS selectors as I would be able to use inheritance instead. I'd probably never use a selector path again, avoiding the above problem (except for weird thinks like button pseudo-classes).
> 
> It's the best thing for me but I'm not sure it is the best thing for the platform (hence the 'bad idea?') but I was wondering if other people had thoughts on this and/or ways to allow both patterns to co-exist, or alternative ways to improve the pain of CSS selectors management, modularisation and debugging?
> 
> I'd also be curious to know if I am I the only one who feels something better is needed here? Are most people generally happy with CSS and I'm just making unnecessary fuss, or do others share my pain?
> 
> 
> On 24/08/2012, at 8:17 AM, David Grieve <david.grieve at oracle.com> wrote:
> 
>> I agree wholeheartedly that we don't want to introduce things that are not in the standard.
>> You are correct that this concept is not in CSS nor in CSS Selectors 4 draft. My suggestion was that this concept could be proposed to the working committee for inclusion in the draft. 
>> 
>> On Aug 23, 2012, at 5:49 PM, Pedro Duque Vieira wrote:
>> 
>>> Sorry I forgot to put the subject. Apoligies for sending a duplicate mail.
>>> 
>>> Hi,
>>> 
>>> I don't think the idea is bad but it doesn't exist in the CSS universe. And
>>> if you want to conform to the W3C CSS as is the objective as was mentioned
>>> sometime ago in this mailing list than you don't want to introduce things
>>> that are not present on the standard.
>>> 
>>> I haven't seen any mention on this kind of inheritance on the  CSS
>>> Selectors 4 draft. Have I missed it?
>>> 
>>> Thanks, best regards,
>>> 
>>> 
>>>> Not a bad idea. Certainly the idea has merit and there is a W3C working
>>>> draft on CSS Selectors 4 so maybe this could be proposed.
>>>> 
>>>> For JavaFX purposes, it might be possible to use a functional
>>>> pseudo-element to accomplish this:
>>>> 
>>>> .my-specific-label-style::-fx-
>>>> inherit(.my-base-label-style) { ? }
>>>> 
>>>> The function syntax could allow multiple args for your multiple
>>>> inheritance. Declarations would be copied from the inherited rules in the
>>>> order given in the args (thus, later declarations override earlier ones)
>>>> but coming before the declarations in the child rule.
>>>> 
>>>> As an alternative, it would be fairly straight forward to pre-process a
>>>> file with suitable "extends" syntax and generate a new file with all of the
>>>> "inherited" declarations rolled into the normalized selector that would be
>>>> parseable by standard CSS syntax.
>>>> 
>>>> It never hurts to create a feature request so ideas like these aren't lost.
>>>> 
>>>> On Aug 23, 2012, at 9:19 AM, Daniel Zwolenski wrote:
>>>> 
>>>>> This is maybe a good opening to ask what the thoughts would be on adding
>>>> some stuff beyond web-css, in particular "inheritance" (in the OO sense,
>>>> not the containment sense that CSS already supports).
>>>>> 
>>>>> So if I have a base style like:
>>>>> 
>>>>> .my-base-label-style {
>>>>>     -fx-font: 15px "Open Sans";
>>>>>     -fx-background-color: red;
>>>>> }
>>>>> 
>>>>> Then we have specific instances that then extend this, and override as
>>>> needed:
>>>>> 
>>>>> .my-specific-label-style extends my-base-label-style {
>>>>>     -fx-border: 1px solid green;
>>>>>     -fx-background-color: red;
>>>>> }
>>>>> 
>>>>> (syntax used is for descriptive purposes only, not a suggestion).
>>>>> 
>>>>> So the resulting styles would be the merged set of these two (with the
>>>> base class overriding the parent class styles).
>>>>> 
>>>>> This would mean we could avoid adding both styles in the code, and just
>>>> add the actual specific class (which implies the base class), which means
>>>> styling is kept nicely in the stylesheet. If I want to change my button to
>>>> not use the base class, that's a CSS change, not a code change.
>>>>> 
>>>>> Multiple inheritance would be bonus points (where each 'extends'
>>>> overrides the last).
>>>>> 
>>>>> I don't know the ramifications of doing this and if it is possible in
>>>> the JFX implementation. I just know this type of usage is something I have
>>>> often wanted and wondered about.
>>>>> 
>>>>> If 'extends' style doesn't work, what about an -fx-base-class attribute:
>>>>> 
>>>>> .my-specific-label-style  {
>>>>>     -fx-base-class:  my-base-label-style1, my-base-label-style2;
>>>>>     -fx-border: 1px solid green;
>>>>>     -fx-background-color: red;
>>>>> }
>>>>> 
>>>>> Bad idea?
>>>>> 
>>>>> 
>>>> 
>>> 
>>> -- 
>>> Pedro Duque Vieira
>> 
>> 
>> David Grieve | Principal Member of Technical Staff
>> Mobile: +16033121013 
>> Oracle Java Client UI and Tools
>> Durham, NH 03824 
>> Oracle is committed to developing practices and products that help protect the environment
>> 



More information about the openjfx-dev mailing list