incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon_Less...@DMR.CA
Subject Re: Follow-up on skin issues
Date Mon, 10 Jul 2006 20:18:23 GMT
Sun Certified Programmer for Java 2 Platform 1.4




Jeanne Waldman <jeanne.waldman@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message