New CSS parser for JavaFX

[John Hendrikx]

The CSS code, and its API, to put it diplomatically, is IMHO a bit under 
cooked.

I've had quite a few looks at it, and each time I've come to the 
conclusion that it is near impossible to do any worthwhile improvements 
to it without at a minimum getting rid of the ParsedValue abomination.  
This class has generics that are used like 1% of the time, and in all 
other cases is either used raw or just instanceof'd and casted to 
whatever type the code knows will be in there.  It literally pollutes 
the code and makes it plain unreadable, not to mention giving you a 
completely false sense of security -- it's about as useful as just 
passing Objects around (which can be arrays, or even arrays of arrays...).

So I'm already 100% in favor as this proposal will be getting rid of 
ParsedValue.  The converter example looks like a breath of fresh air 
compared to the current code seen in most converters.

The convert method is, as I think was said earlier, more of an 
interpretation method, where raw CSS syntax is converted to objects used 
by the FX properties.  There is also a convert method that takes a Map 
which seems to serve a different purpose altogether (it deals with 
merging already interpreted values into a larger FX type which consists 
of those values).  For this last method, there was also talk to have a 
"convertBack" variant.

Introducing a new method here would have to opportunity to give this a 
less confusing name (so not all three of these variants are called 
"convert").  As far as I can see there are three main functions for a 
StyleConverter:

- Interpret "raw" CSS values to FX types (like Border, Color, String, 
double)
- Take a map of FX types (already interpreted values) and consolidate 
these into an FX type, which I think is used or can be used for 
shorthand properties and is used to merge values into say a Border or 
Background
- The reverse of the above function (for CSS transitions that are 
applied to properties that consist of multiple distinct values).
- There is no reverse of the interpret function (there is no need to 
convert FX types back to CSS, the code that writes CSS files operates at 
a lower level).

Ideally something like:

- interpret/parse/convertCSS for T convert(ComponentValue, Font)
- consolidate/merge for T convert(Map<CssMetadata,Object>)
- split for Map<CssMetadata, Object> split(T)

Did you any thoughts on this as well?

Anyway, I think it is a worthwhile undertaking.  I think the expected 
benefits will be to break out of the current stalemate where it is hard 
if not impossible to add features to the CSS parser, allowing easier 
future extensions (and immediately offers already one of the best 
features, `var()`).  Other benefits could include more shorthand 
property support.  It would probably also allow opening up more of this 
as a programmatic API -- that all starts with a clean design.

--John

PS.

Under Solution 1, I think the data structure should read "<function>rgb 
(<percentage>100 <percentage>50 <percentage>0 )" (rgb instead of gray) ?



On 26/08/2024 05:44, Michael Strauß wrote:
> I've written up a proposal to implement a new CSS parser for JavaFX:
> https://gist.github.com/mstr2/f416996caf48e11193f0b6a5883a3926
>
> The goal is not add new features at this point, but to resolve some
> long-standing issues with the existing CSS parsing (though if you read
> carefully, you might spot a new feature).
>
> I'm interested in your opinion whether this is a good idea to move forward.