> 1. CSS is a standard for styling HTML, and WTKX is a ui markup like HTML.
It is like HTML, but it is not HTML. This is an important distinction. It is also like MXML and XAML, but it isn't those, either. We don't try to emulate features from other toolkits just because developers are comfortable using them. We try to design a solution that works best for BXML. We use standard technologies and draw inspiration from other platforms where appropriate, but we're not going to bend over backwards to support something just because it works well in another context. > 2. CSS is well known and has been around forever. The same can be said for Java, XML, and JSON, all of which Pivot uses heavily. > 3. CSS is powerful. CSS has to be powerful, because trying to build a GUI out of document markup tags necessitates it. Pivot's styling support doesn't need to be quite as robust, because a lot of would otherwise need to be done via CSS is handled internally by the skin classes in Pivot. I can say this with some level of authority because Pivot was originally implemented as an AJAX toolkit using DHTML and JavaScript with CSS for styling. One of the reasons we moved to Java was to get away from the messiness of using CSS for rendering. > 5. CSS+WTKX requires less typing (as in "fingers hitting the keyboard") than > the other proposals I've seen so far. In practice, I suspect that the amount of typing will be roughly the same. A CSSSerializer will allow you to include CSS files in a BXML document, but you'll still need to apply those styles in markup the same as if you had defined them in JSON. > 6. The behavior of CSS styles as applied to HTML is well-defined, and, if > implemented in close analogy, will work the same way as applied to WTKX. Again, BXML is not HTML. So, while CSS applies well to HTML, it does not necessarily map as well to BXML. JSON does - that's why we use it. > That being said, if the Pivot styling API has hooks for plugging in other > implementations (like, say, a CSS approach), I don't see the need for one > implementation to "win" in a debate. There will be a default, but if devs > have a choice, they will choose what they want to use. I would not use the term "pluggable" to describe what I am suggesting. Pluggability implies that the framework will provide some sort of "service provider API" that can be used to hook into styling, which is not the case. You'll simply be able to use the existing features of BXMLSerializer to load style definitions via an alternate means.
