> Also one more advantage I see if JavaFX complies with w3c CSS (on the > things that count) is that CSS is a continuously evolving technology with a > lot of people already working on it and evolving it (for instance, the > broken layout system is being rewritten with things like the box model), if > JavaFX follows along it will benefit from that web of knowledge.
One misconception here is that there is any way for us to follow along for free. There is not an existing CSS engine that we can reuse. They are all heavily tied to their native C/C++ browser implementations and are all based on DOM nodes, not scene graph nodes. When the W3C or WhatWG adds new CSS capabilities, we don't get those for free, regardless of the syntax that we were to use. As for following the standard, we do intend to do that (and always have), at least insofar as it makes sense. But some things in Web CSS just don't make sense in the FX scene graph (layout being an obvious example, but some of the CSS selectors that allow you to insert dynamic nodes into the system don't directly map unless we were to implement it via FXML instead of HTML). > @Tom Schindl: I'm not talking about only the "CSS language", there is no > such thing That is not correct. There is a CSS language (syntax) which is independent of the various specific pseudo-classes or declarations supported by a specific target (node type). You can find grammars on the internet. > One of the problems is that JavaFX adds a "-fx-" prefix to every keyword, > the use of this prefix was meant to distinguish experimental browser new > specific features during their testing, experimentation period. This was > during an experimental phase, and was meant to be dropped as soon as all > browser implementations of that new feature work the same. As a practical matter, it is hard for the browsers to ever drop the extension syntax, they just add in the new standard (dropping the existing syntax breaks untold millions of websites). The same is true for FX, we can't drop the -fx- prefix. And in fact we *added* the -fx- prefix at the last minute before we shipped 2.0 (iirc). We didn't used to have the -fx- prefix for everything. The problem was the the CSS standard was a moving target, and we have to maintain compatibility, so we just put -fx- in front of everything to make sure that we wouldn't be burned (as we already had been once or twice) when the at-the-time unfinished CSS 3 backgrounds and borders specification changed out from under us. In fact, the reason we put in -fx- was *exactly* to allow us to have CSS-compliant non-fx- rules later on. > In JavaFX by contrast, this was added for the purposes of being able to > write in the same stylesheet file both web w3c css and JavaFX css without > the 2 clashing into each other. That isn't really the reason why. It was so that we could be standards compliant. We shipped before the CSS 3 spec was completed, so we needed to use the vender extension prefix to make sure that we could later be spec compliant (to the degree that makes sense). > But all this can be changed, we can have both -fx- prefixed properties and > non -fx- prefixed properties and with this not breaking backwards > compatibility. That's correct, and has always been the plan. But in practice (and as John pointed out) this isn't really that big of a deal -- I'd rather have CSS animations before we dealt with this, to be honest. Cheers Richard
