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 <[email protected]>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 <[email protected] > > 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 >> > >
