[EMAIL PROTECTED] 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
