On Mon, 12 Oct 2026 20:40:26 GMT, Marius Hanl <[email protected]> wrote:
>> It should re-add the property at a later run. Usually, it is checked if the >> property is already included or not. >> A property is usually non-settable when it is bound (we will get an >> exception if we try). >> >> So in this case, the style is not interesting for us, as it is anyway bound >> and therefore basically 'forced' to not being overwritable for now. > >> Well, you can `bind` a property... good luck setting it then. >> >> Never quite understood why it was decided that in the CSS system, `set` and >> `bind` aren't the ultimate truth, but can be overridden by the users own >> stylesheet (but not the user agent stylesheet). >> >> I mean `USER` in browser terminology means the browser user (browsers allow >> for stylesheets set directly by the end user, that fit between the browsers >> own default look (`USER_AGENT`) and the website developers look (`AUTHOR`). >> >> However, in JavaFX, `USER` has been conflated with application developer... >> it should have been the end user. > > 100% agree. This behavior is very confusing and feels just wrong. > It confused me so much when writing tests for this (and testing various > scenarios on test apps). > > This is the result, which, I repeat myself feels completely wrong (I even > considered to add this to the tests, because it was such a surprise to me): > > root.applyCss(); > > assertEquals(0.5, node.getOpacity()); > > node.setOpacity(0.8); > assertEquals(0.8, node.getOpacity()); > > // aaanndd its gone. > root.applyCss(); > assertEquals(0.5, node.getOpacity()); the question was around the property being reported as non-settable **temporarily**, which is a rather contrived scenario. objection withdrawn, your honor. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2343#discussion_r4252226676
