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
>

Reply via email to