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
