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 Tue, 11 Jul 2006 12:58:26 GMT
Hello,

An automated documentation generator would indeed be great.


Simon Lessard
Fujitsu Consulting






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