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
[EMAIL PROTECTED] wrote:
Sun Certified Programmer for Java 2 Platform 1.4
Jeanne Waldman <[EMAIL PROTECTED]>
2006-07-10 15:47
Please respond to adffaces-dev
To: adffaces-dev@incubator.apache.org
cc:
Subject: Re: Follow-up on skin issues
[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.
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
