New CSS parser for JavaFX

[Michael Strauß]

On Mon, Aug 26, 2024 at 11:14 PM John Hendrikx <john.hendrikx at gmail.com> wrote:
>
> 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 fact that ParsedValue is almost unusable by third-party
applications works to our advantage here, as this is the reason why we
can remove it in the first place.



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

Not beyond what you wrote down here. I think these are quite different
concerns, and don't need to be solved together.



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

Yes, thanks for pointing that out!