You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2010/06/30 15:01:02 UTC
Named styles
Hi all,
I have recently been giving some thought to how we might support a form of style propagation. This has come up a few times and is clearly a feature that developers would like the platform to provide.
By design, Pivot does not currently support style inheritance. We decided up front that there is not enough commonality between component and container styles for such an inheritance mechanism to make sense. What does make sense, however, is the concept of "named styles". These are similar in concept to CSS classes - they would allow a caller to specify a set of styles by name that should be applied to a component. For example, all Labels associated with the "boldLabel" named style would be bold.
Pivot currently supports a rudimentary form of named styles via the URL-based styles setter:
<Label styles="@my_label_styles.json"/>
There are a couple of downsides to this approach, though:
- It requires designers to split their style definitions into many small files.
- It only allows the designer to apply a single set of styles; style sets cannot be combined (e.g. "apply both my_styles1.json and my_styles2.json"), nor can they be overridden on a per-component basis by applying local styles (e.g. "apply my_styles.json and {foo:'bar'}").
I have a proposed solution and I would like to hear your feedback on it. I suggest that we add a "namedStyles" property at the Container level. This property would be a read-only dictionary mapping style group names to maps of style properties:
Container {
NamedStyleDictionary : Dictionary<String, Map<String, ?>>
}
These styles could be referred to by child components of the container. For example, the following would create a "boldLabel" style at the Window level and apply it to the window's content:
<Window namedStyles="{boldLabel:{font:{bold:true}}}">
<Label styles="boldLabel"/>
</Window>
Named styles could be combined as well as augmented on a per-component basis by local styles:
<Label styles="boldLabel, redLabel, {backgroundColor:'#00ff00'}"/>
Additionally, nested container could override styles defined by an ancestor:
<Window namedStyles="{myLabel:{color:'#ff0000'}}">
<BoxPane namedStyles="{myLabel:{color:'#0000ff'}}">
<!-- Label text will be blue -->
<Label styles="myLabel"/>
</BoxPane>
</Window>
Finally, named styles could be stored externally and loaded via URL or resource path:
<Window namedStyles="@my_styles.json">
...
</Window>
<Window namedStyles="com/foo/my_styles.json">
...
</Window>
Overall, I think the approach works well. It addresses the major issues that have been raised and does so in a manner that is consistent with other aspects of BXML and WTK. There is only one aspect of the design that I am not 100% happy with - supporting a simple "namedStyles" attribute would only allow the developer to include a single named styles definition per container. In practice, this is probably sufficient, but it would be nice to support multiple style sheets if possible. My proposed solution to this is as follows:
<Window>
<namedStyles buttons="@button_styles.json"
labels="{color:'#ff0000'}"/>
...
</Window>
This would be the equivalent of the following style sheet applied via the "namedStyles" attribute:
{ buttons: {
// content of button_styles.json
},
labels: {
color: "#ff0000"
}
}
This syntax could be supported in addition to, or instead of, the attribute syntax.
Please let me know what you think of this possible approach.
Thanks,
Greg
RE: Named styles
Posted by Sandro Martini <sa...@gmail.com>.
Hi,
in my opinion anything useful to reduce duplicate styles customization
inside bxml/wtkx files is good (and less error-prone). So I agree with your
proposal on Container level, without introducing too much complex things, at
least as a starting point.
More in detail, I've not a clear idea if it will be better to implement/use
it as a container attribute, or if a sub-element, but to me is a detail, no
preference at the moment.
A question: using the URL-based styles setter (in the attribute style), will
it be possible to set multiple styles in the same external json file ? If
this is right for me can be enough (at least at the moment, and see later
for a generalization).
Or ... an old thing come to my mind:
do you remember a ticket ( https://issues.apache.org/jira/browse/PIVOT-245 )
related to add some more parametrization of Terra theme in the json file
(and pass it at application startup) ?
Having default (overridden) styles there maybe could be another similar way
to have overridden styles in application-specific json files, in a
transparent way ... comments ?
Bye,
Sandro
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/Named-styles-tp933133p933727.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: Named styles
Posted by Greg Brown <gk...@mac.com>.
> Based on discussions I have seen folks were also thinking about CSS-like
> styling.
By "CSS-like", I simply meant that we might want to consider supporting a feature similar to CSS classes. I did not mean that we would attempt to support CSS syntax or replicate any other CSS behaviors.
> This uses JSON as the backing store for styling content. Currently,
> pivot supports styling form json files using a special @ notation, directly
> specified in strings through JSON, and now as proposed using inherited
> styling with style sheets as well as combining styles in a string-based DSL
> with classpath resources and URL implied notation.
The '@' syntax is not specific to styles. It is one of BeanSerializer's resolution operators. While JSON-formatted styles could be considered a DSL, it is really just the encoding supported by Component#setStyles(String).
> I think simple was left behind awhile ago.
It is actually pretty simple. There is one primary way to set styles - via Component.StyleDictionary. However, as with many things in BXML, there are multiple ways to accomplish the same thing.
> There are two issues around styling discussed below: specifying styling and
> getting the right styling information to the right component at the right
> time.
They aren't really two separate issues. Styling is applied whenever the component's style dictionary is modified. The "right" information is simply the information you pass to the style dictionary at that time.
> Pluggable *could* mean changing the style property to a StyleProvider
> interface and making StyleProvider have one method that says Map<String, ?>
> getStyles().
This is the unnecessary complexity Noel is talking about. The current styling mechanism is well defined and is already pretty flexible. This approach seems like it is intended to address a hypothetical use case, which, as I have said before, we try to stay away from in Pivot.
G
RE: Named styles
Posted by aappddeevv <aa...@verizon.net>.
Based on discussions I have seen folks were also thinking about CSS-like
styling. This uses JSON as the backing store for styling content. Currently,
pivot supports styling form json files using a special @ notation, directly
specified in strings through JSON, and now as proposed using inherited
styling with style sheets as well as combining styles in a string-based DSL
with classpath resources and URL implied notation.
I think simple was left behind awhile ago.
There are two issues around styling discussed below: specifying styling and
getting the right styling information to the right component at the right
time. I am separating these two issues to understand how you are addressing
each separately and together.
Pluggable *could* mean changing the style property to a StyleProvider
interface and making StyleProvider have one method that says Map<String, ?>
getStyles(). The default implementation would accept a string that does
everything you describe below so it would like transparent to clients. The
audience for this would be developers not pure library clients. It would
help you migrate styling in the future as your mechanism evolves.
-----Original Message-----
From: Noel Grandin [mailto:noelgrandin@gmail.com]
Sent: Wednesday, June 30, 2010 11:57 AM
To: dev@pivot.apache.org
Cc: aappddeevv
Subject: Re: Named styles
What use-case are you targeting here?
I don't see a a clear need for having multiple styling mechanisms, and
supporting such a mechanism would add unnecessary
complexity.
-- Noel Grandin
aappddeevv wrote:
> I think any step you take in this direction is good!
>
> However, what you propose can be accomplished in external code with a few
> static methods. It would be good to understand what pivot's intentions are
> around the evolution of the themeing/skin API and how styling features fit
> into that in a seamless way.
>
> Also, the use of the approach embeds another DSL (for combining styles)
into
> an attribute's string values (which is not pluggable in the current pivot
> code base) and I would think very carefully about doing that. If you are
> going to make any changes, I would encourage making styling more pluggable
> and make the approach you outline one instantiation of that pluggable
> approach.
>
>
>
>
> -----Original Message-----
> From: Greg Brown [mailto:gkbrown@mac.com]
> Sent: Wednesday, June 30, 2010 9:01 AM
> To: dev@pivot.apache.org
> Subject: Named styles
>
> Hi all,
>
> I have recently been giving some thought to how we might support a form of
> style propagation. This has come up a few times and is clearly a feature
> that developers would like the platform to provide.
>
> By design, Pivot does not currently support style inheritance. We decided
up
> front that there is not enough commonality between component and container
> styles for such an inheritance mechanism to make sense. What does make
> sense, however, is the concept of "named styles". These are similar in
> concept to CSS classes - they would allow a caller to specify a set of
> styles by name that should be applied to a component. For example, all
> Labels associated with the "boldLabel" named style would be bold.
>
> Pivot currently supports a rudimentary form of named styles via the
> URL-based styles setter:
>
> <Label styles="@my_label_styles.json"/>
>
> There are a couple of downsides to this approach, though:
>
> - It requires designers to split their style definitions into many small
> files.
>
> - It only allows the designer to apply a single set of styles; style sets
> cannot be combined (e.g. "apply both my_styles1.json and
my_styles2.json"),
> nor can they be overridden on a per-component basis by applying local
styles
> (e.g. "apply my_styles.json and {foo:'bar'}").
>
> I have a proposed solution and I would like to hear your feedback on it. I
> suggest that we add a "namedStyles" property at the Container level. This
> property would be a read-only dictionary mapping style group names to maps
> of style properties:
>
> Container {
> NamedStyleDictionary : Dictionary<String, Map<String, ?>>
> }
>
> These styles could be referred to by child components of the container.
For
> example, the following would create a "boldLabel" style at the Window
level
> and apply it to the window's content:
>
> <Window namedStyles="{boldLabel:{font:{bold:true}}}">
> <Label styles="boldLabel"/>
> </Window>
>
> Named styles could be combined as well as augmented on a per-component
basis
> by local styles:
>
> <Label styles="boldLabel, redLabel, {backgroundColor:'#00ff00'}"/>
>
> Additionally, nested container could override styles defined by an
ancestor:
>
> <Window namedStyles="{myLabel:{color:'#ff0000'}}">
> <BoxPane namedStyles="{myLabel:{color:'#0000ff'}}">
> <!-- Label text will be blue -->
> <Label styles="myLabel"/>
> </BoxPane>
> </Window>
>
> Finally, named styles could be stored externally and loaded via URL or
> resource path:
>
> <Window namedStyles="@my_styles.json">
> ...
> </Window>
>
> <Window namedStyles="com/foo/my_styles.json">
> ...
> </Window>
>
> Overall, I think the approach works well. It addresses the major issues
that
> have been raised and does so in a manner that is consistent with other
> aspects of BXML and WTK. There is only one aspect of the design that I am
> not 100% happy with - supporting a simple "namedStyles" attribute would
only
> allow the developer to include a single named styles definition per
> container. In practice, this is probably sufficient, but it would be nice
to
> support multiple style sheets if possible. My proposed solution to this is
> as follows:
>
> <Window>
> <namedStyles buttons="@button_styles.json"
> labels="{color:'#ff0000'}"/>
> ...
> </Window>
>
> This would be the equivalent of the following style sheet applied via the
> "namedStyles" attribute:
>
> { buttons: {
> // content of button_styles.json
> },
>
> labels: {
> color: "#ff0000"
> }
> }
>
> This syntax could be supported in addition to, or instead of, the
attribute
> syntax.
>
> Please let me know what you think of this possible approach.
>
> Thanks,
> Greg
>
Re: Named styles
Posted by Noel Grandin <no...@gmail.com>.
What use-case are you targeting here?
I don't see a a clear need for having multiple styling mechanisms, and supporting such a mechanism would add unnecessary
complexity.
-- Noel Grandin
aappddeevv wrote:
> I think any step you take in this direction is good!
>
> However, what you propose can be accomplished in external code with a few
> static methods. It would be good to understand what pivot's intentions are
> around the evolution of the themeing/skin API and how styling features fit
> into that in a seamless way.
>
> Also, the use of the approach embeds another DSL (for combining styles) into
> an attribute's string values (which is not pluggable in the current pivot
> code base) and I would think very carefully about doing that. If you are
> going to make any changes, I would encourage making styling more pluggable
> and make the approach you outline one instantiation of that pluggable
> approach.
>
>
>
>
> -----Original Message-----
> From: Greg Brown [mailto:gkbrown@mac.com]
> Sent: Wednesday, June 30, 2010 9:01 AM
> To: dev@pivot.apache.org
> Subject: Named styles
>
> Hi all,
>
> I have recently been giving some thought to how we might support a form of
> style propagation. This has come up a few times and is clearly a feature
> that developers would like the platform to provide.
>
> By design, Pivot does not currently support style inheritance. We decided up
> front that there is not enough commonality between component and container
> styles for such an inheritance mechanism to make sense. What does make
> sense, however, is the concept of "named styles". These are similar in
> concept to CSS classes - they would allow a caller to specify a set of
> styles by name that should be applied to a component. For example, all
> Labels associated with the "boldLabel" named style would be bold.
>
> Pivot currently supports a rudimentary form of named styles via the
> URL-based styles setter:
>
> <Label styles="@my_label_styles.json"/>
>
> There are a couple of downsides to this approach, though:
>
> - It requires designers to split their style definitions into many small
> files.
>
> - It only allows the designer to apply a single set of styles; style sets
> cannot be combined (e.g. "apply both my_styles1.json and my_styles2.json"),
> nor can they be overridden on a per-component basis by applying local styles
> (e.g. "apply my_styles.json and {foo:'bar'}").
>
> I have a proposed solution and I would like to hear your feedback on it. I
> suggest that we add a "namedStyles" property at the Container level. This
> property would be a read-only dictionary mapping style group names to maps
> of style properties:
>
> Container {
> NamedStyleDictionary : Dictionary<String, Map<String, ?>>
> }
>
> These styles could be referred to by child components of the container. For
> example, the following would create a "boldLabel" style at the Window level
> and apply it to the window's content:
>
> <Window namedStyles="{boldLabel:{font:{bold:true}}}">
> <Label styles="boldLabel"/>
> </Window>
>
> Named styles could be combined as well as augmented on a per-component basis
> by local styles:
>
> <Label styles="boldLabel, redLabel, {backgroundColor:'#00ff00'}"/>
>
> Additionally, nested container could override styles defined by an ancestor:
>
> <Window namedStyles="{myLabel:{color:'#ff0000'}}">
> <BoxPane namedStyles="{myLabel:{color:'#0000ff'}}">
> <!-- Label text will be blue -->
> <Label styles="myLabel"/>
> </BoxPane>
> </Window>
>
> Finally, named styles could be stored externally and loaded via URL or
> resource path:
>
> <Window namedStyles="@my_styles.json">
> ...
> </Window>
>
> <Window namedStyles="com/foo/my_styles.json">
> ...
> </Window>
>
> Overall, I think the approach works well. It addresses the major issues that
> have been raised and does so in a manner that is consistent with other
> aspects of BXML and WTK. There is only one aspect of the design that I am
> not 100% happy with - supporting a simple "namedStyles" attribute would only
> allow the developer to include a single named styles definition per
> container. In practice, this is probably sufficient, but it would be nice to
> support multiple style sheets if possible. My proposed solution to this is
> as follows:
>
> <Window>
> <namedStyles buttons="@button_styles.json"
> labels="{color:'#ff0000'}"/>
> ...
> </Window>
>
> This would be the equivalent of the following style sheet applied via the
> "namedStyles" attribute:
>
> { buttons: {
> // content of button_styles.json
> },
>
> labels: {
> color: "#ff0000"
> }
> }
>
> This syntax could be supported in addition to, or instead of, the attribute
> syntax.
>
> Please let me know what you think of this possible approach.
>
> Thanks,
> Greg
>
RE: Named styles
Posted by aappddeevv <aa...@verizon.net>.
I think any step you take in this direction is good!
However, what you propose can be accomplished in external code with a few
static methods. It would be good to understand what pivot's intentions are
around the evolution of the themeing/skin API and how styling features fit
into that in a seamless way.
Also, the use of the approach embeds another DSL (for combining styles) into
an attribute's string values (which is not pluggable in the current pivot
code base) and I would think very carefully about doing that. If you are
going to make any changes, I would encourage making styling more pluggable
and make the approach you outline one instantiation of that pluggable
approach.
-----Original Message-----
From: Greg Brown [mailto:gkbrown@mac.com]
Sent: Wednesday, June 30, 2010 9:01 AM
To: dev@pivot.apache.org
Subject: Named styles
Hi all,
I have recently been giving some thought to how we might support a form of
style propagation. This has come up a few times and is clearly a feature
that developers would like the platform to provide.
By design, Pivot does not currently support style inheritance. We decided up
front that there is not enough commonality between component and container
styles for such an inheritance mechanism to make sense. What does make
sense, however, is the concept of "named styles". These are similar in
concept to CSS classes - they would allow a caller to specify a set of
styles by name that should be applied to a component. For example, all
Labels associated with the "boldLabel" named style would be bold.
Pivot currently supports a rudimentary form of named styles via the
URL-based styles setter:
<Label styles="@my_label_styles.json"/>
There are a couple of downsides to this approach, though:
- It requires designers to split their style definitions into many small
files.
- It only allows the designer to apply a single set of styles; style sets
cannot be combined (e.g. "apply both my_styles1.json and my_styles2.json"),
nor can they be overridden on a per-component basis by applying local styles
(e.g. "apply my_styles.json and {foo:'bar'}").
I have a proposed solution and I would like to hear your feedback on it. I
suggest that we add a "namedStyles" property at the Container level. This
property would be a read-only dictionary mapping style group names to maps
of style properties:
Container {
NamedStyleDictionary : Dictionary<String, Map<String, ?>>
}
These styles could be referred to by child components of the container. For
example, the following would create a "boldLabel" style at the Window level
and apply it to the window's content:
<Window namedStyles="{boldLabel:{font:{bold:true}}}">
<Label styles="boldLabel"/>
</Window>
Named styles could be combined as well as augmented on a per-component basis
by local styles:
<Label styles="boldLabel, redLabel, {backgroundColor:'#00ff00'}"/>
Additionally, nested container could override styles defined by an ancestor:
<Window namedStyles="{myLabel:{color:'#ff0000'}}">
<BoxPane namedStyles="{myLabel:{color:'#0000ff'}}">
<!-- Label text will be blue -->
<Label styles="myLabel"/>
</BoxPane>
</Window>
Finally, named styles could be stored externally and loaded via URL or
resource path:
<Window namedStyles="@my_styles.json">
...
</Window>
<Window namedStyles="com/foo/my_styles.json">
...
</Window>
Overall, I think the approach works well. It addresses the major issues that
have been raised and does so in a manner that is consistent with other
aspects of BXML and WTK. There is only one aspect of the design that I am
not 100% happy with - supporting a simple "namedStyles" attribute would only
allow the developer to include a single named styles definition per
container. In practice, this is probably sufficient, but it would be nice to
support multiple style sheets if possible. My proposed solution to this is
as follows:
<Window>
<namedStyles buttons="@button_styles.json"
labels="{color:'#ff0000'}"/>
...
</Window>
This would be the equivalent of the following style sheet applied via the
"namedStyles" attribute:
{ buttons: {
// content of button_styles.json
},
labels: {
color: "#ff0000"
}
}
This syntax could be supported in addition to, or instead of, the attribute
syntax.
Please let me know what you think of this possible approach.
Thanks,
Greg
Re: Named styles
Posted by Michael Allman <ms...@allman.ms>.
Hmmmmm... why not use a subset of CSS syntax? Define CSS classes inline
or in stylesheets and define class attributes on elements? Kinda like
html.
Cheers,
Michael
On Wed, 30 Jun 2010, Greg Brown wrote:
> Hi all,
>
> I have recently been giving some thought to how we might support a form
> of style propagation. This has come up a few times and is clearly a
> feature that developers would like the platform to provide.
>
> By design, Pivot does not currently support style inheritance. We
> decided up front that there is not enough commonality between component
> and container styles for such an inheritance mechanism to make sense.
> What does make sense, however, is the concept of "named styles". These
> are similar in concept to CSS classes - they would allow a caller to
> specify a set of styles by name that should be applied to a component.
> For example, all Labels associated with the "boldLabel" named style
> would be bold.
>
> Pivot currently supports a rudimentary form of named styles via the
> URL-based styles setter:
>
> <Label styles="@my_label_styles.json"/>
>
> There are a couple of downsides to this approach, though:
>
> - It requires designers to split their style definitions into many small
> files.
>
> - It only allows the designer to apply a single set of styles; style
> sets cannot be combined (e.g. "apply both my_styles1.json and
> my_styles2.json"), nor can they be overridden on a per-component basis
> by applying local styles (e.g. "apply my_styles.json and {foo:'bar'}").
>
> I have a proposed solution and I would like to hear your feedback on it.
> I suggest that we add a "namedStyles" property at the Container level.
> This property would be a read-only dictionary mapping style group names
> to maps of style properties:
>
> Container {
> NamedStyleDictionary : Dictionary<String, Map<String, ?>>
> }
>
> These styles could be referred to by child components of the container.
> For example, the following would create a "boldLabel" style at the
> Window level and apply it to the window's content:
>
> <Window namedStyles="{boldLabel:{font:{bold:true}}}">
> <Label styles="boldLabel"/>
> </Window>
>
> Named styles could be combined as well as augmented on a per-component
> basis by local styles:
>
> <Label styles="boldLabel, redLabel, {backgroundColor:'#00ff00'}"/>
>
> Additionally, nested container could override styles defined by an
> ancestor:
>
> <Window namedStyles="{myLabel:{color:'#ff0000'}}">
> <BoxPane namedStyles="{myLabel:{color:'#0000ff'}}">
> <!-- Label text will be blue -->
> <Label styles="myLabel"/>
> </BoxPane>
> </Window>
>
> Finally, named styles could be stored externally and loaded via URL or
> resource path:
>
> <Window namedStyles="@my_styles.json">
> ...
> </Window>
>
> <Window namedStyles="com/foo/my_styles.json">
> ...
> </Window>
>
> Overall, I think the approach works well. It addresses the major issues
> that have been raised and does so in a manner that is consistent with
> other aspects of BXML and WTK. There is only one aspect of the design
> that I am not 100% happy with - supporting a simple "namedStyles"
> attribute would only allow the developer to include a single named
> styles definition per container. In practice, this is probably
> sufficient, but it would be nice to support multiple style sheets if
> possible. My proposed solution to this is as follows:
>
> <Window>
> <namedStyles buttons="@button_styles.json"
> labels="{color:'#ff0000'}"/>
> ...
> </Window>
>
> This would be the equivalent of the following style sheet applied via
> the "namedStyles" attribute:
>
> { buttons: {
> // content of button_styles.json
> },
>
> labels: {
> color: "#ff0000"
> }
> }
>
> This syntax could be supported in addition to, or instead of, the
> attribute syntax.
>
> Please let me know what you think of this possible approach.
>
> Thanks,
> Greg
>
Re: Named styles
Posted by Greg Brown <gk...@mac.com>.
> How about
>
> <Window namedStyles="{ buttons: @button_styles.json, labels : {color:'#ff0000'} }"/>
BeanSerializer isn't capable of detecting an embedded @ symbol, and I don't think it should be. That would impose too many assumptions about the content of an attribute.
> Hmmm, all this makes me wonder why we don't use a pure-JSON format for UI files???
JSON doesn't provide any support for custom types, so you'd need to extend the syntax; for example:
Window: {
title: "My Window Title",
content: BoxPane: [
Label {
text: "My Label Text"
}
]
}
YAML does something like this, as does JavaFX. It's not out of the question and could be an interesting future exercise. However, I don't think there's anything wrong with the XML approach for now (it is conceptually similar to HTML, MXML, and XAML, which most developers are already familiar with).
G
Re: Named styles
Posted by Noel Grandin <no...@gmail.com>.
How about
<Window namedStyles="{ buttons: @button_styles.json, labels : {color:'#ff0000'} }"/>
...
</Window>
Hmmm, all this makes me wonder why we don't use a pure-JSON format for UI files???
Greg Brown wrote:
> Hi all,
>
> I have recently been giving some thought to how we might support a form of style propagation. This has come up a few times and is clearly a feature that developers would like the platform to provide.
>
> By design, Pivot does not currently support style inheritance. We decided up front that there is not enough commonality between component and container styles for such an inheritance mechanism to make sense. What does make sense, however, is the concept of "named styles". These are similar in concept to CSS classes - they would allow a caller to specify a set of styles by name that should be applied to a component. For example, all Labels associated with the "boldLabel" named style would be bold.
>
> Pivot currently supports a rudimentary form of named styles via the URL-based styles setter:
>
> <Label styles="@my_label_styles.json"/>
>
> There are a couple of downsides to this approach, though:
>
> - It requires designers to split their style definitions into many small files.
>
> - It only allows the designer to apply a single set of styles; style sets cannot be combined (e.g. "apply both my_styles1.json and my_styles2.json"), nor can they be overridden on a per-component basis by applying local styles (e.g. "apply my_styles.json and {foo:'bar'}").
>
> I have a proposed solution and I would like to hear your feedback on it. I suggest that we add a "namedStyles" property at the Container level. This property would be a read-only dictionary mapping style group names to maps of style properties:
>
> Container {
> NamedStyleDictionary : Dictionary<String, Map<String, ?>>
> }
>
> These styles could be referred to by child components of the container. For example, the following would create a "boldLabel" style at the Window level and apply it to the window's content:
>
> <Window namedStyles="{boldLabel:{font:{bold:true}}}">
> <Label styles="boldLabel"/>
> </Window>
>
> Named styles could be combined as well as augmented on a per-component basis by local styles:
>
> <Label styles="boldLabel, redLabel, {backgroundColor:'#00ff00'}"/>
>
> Additionally, nested container could override styles defined by an ancestor:
>
> <Window namedStyles="{myLabel:{color:'#ff0000'}}">
> <BoxPane namedStyles="{myLabel:{color:'#0000ff'}}">
> <!-- Label text will be blue -->
> <Label styles="myLabel"/>
> </BoxPane>
> </Window>
>
> Finally, named styles could be stored externally and loaded via URL or resource path:
>
> <Window namedStyles="@my_styles.json">
> ...
> </Window>
>
> <Window namedStyles="com/foo/my_styles.json">
> ...
> </Window>
>
> Overall, I think the approach works well. It addresses the major issues that have been raised and does so in a manner that is consistent with other aspects of BXML and WTK. There is only one aspect of the design that I am not 100% happy with - supporting a simple "namedStyles" attribute would only allow the developer to include a single named styles definition per container. In practice, this is probably sufficient, but it would be nice to support multiple style sheets if possible. My proposed solution to this is as follows:
>
> <Window>
> <namedStyles buttons="@button_styles.json"
> labels="{color:'#ff0000'}"/>
> ...
> </Window>
>
> This would be the equivalent of the following style sheet applied via the "namedStyles" attribute:
>
> { buttons: {
> // content of button_styles.json
> },
>
> labels: {
> color: "#ff0000"
> }
> }
>
> This syntax could be supported in addition to, or instead of, the attribute syntax.
>
> Please let me know what you think of this possible approach.
>
> Thanks,
> Greg
>