If you're into CSS, maybe you can help with the re...

# tornadofx

[Ruckus]

If you're into CSS, maybe you can help with the rewrite whenever we get around to it. Or you could spearhead it yourself if you're feeling ambitious.

[nekoinemo]

So... I actually ended up trying to a bit of rewriting.
https://github.com/NekoiNemo/prototype-cssdsl
In my opinion it is a bit more flexible and easier to understand, and a bit more streamlined.
I also borrowed some ideas from JB's Exposed wehn it comes to delegates and setters via [].
Though the actual reason i did it are Context classes (name is wip) that describe exactly what properties, pseudo-classes and children are available for specific class/tag, at compile time

[nekoinemo]

Basically, the point of Context is:
In current implementation all properties are available for every class, which is, while correct from css syntax standpoint, not quite correct logically as something like textOrigin set for Shape would do nothing.
At the same time, those properties follow the same hierarchical structure as JavaFX classes, i.e. any css class that represents element subclassing Labeled will also have all css properties that Labeled has.

[nekoinemo]

Another thing i was concerned about is discoverability, as at this point the only way to understand styling of JFX program is to dive deep into modena.css and (fairly inconsistent and sometimes i think even incorrect) Oracle's JavaFX CSS Reference.
Meanwhile when it comes to JAva side of JavaFX, a lot of small details can be found out from autocompletion suggestions and reading JavaDoc.
And Context is my attempt to bring that same clarity to the CSS side of things.
And as an added "bonus", typed Context may be used in combination with inlined styling of specific element inside the TFX builders to make it more clear which properties are styleable for this element, and which aren't.

[nekoinemo]

Well, that's the first major thing. Second major idea is unification of selection across the DSL. For that i introduced a little abstraction in form of Selectable

[nekoinemo]

It's an abstract wrapper over css elements and their relation with only requirement being that there should be a way to resolve it onto proper form of one or moer css selector.
Because of that it Selectable allows to declare selections of any complexity, linear or branching, converging or diverging at any point, without having to worry about its structure and delegating it to Selectable itself.

[nekoinemo]

Returning momentary to typed Context, the only "weak" part is that currently you can't really use them in complex selections, as Selectable does not retain the Context type and will always end up with GenericContext (base class of all contexts with no specifications of its own) at the end. It could be done, but it seemed like a bit of a daunting task for something that i'm not sure will even get approved for use.

[nekoinemo]

Though, i imagine, doing something like this (taken from modena.css)

.button,
.toggle-button,
.radio-button > .radio,
.check-box > .box,
.menu-button,
.choice-box,
.color-picker.split-button > .color-picker-label,
.combo-box-base,
.combo-box-base:editable > .arrow-button {
    -fx-background-color: -fx-shadow-highlight-color, -fx-outer-border, -fx-inner-border, -fx-body-color;
    -fx-background-insets: 0 0 -1 0, 0, 1, 2;
    -fx-background-radius: 3px, 3px, 2px, 1px;
    -fx-padding: 0.333333em 0.666667em 0.333333em 0.666667em; /* 4 8 4 8 */
    -fx-text-fill: -fx-text-base-color;
    -fx-alignment: CENTER;
    -fx-content-display: LEFT;
}

in a type-safe way with selectors and ending up with a context of a common ancestor ("Labeled") in this case, that already has all legible properties declared for them would be pretty cool...

[Ruckus]

Interesting. I see a few quirks you may need to look out for, but I'll try to dig into it more later when I get time.

[nekoinemo]

Thank you~
Few quirks?