You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Si...@DMR.CA on 2006/07/10 15:29:10 UTC
Follow-up on skin issues
Hello,
I redid the test with the menuList, you were right about the
menuList::selected, it's just ignored completely. The bold weight I was
seeing on the selected field was coming from .AFDefaultBoldFont:alias,
sorry about that.
However, I had other comments about the skin from users. Another example
of badly answering skin is with the messages component. If the user
specifies the following selectors, he'll assume that he'll get a message
zone using a green background:
af|messages
{
background-color: green;
}
af|messages::header
{
padding-left: 20px;
}
af|messages::body
{
border-top-style: solid;
border-top-color: #ffffff;
border-top-width: 3px;
width: 100%;
}
Sadly, the resulting background will be gray because
.AFLightAccentBackground:alias will be used because simple skin import it
on ::body selector. Of course, one could inhibit ; background-color on
body, but again the user will have to execute the page first to figure it
out.
Also, I would like to open a discussion on the pertinence of applying
.AFDefaultFont:alias and .AFLinkForeground:alias prety much everywhere in
the page. I think those two alone cause the most troubles for the end
user. I think we could coerce those in some predefined selectors in the
final CSS:
AFDefaultFont:alias --> *
AFDefaultFont:alias --> h1 *
AFDefaultFont:alias --> h2 *
AFDefaultFont:alias --> h3 *
AFDefaultFont:alias --> h4 *
or
AFDefaultFont:alias --> .panelHeaderClass *
and
AFLinkForeground:alias --> a:link
or
AFLinkForeground:alias --> *:link
That way they would be applied to everything, but at a lower priority
inside the cascading style chain, thus making easier to override the style
on child elements using the skin rather than sometimes being forced to use
inlineStyle.
That sounds acceptale?
Regards,
Simon Lessard
Fujitsu Consulting
Re: Follow-up on skin issues
Posted by Adam Winer <aw...@gmail.com>.
Hey, folks - as items come out of this discussion (like a doc generator
for skining, etc.), could you file them in the issue tracker? We don't
want these ideas getting lost!
-- Adam
On 7/11/06, Simon_Lessard@dmr.ca <Si...@dmr.ca> wrote:
>
> Hello,
>
> An automated documentation generator would indeed be great.
>
>
> Simon Lessard
> Fujitsu Consulting
>
>
>
>
>
>
> Jeanne Waldman <je...@oracle.com>
> 2006-07-10 17:59
> Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: Follow-up on skin issues
>
>
> Hi Simon,
>
> Thanks again for your feedback. It would be awesome if we could get more
> feedback from users of the skinning feature.
>
> I could see a configuration setting where you can say you want your skin
> to inherit from simple or to inherit from nothing at all.
> But I really think this will cause way more problems than it solves.
> I think the inhibit feature would have helped so much that you wouldn't
> have wanted or needed to inhibit everything. :)
> And of course, we definitely need better documentation.
> Ideally, we should have one source of truth -- the .xss files and base
> .css files if any, and it would be awesome to be able to generate
> documentation off of that that shows each skin selector and what it
> includes... this would be before the step that resolves the included
> styles.
>
> - Jeanne
>
> Simon_Lessard@DMR.CA wrote:
>
> >Sun Certified Programmer for Java 2 Platform 1.4
> >
> >
> >
> >
> >Jeanne Waldman <je...@oracle.com>
> >2006-07-10 15:47
> >Please respond to adffaces-dev
> >
> > To: adffaces-dev@incubator.apache.org
> > cc:
> > Subject: Re: Follow-up on skin issues
> >
> >
> >
> >
> >Simon_Lessard@DMR.CA wrote:
> >
> >
> >
> >>Hello,
> >>
> >>I redid the test with the menuList, you were right about the
> >>menuList::selected, it's just ignored completely. The bold weight I was
> >>seeing on the selected field was coming from .AFDefaultBoldFont:alias,
> >>sorry about that.
> >>
> >>However, I had other comments about the skin from users. Another example
>
> >>of badly answering skin is with the messages component. If the user
> >>specifies the following selectors, he'll assume that he'll get a message
>
> >>zone using a green background:
> >>
> >>af|messages
> >>{
> >> background-color: green;
> >>}
> >>
> >>af|messages::header
> >>{
> >> padding-left: 20px;
> >>}
> >>
> >>af|messages::body
> >>{
> >> border-top-style: solid;
> >> border-top-color: #ffffff;
> >> border-top-width: 3px;
> >> width: 100%;
> >>}
> >>
> >>Sadly, the resulting background will be gray because
> >>.AFLightAccentBackground:alias will be used because simple skin import
> it
> >>
> >>
> >
> >
> >
> >>on ::body selector. Of course, one could inhibit ; background-color on
> >>body, but again the user will have to execute the page first to figure
> it
> >>
> >>
> >
> >
> >
> >>out.
> >>
> >>Also, I would like to open a discussion on the pertinence of applying
> >>.AFDefaultFont:alias and .AFLinkForeground:alias prety much everywhere
> in
> >>
> >>
> >
> >
> >
> >>the page. I think those two alone cause the most troubles for the end
> >>user. I think we could coerce those in some predefined selectors in the
> >>final CSS:
> >>
> >>
> >>
> >>
> >I think that these aliases are really nice to have because it is a quick
> >hook for a person to change the colors of the entire application.
> >If the skinner doesn't like this hook, then he can use the inhibit
> >feature to inhibit these properties.
> >
> >
> >
> >The question then is how often will the skinners inhibit everything. If
> >inhibit is used for more than 50% of the selectors, it makes automatic
> >inheritance quite obsolete.
> >
> >Another compromise I see would be to make it so that simple skin does not
>
> >include aliases in any pseudo-element selector, or don't use aliases at
> >all, that is :
> >
> >af|messages {
> > // rule ref allowed in simple skin
> >}
> >
> >af|messages:body {
> > // rule ref not allowed in simple skin
> >}
> >
> >This would ensure that most components get easily skinned without having
> >to inhibit prety much everything since you often want to change the look
> >of the whole component. Also, if simple skin don't use any alias, it will
>
> >really be simple, once inheriting from a different skin than simple is
> >implemented, nothing would prevent Trinidad to have more than one base
> >skin: simple skin not using any rule ref and maybe minimal using what
> >simple skin currently uses. By the way, maybe those names should be
> >changed, I don't know if it's only in French, but here minimal often
> means
> >less than simple, not the other way around. Of course, it's only a
> >semantic debate here.
> >
> >As a metric, we planned 10 days for the skin on our ADF Faces project.
> The
> >result was a 775 lines (including comments and blank lines) file that
> took
> >25 days to create. Comparatively, all other tasks were finished about 10%
>
> >faster than planned. Of course, that's only one project and one cannot
> >generalize from it. Furthermore, inbithit was not supported at this time
> >either. That being said, I believe there's still some teachings to get
> out
> >of it.
> >
> >
> >
> >
> >
> >>AFDefaultFont:alias --> *
> >>
> >>AFDefaultFont:alias --> h1 *
> >>AFDefaultFont:alias --> h2 *
> >>AFDefaultFont:alias --> h3 *
> >>AFDefaultFont:alias --> h4 *
> >>or
> >>AFDefaultFont:alias --> .panelHeaderClass *
> >>
> >>and
> >>
> >>AFLinkForeground:alias --> a:link
> >>or
> >>AFLinkForeground:alias --> *:link
> >>
> >>That way they would be applied to everything, but at a lower priority
> >>inside the cascading style chain, thus making easier to override the
> >>
> >>
> >style
> >
> >
> >>on child elements using the skin rather than sometimes being forced to
> >>
> >>
> >use
> >
> >
> >>inlineStyle.
> >>
> >>
> >>
> >>
> >The skinner could add style definitions like this:
> >* {font-family: Ariel}
> >h1 * {font-family:Ariel}
> >then he could inhibit the AFDefaultFont:alias's properties to get this
> >effect.
> >We don't map our alias style definitions to html constructs like you are
> >suggesting. They are simply
> >mechanisms to include in other styles to make it quicker to make changes
> >to multiple components.
> >
> >That would work. However, using such construct would force the skinner to
>
> >be more apt at CSS than only knowing skin selectors.
> >
> >
> >
> >
> >
> >I think documenting what skin style keys include would be useful to a
> >skinner.
> >
> >Extremely, that alone could greatly improves user's experience with
> skins.
> >
> >
> >
> >
> >
> >Regards,
> >
> >Simon Lessard
> >Fujitsu Consulting
> >
> >
> >
>
>
>
>
Re: Follow-up on skin issues
Posted by Si...@DMR.CA.
Hello,
An automated documentation generator would indeed be great.
Simon Lessard
Fujitsu Consulting
Jeanne Waldman <je...@oracle.com>
2006-07-10 17:59
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: Follow-up on skin issues
Hi Simon,
Thanks again for your feedback. It would be awesome if we could get more
feedback from users of the skinning feature.
I could see a configuration setting where you can say you want your skin
to inherit from simple or to inherit from nothing at all.
But I really think this will cause way more problems than it solves.
I think the inhibit feature would have helped so much that you wouldn't
have wanted or needed to inhibit everything. :)
And of course, we definitely need better documentation.
Ideally, we should have one source of truth -- the .xss files and base
.css files if any, and it would be awesome to be able to generate
documentation off of that that shows each skin selector and what it
includes... this would be before the step that resolves the included
styles.
- Jeanne
Simon_Lessard@DMR.CA wrote:
>Sun Certified Programmer for Java 2 Platform 1.4
>
>
>
>
>Jeanne Waldman <je...@oracle.com>
>2006-07-10 15:47
>Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: Follow-up on skin issues
>
>
>
>
>Simon_Lessard@DMR.CA wrote:
>
>
>
>>Hello,
>>
>>I redid the test with the menuList, you were right about the
>>menuList::selected, it's just ignored completely. The bold weight I was
>>seeing on the selected field was coming from .AFDefaultBoldFont:alias,
>>sorry about that.
>>
>>However, I had other comments about the skin from users. Another example
>>of badly answering skin is with the messages component. If the user
>>specifies the following selectors, he'll assume that he'll get a message
>>zone using a green background:
>>
>>af|messages
>>{
>> background-color: green;
>>}
>>
>>af|messages::header
>>{
>> padding-left: 20px;
>>}
>>
>>af|messages::body
>>{
>> border-top-style: solid;
>> border-top-color: #ffffff;
>> border-top-width: 3px;
>> width: 100%;
>>}
>>
>>Sadly, the resulting background will be gray because
>>.AFLightAccentBackground:alias will be used because simple skin import
it
>>
>>
>
>
>
>>on ::body selector. Of course, one could inhibit ; background-color on
>>body, but again the user will have to execute the page first to figure
it
>>
>>
>
>
>
>>out.
>>
>>Also, I would like to open a discussion on the pertinence of applying
>>.AFDefaultFont:alias and .AFLinkForeground:alias prety much everywhere
in
>>
>>
>
>
>
>>the page. I think those two alone cause the most troubles for the end
>>user. I think we could coerce those in some predefined selectors in the
>>final CSS:
>>
>>
>>
>>
>I think that these aliases are really nice to have because it is a quick
>hook for a person to change the colors of the entire application.
>If the skinner doesn't like this hook, then he can use the inhibit
>feature to inhibit these properties.
>
>
>
>The question then is how often will the skinners inhibit everything. If
>inhibit is used for more than 50% of the selectors, it makes automatic
>inheritance quite obsolete.
>
>Another compromise I see would be to make it so that simple skin does not
>include aliases in any pseudo-element selector, or don't use aliases at
>all, that is :
>
>af|messages {
> // rule ref allowed in simple skin
>}
>
>af|messages:body {
> // rule ref not allowed in simple skin
>}
>
>This would ensure that most components get easily skinned without having
>to inhibit prety much everything since you often want to change the look
>of the whole component. Also, if simple skin don't use any alias, it will
>really be simple, once inheriting from a different skin than simple is
>implemented, nothing would prevent Trinidad to have more than one base
>skin: simple skin not using any rule ref and maybe minimal using what
>simple skin currently uses. By the way, maybe those names should be
>changed, I don't know if it's only in French, but here minimal often
means
>less than simple, not the other way around. Of course, it's only a
>semantic debate here.
>
>As a metric, we planned 10 days for the skin on our ADF Faces project.
The
>result was a 775 lines (including comments and blank lines) file that
took
>25 days to create. Comparatively, all other tasks were finished about 10%
>faster than planned. Of course, that's only one project and one cannot
>generalize from it. Furthermore, inbithit was not supported at this time
>either. That being said, I believe there's still some teachings to get
out
>of it.
>
>
>
>
>
>>AFDefaultFont:alias --> *
>>
>>AFDefaultFont:alias --> h1 *
>>AFDefaultFont:alias --> h2 *
>>AFDefaultFont:alias --> h3 *
>>AFDefaultFont:alias --> h4 *
>>or
>>AFDefaultFont:alias --> .panelHeaderClass *
>>
>>and
>>
>>AFLinkForeground:alias --> a:link
>>or
>>AFLinkForeground:alias --> *:link
>>
>>That way they would be applied to everything, but at a lower priority
>>inside the cascading style chain, thus making easier to override the
>>
>>
>style
>
>
>>on child elements using the skin rather than sometimes being forced to
>>
>>
>use
>
>
>>inlineStyle.
>>
>>
>>
>>
>The skinner could add style definitions like this:
>* {font-family: Ariel}
>h1 * {font-family:Ariel}
>then he could inhibit the AFDefaultFont:alias's properties to get this
>effect.
>We don't map our alias style definitions to html constructs like you are
>suggesting. They are simply
>mechanisms to include in other styles to make it quicker to make changes
>to multiple components.
>
>That would work. However, using such construct would force the skinner to
>be more apt at CSS than only knowing skin selectors.
>
>
>
>
>
>I think documenting what skin style keys include would be useful to a
>skinner.
>
>Extremely, that alone could greatly improves user's experience with
skins.
>
>
>
>
>
>Regards,
>
>Simon Lessard
>Fujitsu Consulting
>
>
>
Re: Follow-up on skin issues
Posted by Jeanne Waldman <je...@oracle.com>.
Hi Simon,
Thanks again for your feedback. It would be awesome if we could get more
feedback from users of the skinning feature.
I could see a configuration setting where you can say you want your skin
to inherit from simple or to inherit from nothing at all.
But I really think this will cause way more problems than it solves.
I think the inhibit feature would have helped so much that you wouldn't
have wanted or needed to inhibit everything. :)
And of course, we definitely need better documentation.
Ideally, we should have one source of truth -- the .xss files and base
.css files if any, and it would be awesome to be able to generate
documentation off of that that shows each skin selector and what it
includes... this would be before the step that resolves the included styles.
- Jeanne
Simon_Lessard@DMR.CA wrote:
>Sun Certified Programmer for Java 2 Platform 1.4
>
>
>
>
>Jeanne Waldman <je...@oracle.com>
>2006-07-10 15:47
>Please respond to adffaces-dev
>
> To: adffaces-dev@incubator.apache.org
> cc:
> Subject: Re: Follow-up on skin issues
>
>
>
>
>Simon_Lessard@DMR.CA wrote:
>
>
>
>>Hello,
>>
>>I redid the test with the menuList, you were right about the
>>menuList::selected, it's just ignored completely. The bold weight I was
>>seeing on the selected field was coming from .AFDefaultBoldFont:alias,
>>sorry about that.
>>
>>However, I had other comments about the skin from users. Another example
>>of badly answering skin is with the messages component. If the user
>>specifies the following selectors, he'll assume that he'll get a message
>>zone using a green background:
>>
>>af|messages
>>{
>> background-color: green;
>>}
>>
>>af|messages::header
>>{
>> padding-left: 20px;
>>}
>>
>>af|messages::body
>>{
>> border-top-style: solid;
>> border-top-color: #ffffff;
>> border-top-width: 3px;
>> width: 100%;
>>}
>>
>>Sadly, the resulting background will be gray because
>>.AFLightAccentBackground:alias will be used because simple skin import it
>>
>>
>
>
>
>>on ::body selector. Of course, one could inhibit ; background-color on
>>body, but again the user will have to execute the page first to figure it
>>
>>
>
>
>
>>out.
>>
>>Also, I would like to open a discussion on the pertinence of applying
>>.AFDefaultFont:alias and .AFLinkForeground:alias prety much everywhere in
>>
>>
>
>
>
>>the page. I think those two alone cause the most troubles for the end
>>user. I think we could coerce those in some predefined selectors in the
>>final CSS:
>>
>>
>>
>>
>I think that these aliases are really nice to have because it is a quick
>hook for a person to change the colors of the entire application.
>If the skinner doesn't like this hook, then he can use the inhibit
>feature to inhibit these properties.
>
>
>
>The question then is how often will the skinners inhibit everything. If
>inhibit is used for more than 50% of the selectors, it makes automatic
>inheritance quite obsolete.
>
>Another compromise I see would be to make it so that simple skin does not
>include aliases in any pseudo-element selector, or don't use aliases at
>all, that is :
>
>af|messages {
> // rule ref allowed in simple skin
>}
>
>af|messages:body {
> // rule ref not allowed in simple skin
>}
>
>This would ensure that most components get easily skinned without having
>to inhibit prety much everything since you often want to change the look
>of the whole component. Also, if simple skin don't use any alias, it will
>really be simple, once inheriting from a different skin than simple is
>implemented, nothing would prevent Trinidad to have more than one base
>skin: simple skin not using any rule ref and maybe minimal using what
>simple skin currently uses. By the way, maybe those names should be
>changed, I don't know if it's only in French, but here minimal often means
>less than simple, not the other way around. Of course, it's only a
>semantic debate here.
>
>As a metric, we planned 10 days for the skin on our ADF Faces project. The
>result was a 775 lines (including comments and blank lines) file that took
>25 days to create. Comparatively, all other tasks were finished about 10%
>faster than planned. Of course, that's only one project and one cannot
>generalize from it. Furthermore, inbithit was not supported at this time
>either. That being said, I believe there's still some teachings to get out
>of it.
>
>
>
>
>
>>AFDefaultFont:alias --> *
>>
>>AFDefaultFont:alias --> h1 *
>>AFDefaultFont:alias --> h2 *
>>AFDefaultFont:alias --> h3 *
>>AFDefaultFont:alias --> h4 *
>>or
>>AFDefaultFont:alias --> .panelHeaderClass *
>>
>>and
>>
>>AFLinkForeground:alias --> a:link
>>or
>>AFLinkForeground:alias --> *:link
>>
>>That way they would be applied to everything, but at a lower priority
>>inside the cascading style chain, thus making easier to override the
>>
>>
>style
>
>
>>on child elements using the skin rather than sometimes being forced to
>>
>>
>use
>
>
>>inlineStyle.
>>
>>
>>
>>
>The skinner could add style definitions like this:
>* {font-family: Ariel}
>h1 * {font-family:Ariel}
>then he could inhibit the AFDefaultFont:alias's properties to get this
>effect.
>We don't map our alias style definitions to html constructs like you are
>suggesting. They are simply
>mechanisms to include in other styles to make it quicker to make changes
>to multiple components.
>
>That would work. However, using such construct would force the skinner to
>be more apt at CSS than only knowing skin selectors.
>
>
>
>
>
>I think documenting what skin style keys include would be useful to a
>skinner.
>
>Extremely, that alone could greatly improves user's experience with skins.
>
>
>
>
>
>Regards,
>
>Simon Lessard
>Fujitsu Consulting
>
>
>
Re: Follow-up on skin issues
Posted by Si...@DMR.CA.
Sun Certified Programmer for Java 2 Platform 1.4
Jeanne Waldman <je...@oracle.com>
2006-07-10 15:47
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: Follow-up on skin issues
Simon_Lessard@DMR.CA wrote:
>Hello,
>
>I redid the test with the menuList, you were right about the
>menuList::selected, it's just ignored completely. The bold weight I was
>seeing on the selected field was coming from .AFDefaultBoldFont:alias,
>sorry about that.
>
>However, I had other comments about the skin from users. Another example
>of badly answering skin is with the messages component. If the user
>specifies the following selectors, he'll assume that he'll get a message
>zone using a green background:
>
>af|messages
>{
> background-color: green;
>}
>
>af|messages::header
>{
> padding-left: 20px;
>}
>
>af|messages::body
>{
> border-top-style: solid;
> border-top-color: #ffffff;
> border-top-width: 3px;
> width: 100%;
>}
>
>Sadly, the resulting background will be gray because
>.AFLightAccentBackground:alias will be used because simple skin import it
>on ::body selector. Of course, one could inhibit ; background-color on
>body, but again the user will have to execute the page first to figure it
>out.
>
>Also, I would like to open a discussion on the pertinence of applying
>.AFDefaultFont:alias and .AFLinkForeground:alias prety much everywhere in
>the page. I think those two alone cause the most troubles for the end
>user. I think we could coerce those in some predefined selectors in the
>final CSS:
>
>
I think that these aliases are really nice to have because it is a quick
hook for a person to change the colors of the entire application.
If the skinner doesn't like this hook, then he can use the inhibit
feature to inhibit these properties.
The question then is how often will the skinners inhibit everything. If
inhibit is used for more than 50% of the selectors, it makes automatic
inheritance quite obsolete.
Another compromise I see would be to make it so that simple skin does not
include aliases in any pseudo-element selector, or don't use aliases at
all, that is :
af|messages {
// rule ref allowed in simple skin
}
af|messages:body {
// rule ref not allowed in simple skin
}
This would ensure that most components get easily skinned without having
to inhibit prety much everything since you often want to change the look
of the whole component. Also, if simple skin don't use any alias, it will
really be simple, once inheriting from a different skin than simple is
implemented, nothing would prevent Trinidad to have more than one base
skin: simple skin not using any rule ref and maybe minimal using what
simple skin currently uses. By the way, maybe those names should be
changed, I don't know if it's only in French, but here minimal often means
less than simple, not the other way around. Of course, it's only a
semantic debate here.
As a metric, we planned 10 days for the skin on our ADF Faces project. The
result was a 775 lines (including comments and blank lines) file that took
25 days to create. Comparatively, all other tasks were finished about 10%
faster than planned. Of course, that's only one project and one cannot
generalize from it. Furthermore, inbithit was not supported at this time
either. That being said, I believe there's still some teachings to get out
of it.
>AFDefaultFont:alias --> *
>
>AFDefaultFont:alias --> h1 *
>AFDefaultFont:alias --> h2 *
>AFDefaultFont:alias --> h3 *
>AFDefaultFont:alias --> h4 *
>or
>AFDefaultFont:alias --> .panelHeaderClass *
>
>and
>
>AFLinkForeground:alias --> a:link
>or
>AFLinkForeground:alias --> *:link
>
>That way they would be applied to everything, but at a lower priority
>inside the cascading style chain, thus making easier to override the
style
>on child elements using the skin rather than sometimes being forced to
use
>inlineStyle.
>
>
The skinner could add style definitions like this:
* {font-family: Ariel}
h1 * {font-family:Ariel}
then he could inhibit the AFDefaultFont:alias's properties to get this
effect.
We don't map our alias style definitions to html constructs like you are
suggesting. They are simply
mechanisms to include in other styles to make it quicker to make changes
to multiple components.
That would work. However, using such construct would force the skinner to
be more apt at CSS than only knowing skin selectors.
I think documenting what skin style keys include would be useful to a
skinner.
Extremely, that alone could greatly improves user's experience with skins.
Regards,
Simon Lessard
Fujitsu Consulting
Re: Follow-up on skin issues
Posted by Jeanne Waldman <je...@oracle.com>.
Simon_Lessard@DMR.CA wrote:
>Hello,
>
>I redid the test with the menuList, you were right about the
>menuList::selected, it's just ignored completely. The bold weight I was
>seeing on the selected field was coming from .AFDefaultBoldFont:alias,
>sorry about that.
>
>However, I had other comments about the skin from users. Another example
>of badly answering skin is with the messages component. If the user
>specifies the following selectors, he'll assume that he'll get a message
>zone using a green background:
>
>af|messages
>{
> background-color: green;
>}
>
>af|messages::header
>{
> padding-left: 20px;
>}
>
>af|messages::body
>{
> border-top-style: solid;
> border-top-color: #ffffff;
> border-top-width: 3px;
> width: 100%;
>}
>
>Sadly, the resulting background will be gray because
>.AFLightAccentBackground:alias will be used because simple skin import it
>on ::body selector. Of course, one could inhibit ; background-color on
>body, but again the user will have to execute the page first to figure it
>out.
>
>Also, I would like to open a discussion on the pertinence of applying
>.AFDefaultFont:alias and .AFLinkForeground:alias prety much everywhere in
>the page. I think those two alone cause the most troubles for the end
>user. I think we could coerce those in some predefined selectors in the
>final CSS:
>
>
I think that these aliases are really nice to have because it is a quick
hook for a person to change the colors of the entire application.
If the skinner doesn't like this hook, then he can use the inhibit
feature to inhibit these properties.
>AFDefaultFont:alias --> *
>
>AFDefaultFont:alias --> h1 *
>AFDefaultFont:alias --> h2 *
>AFDefaultFont:alias --> h3 *
>AFDefaultFont:alias --> h4 *
>or
>AFDefaultFont:alias --> .panelHeaderClass *
>
>and
>
>AFLinkForeground:alias --> a:link
>or
>AFLinkForeground:alias --> *:link
>
>That way they would be applied to everything, but at a lower priority
>inside the cascading style chain, thus making easier to override the style
>on child elements using the skin rather than sometimes being forced to use
>inlineStyle.
>
>
The skinner could add style definitions like this:
* {font-family: Ariel}
h1 * {font-family:Ariel}
then he could inhibit the AFDefaultFont:alias's properties to get this
effect.
We don't map our alias style definitions to html constructs like you are
suggesting. They are simply
mechanisms to include in other styles to make it quicker to make changes
to multiple components.
I think documenting what skin style keys include would be useful to a
skinner.
>That sounds acceptale?
>
>
We could document how the skinner can inhibit these global selectors,
once we add the inhibit feature.
>
>Regards,
>
>Simon Lessard
>Fujitsu Consulting
>
>