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

[Pedro Duque Vieira]

>
> > So if you invent the same node-types you have on the web (lets face it
> there's only a handful of them most important are most likely div,span) and
> give them the same properties you know from the web you can copy your
> Web-CSS stylesheet to your FX-Application.
> +1 to this idea (in a 3rd party lib).
> > The issue I see is that JavaFX CSS significantly differs from W3C CSS
> It surprises me that this issue comes up so rarely in JavaFX forums
> (almost never) - perhaps it is because JavaFX developers tend to be Java
> developers rather than designers.
> A related open jira request is http://javafx-jira.kenai.com/browse/RT-9272 "need
> to reconcile JavaFX CSS with W3C CSS3" 0 votes (no interest at all?).
> In terms of conversion of existing html css resources to javafx css, you
> may be interested in a Q&A with a developer who converted the Foundation
> look and feel to JavaFX (https://forums.oracle.com/thread/2490009) - from
> his point of view the conversion process was quite straight-forward -
> though perhaps that was partially luck of the draw.
> Below is a copy and paste from an earlier JavaFX forum post on this topic:
> You know, sometimes I find JavaFX's lack of certain css features
> refreshing. It is nice to have all, well, almost all, of the JavaFX CSS
> documented on one page. I think if you were to do the same thing for w3c
> css then it would end up with a much larger, more difficult to understand
> document and even what the contents of that document should be would
> probably be pretty controversial, in the same kind of way that the HTML5
> specification ended up being. Microsoft contributed over 7000 tests to w3c
> just to cover only a subset of the css rules available in browsers today.
> The webkit project lists almost a thousand open CSS bugs:
> https://bugs.webkit.org/buglist.cgi?product=WebKit&component=CSS&resolution=---.
> So implementing even partial w3c CSS support is a complex project.
> When I first started using JavaFX CSS I found the differences to w3c CSS
> quite jarring, and it was hard to account for them. Now that I am used to
> JavaFX CSS, I don't have as much of an issue. The difference in names and
> semantics is going to be an impediment to designers working on JavaFX who
> are familar with w3c CSS - but the designers will quickly also discover
> that FXML is not HTML and Java is not JavaScript and JavaFX deployment is
> not HTML deployment. So, perhaps, in the larger picture, it is not as big a
> deal as it would seem. Still, one can't help think that any impediment to
> people easily picking up and adopting JavaFX is doing the technology a
> disservice.
> There are other advantages in having the JavaFX CSS in its own namespace
> to w3c css, in that it can evolve seperately, it is not expected to be
> exactly the same because it has a different name, it is not expected to
> fully implement w3c css as browsers do because it's clearly a different
> thing by name, etc. There is even precedent for it in the use by mozilla of
> moz- CSS prefixes and webkit css properties
> http://css-infos.net/properties/webkit - the web as not as standard as a
> lot of people propose. JavaFX CSS is backing a JavaFX rendering engine and
> not an HTML rendering engine. It is quite remarkable that Oracle was able
> to build and make available a CSS model for JavaFX that feels as familiar
> as it does to w3c css, as w3c css is targeted very strongly toward styling
> a completely different technology set (HTML markup and document object
> model).
> It would be useful to have a tool which translates w3c css to
> approximations of JavaFX css and vice versa, or the ability for JavaFX to
> have a mode (perhaps a boolean value when a stylesheet is loaded) to
> perform an automatic alias or mapping of w3c css to javafx (at least for
> the subset of w3c css which would make sense to automatically translate to
> JavaFX css).   (David commented on this part previously - "Closing the gap
> between JavaFX CSS and W3C CSS will be an evolutionary process. It would be
> nice to use a standard's based stylesheet but there is not always a 1-1
> mapping to JavaFX. But for those properties that can be mapped, it is
> something that should be supported. For example, we should be able to
> handle "font" or "-fx-font".")
> Comments above relate to the naming and semantic meanings of css tags, and
> not the syntax and parsing of css (as both w3c css and javaFX css seem to
> be equivalent in the later regard).
> The JavaFX css model is really powerful and I have found really useful
> some of the additions that it adds above the baseline 2.1 css that is found
> consistently in browsers. With the upcoming Java CSS object model
> http://javafx-jira.kenai.com/browse/RT-17293 "CSS Style Object Model in
> Java" 23 votes, you will also get better programmatic access from Java,
> which seems to be a highly requested feature.
> Regards,
> John


Hi John,

Thanks for your input. That's exactly my view on things.

I'm also surprised so few people ever talk about this, not wanting to hurt
anybody's feelings, I guess the vast majority probably don't do web
development or are not really acquainted with CSS and its intricacies, but
that's just a guess.

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.

@Tom Schindl: I'm not talking about only the "CSS language", there is no
such thing (I guess its also a bit controversial to call "JavaFX CSS",
"CSS" at all). W3C CSS is much more than a "language", what good would CSS
be if you hand't got keywords, like "font", "color", "margin", etc.
You also don't have to invent all the nodes "div", etc, to rip the benefits
of having a more compliant W3C CSS. These can come later.

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.
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. But I don't agree with this, and I think
it's such a minor use case that the disadvantages clearly outweigh the
advantages. For this use case why not have 2 separate stylesheets, what's
the issue of separating things into 2 distinct files and also I think that
it's much simpler to read and maintain 2 different stylesheets that cram
everything into 1.
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.

Thanks, regards,

-- 
Pedro Duque Vieira