I did not know that about CSS styling! Very nice. I implemented it using the
WPF-style. I'll check out CSS.

I like the idea of being able to select on more than just class and id. In
the code I have, I am able to set styles based on general property states
(states are expressed as property-value pairs in JSON) and that sets colors,
backgrounds, icons (or anything else based on triggers which are also JSON
expressions). I did add a "selector" pluggable framework so you can change
which style applies when. This allows you to reduce UI logic in your classes
or make the rules externally pluggable.

You could probably add the selectors in easily and still use JSON syntax for
styles--staying very close to JSON-for-styles.  I stuck with JSON as well,
and hence did not stray from style specification but just on "selector
specification". I found that real trick is how do you specify the selector
and where does it go in the BXML or your json file--it does not require much
syntax to do it. I used 2-3 different approaches before just punting and
doing a simple version of WPF triggers and "styles" and keeping it all
BXML-focused. I think you could do the same but CSS-like and still stay true
to BXML/pivot and keep selector specification simple.

With the wpf-like infrastructure, I can style any component in the
application by specifying styles at the top of the parent-child tree and let
parent-child tree also help guide style selection. But I did not think that
was all that useful unless I really wanted to wholesale change the default
styles everywhere.  I really just like the styles cascading through the
parent-child tree on specific forms/panes and their child contents. I also
found I needed "local" style inheritance for implementing ComponentTemplates
which is about specifying renderer visuals in pure BXML.

Good luck!



-----Original Message-----
From: Michael Allman [mailto:[email protected]] 
Sent: Wednesday, July 14, 2010 12:23 AM
To: [email protected]
Subject: Re: Named styles

What I'm seeing here is that this approach appears to support styling 
specified through element attributes only, i.e. styling of the form

<Duh styles="dsfsdf"/>

One of the nice things about CSS is its support for other kinds of 
selectors like type selectors, class selectors, id selectors, descendant 
selectors, etc.  Then there's inheritence and cascading, which I haven't 
touched yet.  It seems like defining the syntax and behavior for these 
kinds of features within the current or proposed JSON-oriented syntax 
would simultaneously stray from the simplicity of JSON while creating more 
proprietary syntax.

I don't see an impedance mismatch between CSS and WTKX (or BXML as it is 
in pivot 2).  There are some bridges to build because each has defined 
some similar concepts in sightly different ways.  I wrote code to support 
CSS's approach to font and padding specifications, but that's just a 
matter of syntax---the underlying models are the same.  My experience from 
using what I've built thus far is that a CSS syntax works quite well.  I 
will continue to update the list as my experience grows and as I implement 
new features.

Cheers,

Michael

On Sat, 10 Jul 2010, Greg Brown wrote:

>> With all the thoughts going on around styling (people have implemented
CSS-like styling and WPF-like styling/triggers), what is the pivot core
team's thoughts on 2.0 and what the objectives are?
>
> My primary objectives for improving styling support in Pivot 2.0 included
making it easier to apply externally defined styles and possibly supporting
dynamic, automatic updates to those styles. Both of these objectives have
now been met. In addition to the previous means for applying styles:
>
>  Programmatically:
>  myComponent.getStyles().put("color", "#ffffff");
>
>  Declaratively via attribute value:
>  <Label styles="{color:'#ffffff'}"/>
>
>  Declaratively via external file:
>  <Label styles="@label_styles.json"/>
>
>  Declaratively via XML element:
>  <Label>
>    <styles color="#ffffff"/>
>  </Label>
>
> Pivot 2.0 now includes support for defining styles using an external
JSON-based stylesheet:
>
>  <bxml:include bxml:id="myStyles" src="my_styles.json"/>
>  <Label styles="$myStyles.labelStyles"/>
>
> It would also be possible define external styles using CSS syntax, if
someone is interested in writing a parser for it:
>
>  <bxml:include bxml:id="myStyles" src="my_styles.css"/>
>
> As I mentioned earlier, this would basically amount to reading the CSS
data into the same data structure that is output by the JSON serializer.
>
> Additionally, using namespace binding, dynamic style changes can now be
automatically applied:
>
>  <Label>
>    <styles color="${myStyles.labelStyles.color}"/>
>  </Label>
>
> Whenever the "myStyles.labelStyles.color" value changes, the label's color
will automatically change to reflect the new value (as will any other styles
or properties bound to that value). This is demonstrated by the following
example (selecting a value from the color picker automatically updates the
associated label's text as well as its "color" style):
>
>  http://ixnay.biz/pivot-demos/namespace-binding.html
>
> The work Michael has been doing is interesting, though I still think there
is an "impedance mismatch" between the actual CSS specification and how
styles work in Pivot. I would personally rather see some effort focused on
writing a CSS serializer that works within the existing styling framework,
as described above.
>
>> We've seen that we can implement advanced styling approaches (and more)
without changing core pivot at all, but what does this add up to? It seems
that alot of this work is really about easier theming and L&F customization.
>
> Yup, that is exactly what it is about. It simply aims to make it a bit
easier for designers to apply their own L&F customizations to a Pivot app.
>
>

Reply via email to