myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marius Petoi <marius.pe...@codebeat.ro>
Subject Re: [Trinidad] skinning keys for 'icons'
Date Thu, 22 Jul 2010 15:04:38 GMT
Hi Jeanne,

I renamed the styles and added the patch to the ticket:
https://issues.apache.org/jira/browse/TRINIDAD-1860. The styles were not
used anywhere else in the casablanca skin or in Trinidad, so this shouldn't
have such a big impact.

Regards,
Marius

On Thu, Jul 22, 2010 at 12:20 AM, Jeanne Waldman
<jeanne.waldman@oracle.com>wrote:

>  Yes, relying on a naming convention and then allowing them to easily break
> it without any warning was not so smart.
>
> If you can change it, that would be great since the code goes through extra
> cycles trying to figure this out, so if nothing else it will slightly help
> performance. If you think people have extended the skin, then you will break
> them if you change it. That's the issue.
>
> Jeanne
>
>
>
> Marius Petoi wrote, On 7/21/2010 1:44 AM PT:
>
> Hi Jeanne,
>
> My colleague that created the Casablanca skin didn't know about the icon
> and style naming convention. Should I change the names of the selectors? Or
> should I wait until you decide whether you create a new @icon rule.
>
> Regards,
> Marius
>
> On Wed, Jul 21, 2010 at 4:52 AM, Jeanne Waldman <jeanne.waldman@oracle.com
> > wrote:
>
>> Hi,
>>
>> I started working on some skinning tasks regarding Icon Objects.
>> https://issues.apache.org/jira/browse/TRINIDAD-636 and
>> https://issues.apache.org/jira/browse/TRINIDAD-17
>> One is to have -tr-rule-ref work for icons. The other is to be able to
>> inherit properties from a base skin for icons.
>>
>> While looking at these issues, I found that some of our skinning keys end
>> in "-icon" when they should have ended in "-icon-style". The reason is the
>> parser code looks at -icon and says it is an Icon Object, and it creates an
>> Icon Object. If the 'content' property is not there, it also creates a
>> StyleNode. StyleNodes get transformed and written to the generated CSS file.
>> Icon Objects do not.
>>
>> What should have happened is that anything that ended with -icon was an
>> Icon Object, and if there was no 'content' we output a warning, but do not
>> create a StyleNode.
>>
>> This way people wouldn't have been able to create selectors with names
>> that ended in '-icon' and really weren't icons.
>>
>> This makes it harder to solve those JIRA issues.
>>
>> The point of this email is twofold.
>>
>> *One*:* remember, icons end in '-icon' or 'Icon:alias' whereas styles
>> that you want generated in the CSS should not - they should say
>> '-icon-style' or 'IconStyle:alias'.*
>>
>> *Two*: *For backward compatibility, I don't think I can change the
>> selectors with wrong names because they are public. What do people think?
>> *
>>
>> They are:
>>
>> af|panelPopup::close-icon
>> and
>> af|dialog::close-icon
>>
>> The new casablanca skin creates its own selectors, and it uses Icon, when
>> it meant IconStyle. These are not documented anywhere, but I suppose someone
>> could have created a skin from them either way. They are:
>>
>> /* Dialog window component
>> ------------------------------------------------------------------------------------------
>> */
>>
>> .CBDialogHeadCloseIcon {
>>     -tr-rule-ref: selector(".CBDialogHeadCloseIcon:alias");
>> }
>> .CBDialogHeadCloseIconHover {
>>     -tr-rule-ref: selector(".CBDialogHeadCloseIconHover:alias");
>> }
>>
>> af|dialog::close-icon {
>>     -tr-rule-ref: selector(".CBDialogHeadCloseIcon");
>> }
>>
>> --
>> /* Table icons */
>> */* We don't use ":alias" sufix because didn't work, probably its a bug
>> */*
>> .CBTableSelectAllIcon{
>>     -tr-rule-ref: selector(".CBIconLook:alias");
>>     -tr-rule-ref: selector(".CBIconSelectAll:alias");
>> }
>> .CBTableSelectAllIconHover {
>>     -tr-rule-ref: selector(".CBIconLookHover:alias");
>>     -tr-rule-ref: selector(".CBIconSelectAll:alias");
>> }
>> .CBTableSelectNoneIcon {
>>     -tr-rule-ref: selector(".CBIconLook:alias");
>>     -tr-rule-ref: selector(".CBIconSelectNone:alias");
>> }
>> .CBTableSelectNoneIconHover {
>>     -tr-rule-ref: selector(".CBIconLookHover:alias");
>>     -tr-rule-ref: selector(".CBIconSelectNone:alias");
>> }
>> .CBTableSelectExpandAllIcon {
>>     -tr-rule-ref: selector(".CBIconLook:alias");
>>     -tr-rule-ref: selector(".CBIconExpandAll:alias");
>> }
>> .CBTableSelectExpandAllIconHover {
>>     -tr-rule-ref: selector(".CBIconLookHover:alias");
>>     -tr-rule-ref: selector(".CBIconExpandAll:alias");
>> }
>> .CBTableSelectCollapseAllIcon {
>>     -tr-rule-ref: selector(".CBIconLook:alias");
>>     -tr-rule-ref: selector(".CBIconCollapseAll:alias");
>> }
>> .CBTableSelectCollapseAllIconHover {
>>     -tr-rule-ref: selector(".CBIconLookHover:alias");
>>     -tr-rule-ref: selector(".CBIconCollapseAll:alias");
>> }
>>
>> --
>> The person that created these keys thought it was a bug that :alias didn't
>> work, when really it is a bug that ending the selector name with 'Icon' did
>> work! :)
>>
>> I'm wondering if anyone has thoughts on this.
>>
>> I'm thinking I can add a warning if I know a selector ends in Icon but
>> doesn't have 'content'.
>>
>> When I implement -tr-rule-ref, the only thing I can think of is to resolve
>> all the includes to see if anywhere there is a 'content', and if so, create
>> an Icon, if not create a StyleNode, but this will make it more complicated.
>>
>> If I had to do all this over again, I'd make an @rule for icons or have
>> them be in a separate file, rather than relying on a naming convention which
>> obviously did not work. In fact, I wonder if I can create an @icon rule now.
>> Hmmm.
>>
>> - Jeanne
>>
>
>

Mime
View raw message