JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)

[Pedro Duque Vieira]

Richard, John and Tom thanks for your input.


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


That's not what I meant.
What I meant is that you build on the existing knowledge surrounding a
technology that is meant to define the appearance of applications. Of
course, unfortunately you can not build on the implementation.

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).


Yes I would discard layout and inserting dynamic nodes as well. I'm talking
about what already exists in JavaFX CSS and that does not follow the CSS
specification. For instance: margins, effects, the "-fx-" prefix
everywhere, etc..
There are clearly some decisions being made that go against the spec and
not because it would be hard or more work to follow the spec. With others I
can agree that it can be difficult to follow.

> @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.


There is no CSS as language. You can talk about it, but CSS does not define
only a language but also a bunch of properties: font, background and
foreground colors, text properties, margins, etc, etc. Look at any CSS spec
and you will find these.

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


That's not correct. Vendor prefixes are meant to be temporary as they
fragment the web (each browser having there own prefix and implementation
of a property), there have already been prefixes that were dropped.
Taken from the W3C CSS specification 3 (
http://www.w3.org/TR/css3-syntax/#vendor-specific):
"Although proprietary extensions should be avoided in general, there are
situations (experiments, implementations of W3C drafts that have not yet
reached Candidate Recommendation, intra-nets, debugging, etc.) where it is
convenient to add some nonstandard, i.e., proprietary identifiers to a CSS
style sheet. It is often hard to predict how long these proprietary
extensions will be in use and hard to avoid that their names clash with
new, standard properties or with other proprietary properties. Therefore
the CSS Working Group proposes the following simple naming convention. A
proprietary name should have a prefix consisting of..."

In fact, the reason we put in -fx- was *exactly* to allow us to have
> CSS-compliant non-fx- rules later on.


Are you positively sure that your CSS implementation is compliant? I have
serious doubts.

> 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).


This was what I've been told more than once the reason was by Oracle staff.
Again are you sure that this makes JavaFX CSS spec compliant?

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


I would be more interested in JavaFX CSS being W3C compliant than having
CSS animations (you can already do those with java code), for the reasons I
mentioned earlier.

Thanks again, cheers,



Pedro Duque Vieira