JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
John Smith
John_Smith at symantec.com
Wed Aug 7 16:08:29 PDT 2013
> 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
-----Original Message-----
From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl
Sent: Wednesday, August 07, 2013 2:01 PM
To: openjfx-dev at openjdk.java.net
Subject: Re: Proposal to move default style-class from Control to SkinBase
Oh and one more thing: IIRC you can run e.g. less in rhino so feeding it a less file with -fx properties should get you css file which you can pass on to FX.
Tom
On 07.08.13 22:56, Tom Schindl wrote:
> If I get your complain right what you want has nothing to do with CSS
> but you are requesting that the complete FX API is remodeled, CSS is
> simply a way to set properties of your Nodes in the SceneGraph, in a
> none intrusive way.
>
> You need to differiate between CSS as a language and the properties
> one can set on DOM/SceneGraph-Nodes.
>
>>From the selector point (language) of view FX-CSS support all
>>important
> selector types, but because the nodes in the DOM (=SceneGraph in FX)
> are different you have other properties.
>
> 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.
>
> Tom
>
> On 07.08.13 22:41, Pedro Duque Vieira wrote:
>> Hi David,
>>
>> I'm not going to directly answer your question but I'm rather gonna
>> touch on a problem I see regarding JavaFX CSS. Forgive me for not
>> directly sticking to the subject of your email.
>>
>> The issue I see is that JavaFX CSS significantly differs from W3C
>> CSS, that is the CSS that is used on the web.
>> I've already touch this subject before but didn't have much answer
>> from this mailing list. The reason why I bring it back again is that
>> the more I do web development the more this seems unappropriated.
>>
>> Having JavaFX CSS differ from W3C CSS has the following disadvantages:
>>
>> - Designers coming from web development (they are the majority) will
>> struggle with JavaFX CSS
>> - Cannot use CSS pre-processors like SASS, LESS, Compass thus missing
>> out on this tooling that significantly enhances CSS. You can do really cool
>> stuff with Compass.
>> - Cannot reuse what already is out there on the web. And there are a
>> huge amount of examples there.
>> - Re-inventing the wheel. My personal opinion is that you should try to
>> harness the work that already exists especially when you have few
>> resources. People have already spent some time on this, tested and fixed
>> issues with it. So why not "stand on the shoulder of giants".
>>
>> I'm not saying you should introduce CSS layout, that is a headache
>> and a problem that they're trying to solve in CSS3, but all the rest
>> can be changed to be the same as CSS. You can even have both working
>> side by side, the current JavaFX CSS and a newer more W3C conforming
>> CSS so that you don't break existing apps.
>>
>> I don't see any advantage of having a CSS different from W3C one, if
>> I was going to make one different I would have created a newer more
>> simpler language to express an apps appearance. Not used CSS.
>>
>> Thanks, best regards,
>>
>>
>>
>
More information about the openjfx-dev
mailing list