-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, August 21, 2006 2:43 AM
To: [email protected]
Subject: Re: ADFFACES-49 inputText::content:required or
inputText:required::content
> We use both syntaxes, and they mean different things.
> For example:
> af|train::stop:disabled (when this train's stop is disabled, then style
> the stop like this)
> af|train:disabled::stop (when the entire train is disabled, style all
> the stops like this)
Agreed.
> Let's say I have this: <span class="myText">Hello!</span> and this css:
> .myText {color: black}
> .myText:hover {color:red}
> Does this work? (not in my tests)
It works in Firefox, not IE, as usual. W3C specifies that :hover should
work with everything, but it's not like all browsers will support
everything W3C says anytime soon. Maybe we should intercept all
pseudo-classes, if it can be resolved on Java side (like :disabled), we
resolve it there and it never pass through so we prevent all bad support
from the browser. For states that cannot be resolved in Java, we could ask
the Agent if it supports the specified pseudo-class for the generated
element (link:hover works in IE, but not on anything else). If the agent
supports it, we let the class pass through to the generated CSS file, if
the agent does not, then we could add some JS code to emulate it.
The main problem I have the "per component" option is the potential
performance overhaul it represents as well as the increased component
development complexity (since you have to put more information in the
metadata).
The prefix is ok, but I find it a bit counter intuitive since the user has
to know which states will be handled by browser and which are managed by
Trinidad. I would prefer to hide that kind of low level implementation
details to skinners.
On a side note that could lead to a new post, what should we do with
icons? Currently the engine considers a selector an icon one if it ends
with -icon. This lead to some strange selectors sometimes like
-icon-style-class simply to prevent the parser to interpret it as an icon.
Maybe we should add something like :::icon, ::tri-icon or --icon? That way
there will be no ambiguity left.
Regards
¬ Simon
Jeanne Waldman <[EMAIL PROTECTED]>
2006-08-18 18:27
Please respond to adffaces-dev
To: [email protected]
cc:
Subject: Re: ADFFACES-49 inputText::content:required or
inputText:required::content
see inline for some random thoughts. :) I'm glad you brought this up,
because I need to come up with a solution soon for our internal project
that we are working on so that our developers can write their renderers
correctly.
[EMAIL PROTECTED] wrote:
>Hello all,
>
>I raised that issue a while back, but now it's a bit more important since
>I'm trying to finalize ADFFACES-49 issue. What selector synthax do you
>prefer for states:
>1.1. <component>::<subPart>:<state>
>1.2. <component>:<state>::<subPart>.
>
>
We use both syntaxes, and they mean different things.
1.1 means this: The subPart of the component is in this state.
For example:
af|train::stop:disabled (when this train's stop is disabled, then style
the stop like this)
af|train:disabled::stop (when the entire train is disabled, style all
the stops like this)
1.2 means this: The component is in this state, and this is the subpart.
For example:
af|inputText:disabled::content (when the af:inputText disabled="true",
then style the content piece like this)
>I prefer the former and it's easier to implement. However, we already
have
>some :disabled that use the latter synthax.
>
>Secondly, there's also the issue raised by Jeanne, how should we manage
>which states are intercepted and which should pass through and be copied
>in the final CSS:
>2.1. Use a component specific list, so that :disabled could pass through
>for some components but get intercepted for some others? If that solution
>is selected, how/where should we configure that list, in the
>faces-config's metadata?
>
>
I like this one the best because let's say I use :disabled and I
intercept it and do some funky things with it. Then let's say I decide
that the css spec deals
with :disabled perfectly fine, and I don't need to intercept it.
Also, let's say :hover and :active work great on some dom elements, but
do they work for everything?
Let's say I have this: <span class="myText">Hello!</span> and this css:
.myText {color: black}
.myText:hover {color:red}
Does this work? (not in my tests)
But what if this represents a component. I might want them to be able to
specify .myText:hover and have it work even if the built-in browser
support wasn't there.
So I would want
af|myComponent:hover to work.
I'd render this
<span class="af_myComponent p_AFHover">Hello!</span>
when they are hovering over my span.
>2.2. Use a list of pseudo-classes passing through for all components.
Such
>list would have to be based on W3C, but as Jeanne observed, such list
>would break our :disabled that we're intercepting currently and could
lead
>to som.e problems if more pseudo-classes are added in future version of
>CSS.
>
>
Yes, I'd have to change the name of :disabled. But so far that is the
only css valid pseudo-class that I use to date.
We have others like :hover (see above... if we don't want this to pass
through, we'll need to change it to something else).
>2.3. Use a static list of pseudo-classes to intercept used by all
>components? If so, where should we place it? This solution probably has
>the same flaws as 2.2 if a new pseudo-classes i nthe CSS specification
>matches a name defined in the intercept list.
>2.4. Use a prefix for intercepted pseudo-classes like the -ora- used for
>properties?
>
>
I like this second best. If we did this, then I'd suggest that we also
prefix the pseudo-elements.
The problem is, taking my :hover example, some components might be
rendered such that the browser
automatically works with :hover on the generated css, but others don't,
so those that don't have to have
:-tri-hover ?
>
>My votes are:
>+1 for 1.1
>+1 for 2.2, but I would not place states resolvable during rendering in
>that list, so that disabled is still intercepted.
>
>
