incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: Follow-up on skin issues
Date Tue, 11 Jul 2006 16:17:29 GMT
Hey, folks - as items come out of this discussion (like a doc generator
for skining, etc.), could you file them in the issue tracker?  We don't
want these ideas getting lost!

-- Adam


On 7/11/06, Simon_Lessard@dmr.ca <Simon_Lessard@dmr.ca> wrote:
>
> 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