RE CSS: inheriting styles in the OO sense (was: Are more font variants in the pipeline?)
Daniel Zwolenski
zonski at gmail.com
Thu Sep 20 22:40:45 PDT 2012
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
> >>
>
>
More information about the openjfx-dev
mailing list