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
