From adffaces-dev-return-393-apmail-incubator-adffaces-dev-archive=incubator.apache.org@incubator.apache.org Mon Jul 10 21:59:53 2006 Return-Path: Delivered-To: apmail-incubator-adffaces-dev-archive@locus.apache.org Received: (qmail 5887 invoked from network); 10 Jul 2006 21:59:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Jul 2006 21:59:53 -0000 Received: (qmail 81753 invoked by uid 500); 10 Jul 2006 21:59:52 -0000 Delivered-To: apmail-incubator-adffaces-dev-archive@incubator.apache.org Received: (qmail 81730 invoked by uid 500); 10 Jul 2006 21:59:52 -0000 Mailing-List: contact adffaces-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-dev@incubator.apache.org Delivered-To: mailing list adffaces-dev@incubator.apache.org Received: (qmail 81720 invoked by uid 99); 10 Jul 2006 21:59:52 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Jul 2006 14:59:52 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [141.146.126.228] (HELO agminet01.oracle.com) (141.146.126.228) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Jul 2006 14:59:51 -0700 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k6ALxUJZ019613 for ; Mon, 10 Jul 2006 16:59:30 -0500 Received: from [127.0.0.1] (jwaldman-pc.us.oracle.com [130.35.101.32]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k6ALxTYe027399 for ; Mon, 10 Jul 2006 15:59:29 -0600 Message-ID: <44B2CDB4.4020708@oracle.com> Date: Mon, 10 Jul 2006 14:59:16 -0700 From: Jeanne Waldman User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: adffaces-dev@incubator.apache.org Subject: Re: Follow-up on skin issues References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 >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 > > >