Hello Jeanne,
Thank for that complete answer.
For the state issue, my vote would go to prefix rather than configuration
file to make it easier for component developers. Also, prefix will prevent
name clashes, like :disabled.
> I've tested in the past swapping the style classes in the html file, and
> that has no effect. It is the order they are defined in the css file,
> and I don't want to attempt to keep the css file ordered; that would be
> a maintenance black hole.
Awww... Good to know, then setting the class on the label element will be
the only way I guess.
> Can you submit an issue for this bug?
Sure thing.
Regards,
Simon Lessard
Fujitsu Consulting
Jeanne Waldman <[EMAIL PROTECTED]>
2006-07-31 13:15
Please respond to adffaces-dev
To: [email protected]
cc:
Subject: Re: Some more skinning issues
Hey Simon...
[EMAIL PROTECTED] wrote:
>Heya!
>
>Another day, another issue. I just helped one of my teammate debugging
the
>af|inputText:required::content he's trying to implements and I found out
>some issues.
>
>1) af|inputText:required::content got transformed to
>af_inputText:required_content instead of af_inputText_required_content
>because I assume single colon is kept to allow the skin to use CSS
>pseudo-classes. So I decided to test the various :disabled::label
>selectors already existing to find out those are working correctly. So I
>assume there's a list of "allowed" component states hidden somewhere.
>Anyone knows where that is? Also, shouldn't it be the other way around to
>make it simpler for skin users? That is keep the single colon in the
>resulting selector only if the pseudo-clas is a known CSS3 class as
>specified by W3C. This way, it will be easier for component developers to
>add new component with custom states supporting selectors using the
:state
>synthax.
>
>
Yes, there is a list in FileSystemStyleCache. When I finish up some
projects that are high priority for me now, I was going to open up this
topic, because we do need a way to make the pseudo-classes work without
maintaining a list like this.
One proposal could be what you suggest, but then we wouldn't be able to
use disabled, cuz that is a css pseudo-class, and we'd have to keep this
list up to date, and then what happens if it wasn't in the list, and we
use it automatically, then the css3 proposal changes and it gets added
to the list?
Another proposal is to have a list, but not in FileSystemStyleCache,
maybe somewhere else, like in the Skin, or a configuration file??, where
we keep track of the component and its pseudo-classes that do not get
passed through to the css file. So, if it is a processTrain component,
it might not want :hover to pass through, but if it is some other
component, it might want it to pass through.
Another proposal is to add a prefix to the pseudo-classes, like
-tri-disabled, and we know NOT to pass these through, but to convert
them to a styleclass.
>2) If you use a disabled inputText inside a panelForm and override the
>af|inputText:disabled::label selector with color property set to red, it
>won't have any effect because the style class applied to the cell
>containing the label will be set to "af|inputText:disabled::label
>af|panelForm::label-cell", giving priority to af|panelFoorm::label-cell
>that set color to black. I think the style classes should be either
>inverted so af|inputText:disabled::label get priority or
>af|inputText:disabled::label should be placed on the <label> element
>instead of the cell itself.
>
>
good catch.
I've tested in the past swapping the style classes in the html file, and
that has no effect. It is the order they are defined in the css file,
and I don't want to attempt to keep the css file ordered; that would be
a maintenance black hole.
Can you submit an issue for this bug?
Thanks,
Jeanne
>
>Regards,
>
>Simon Lessard
>Fujitsu Consulting
>
>
