>> True, and those features are essential when you are trying to construct a >> complex GUI using HTML, because HTML isn't really a GUI toolkit. However, >> Pivot is a GUI toolkit, so you don't need to build so much by hand. > > Hmmm... can't say I follow your argument against selectors here---especially > about the "you don't need to build so much by hand."
I just mean that CSS is your only option for "rendering" in HTML, so it has to be super-sophisticated in order to support all of the things that developers try to do with it. The same isn't true for Pivot (or Swing), since we use Java2D for rendering. > I like being able to specify default style values by Java class name. For > example, if you look at BoxPaneSkin you can see that the spacing is set to 4 > by default. Not everyone will like that. Is there a simple way to change > default style values? There isn't, but I can certainly see an argument for adding support for this. Not entirely sure what the best approach would be, but it doesn't necessarily have to be "the CSS way". It could potentially be done "the Java way", by setting a static value that all BoxPaneSkin instances will use instead of the hard-coded default. > Incidentally, given that these properties are part of the CSS spec and the > CSS spec doesn't change very often I don't see a big maintenance headache in > supporting the font-size and font-weight properties. Yes, but I was actually trying to point out the opposite problem. CSS may be a "standard", but a Pivot skin's style properties (by design) are not. So you would have to stay on top of any changes that the skin developers decide to make. In fairness, a style such as "font" isn't likely to change all that often - I'm just pointing out a potential weakness in the design. I think you probably have some valid use cases you would like to address. However, this feels like a "cart before the horse" situation. CSS may be a great way to meet your requirements in HTML, but maybe not the best way to do it in Pivot. I would like to understand more specifically what you are trying to do (and why), rather than what you think the solution should be. That way, it will be much easier to evaluate the various approaches and determine which might work best.
