Re: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
Hi Pedro, on CSS as a spec: You are right the spec does not only hold a language definition but also the definition of e.g. the box-model, ... who simply can not be applied to FX unless you completely revamp how it works on CSS: The grammer of the CSS-Language is at http://www.w3.org/TR/CSS2/grammar.html with a descrption at http://www.w3.org/TR/CSS2/syndata.html with updates in later specs and CSS can not only be applied to HTML-Doms but e.g. also to SVG where you have completely different attributes. See www.w3.org/TR/2011/REC-SVG11-20110816/styling.html how few properties SVG and HTML-CSS share! So to me it looks like the authors of SVG see CSS in the same way the JavaFX-Team does it as a styleing DSL leaving out things like the Box-Model, ... on SASS: I see no reason it can not be used. Like I said SASS is simply syntatic sugar above the CSS Language, but it does not really care about how the properties are named! I've attached you a sample of scss file derived from the projects website using JavaFX properties and to me the output looks correct, maybe there are advanced features I'm not aware of - I haven't used SASS at all on Compass: This one does not work with FX because it somehow deals with the properties on reusing CSS-HTML-Properties: I think the confusion would be getting worse if we'd start mixing HTML-CSS-Property names with -fx ones (which we need in any case) - even if we can get them 100% HTML-CSS compliant. I don't see me blindly copying a HTML-CSS which assumes the Box-Model, element-types who are not existing in FX at all Tom On 08.08.13 02:58, Pedro Duque Vieira wrote: Go to the CSS W3C website and read the spec, you'll see that it's not only a language. No SASS can't be used with JavaFX unless you make a SASS of your own that works like the original but with JavaFX CSS files. Thanks, regards, On Thu, Aug 8, 2013 at 1:38 AM, Tom Schindl tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote: SASS can be used as well in fx, it is simply a preprocessor, like LESS, and for CSS the language and selectors there is a grammer! CSS is simply a DSL and its most important part are the selectors and its cascading nature. Tom Von meinem iPhone gesendet Am 08.08.2013 um 02:11 schrieb Pedro Duque Vieira pedro.duquevie...@gmail.com mailto:pedro.duquevie...@gmail.com: I might have jumped the gun when talking about LESS, I'm not actually familiar with it and thought it would be along the same lines like SASS. But still you can't use SASS or Compass with JavaFX CSS. Cheers, On Thu, Aug 8, 2013 at 1:05 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com mailto:pedro.duquevie...@gmail.com wrote: 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 QA 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
Re: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
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
JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
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 QA 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=WebKitcomponent=CSSresolution=---. 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-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tom Schindl Sent: Wednesday,
Re: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
I couldn't resist - http://tomsondev.bestsolution.at/2013/08/07/using-less-in-javafx/ Tom On 08.08.13 01:08, John Smith wrote: 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 QA 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=WebKitcomponent=CSSresolution=---. 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
