[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    RE CSS: inheriting styles in the OO sense (was: Are more font variants in the pipeline?)
From:       tbee () tbee ! org (Tom Eugelink)
Date:       2012-09-21 6:08:14
Message-ID: 505C044E.9070902 () tbee ! org
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]