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

[Tom Eugelink]

In my PHP projects I often use the trick of having a PHP generated CSS file. Because the CSS file simply is requested as a regular file by the browser, you can do this:

<LINK REL="StyleSheet  HREF="style.css_*.php*_" TYPE="text/css">

PHP of course can generate a css just fine, since only the <? blocks ?> are processed. And that gives me the possibility to construct the CSS as I like; variables, includes, ...

So, it could be a flexible solution to only allow CSS files to be post-processed after they are loaded, by providing a call-hook. The developer can then setup his own stuff; pull the file through FreeMarker, let Rhino run over it, or what ever people come up with.

Tom



On 2012-09-21 07:40, Daniel Zwolenski wrote:
> So there is precedence for this.
>
> Basically what I want is LESS CSS in JFX (http://lesscss.org/) in
> particular mixins (but the other stuff looks nice too).
>
> JIRA here: http://javafx-jira.kenai.com/browse/RT-25126
>
>
> On Sat, Aug 25, 2012 at 3:23 AM, Felipe Heidrich <felipe.heidrich at oracle.com
>> wrote:
>> 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
>>