Hi Catalin,
Thanks for the email. See below for my response.
Catalin Kormos wrote:
Hi there,
I just want to say that it sounds to me like a very good ideea, having
the
same skin take care of browsers incompatibilities for example, rather
than
having different skins take care of that, with need of user intervention;
i'm working on the future skinning framework for MyFaces (at least i
hope it
will become that), which is very much inspired by the current state of
the
ADF Faces skinning. It's going to be done during the Google's SoC program
btw. Would be ok if i take some inspiration from this too? :)
A concern of mine would be about the :lang pseudo selector. Maybe this
one i
didn't get quite right, but wouldn't this interfere with the standard
usage
of the :lang pseudo selector, for styling components that renderer
their own
different "lang" attribute value, maybe on the same page? this might
not be
the case for ADF Faces components though.
I could do a couple of things for the language/locale feature:
1. parse out the :lang pseudo-class from the adf faces component
selectors in the generated css and leave the non-adf faces components
alone. The adf faces component selectors that have :lang will be written
out only if their language matches that of the request.
The adf faces components selectors might be tricky to determine.
do I look for 'af' prefix, but what if people create their own
components/selectors?
or do I keep a map (this wouldn't be good, too hard to maintain)).
2. I could keep the :lang() pseudo-class on all the selectors in the
generated css, and let the browser do the work, since we will render the
lang on the html tag. However,:lang() does not work in IE.
3. I could go with @locales{} instead, and have it work like the @agent
and @platform. This is how I'm leaning right now. Let me know what you
think.
Regards,
Catalin
