My opinion is that if you want the same pseudo-class to pass through
when in one state and not when in the other state, then I would just not
have it pass through in either case, and handle it yourself.
- Jeanne
Simon Lessard wrote:
> Hello Pavitra,
>
> My solution would work with it as it is binary, the pseudo-class
> either get
> intercepted or pass through, independently of the enclosing element. For
> :hover case, it would always go through for Firefox, except if the
> component
> said he wanted to intercept that pseudo-class and for IE it would
> always get
> intercepted, even on <a /> element since the JavaScript required to
> emulate
> a pseudo-class should always be the same, independently of the element.
>
> So in your case, it would not work. However, I wonder why you would
> want to
> intercept it in a case and not in the other as it only remove
flexibility
> for the end user imho. Can you explain the reason a bit more please?
>
>
> Regards,
>
> ~ Simon
>
> On 8/23/06, Pavitra Subramaniam <[EMAIL PROTECTED]> wrote:
>
>>
>> Hello Jeanne and Simon,
>>
>> There could be cases where intercepted states for a component or it's
>> sub-part need to be considered together rather than individually. Or
>> in some
>> case it might be too early for even the renderer to provide a valid
>> interceptor-state list at init time. The best time may be at
>> rendering time.
>>
>> For instance, let's assume that the component sub-part "af|train::stop"
>> can be in the following states :visited and :selected states.
>>
>> At runtime if the stop is selected, it may be rendered as a span and
>> as an
>> anchor, <a >, if it was visited before (and hence clickable). Both
these
>> elements may want to support the :hover pseudo-class.
>>
>> If I wanted the :hover to pass through if it's for selected stop (for
>> the
>> <span>) and intercept :hover if it's for a stop that is visited (link),
>> would the proposed solution work?
>>
>>
>> Thanks
>> - Pavitra
>>
>> -----Original Message-----
>> From: Simon Lessard [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, August 23, 2006 6:28 AM
>> To: [email protected]
>> Subject: Re: ADFFACES-49 inputText::content:required or
>> inputText:required::content
>>
>> Hello Jeanne,
>>
>> Yes I'm aware that states can go on the component's sub-part, but are
>> you
>> suggesting that we extends the concept to be flexible enough to allow
>> thecomponent to intercept a given state on the root element but not
>> on the
>> sub-part? e.g. inputText would intercept :disabled when placed on
>> af|inputText but not on af|inputText::content? That's some complexity
>> af|but
>> it's doable I guess.
>>
>>
>> Regards,
>>
>> ~Simon
>>
>> On 8/22/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>> >
>> > I agree that only the renderers should know what states they want to
>> > intercept. I was thinking we add this information in the renderer
.xml
>> > file and then when we build our classes, we can put this information
>> > somewhere -- not sure where.
>> >
>> > I'm sure you realize this, but just in case... the states do not have
>> > to go on the root dom element, they can go on sub-root elements, like
>> > af|train::stop:disabled.
>> >
>> > Simon Lessard wrote:
>> >
>> > > Hmmm, I'm leaning toward the per component basis option more and
>> more.
>> > > However, I hate static lists and additional config files are not
all
>> > that
>> > > great. I see a possibility though. Maybe it will work, but I did
not
>> > > explore that area much yet so I might say something stupid.
>> > > Currently it seem to me that skins are linked to the renderkit. So,
>> > > how feasible would it be to create a SkinRenderKitFactory that
>> > > would, before giving away any renderer, would populate a
>> > > Map<component, list<state>> be interrogating all renderers in the
>> > > kit. That way, when StyleSheetRenderer would do its work, we would
>> > > be sure that the list is populated. Also, with that solution, only
>> > > the renderers would have to know what states they want to
intercept.
>> > > This also fix the synchronization issue, changing the kit or the
>> > > renderer would automatically update the interception list. We would
>> > > have to create a
>> > new
>> > > BaseRenderer in the API however. I see two additional methods
needed
>> > > for such renderers:
>> > >
>> > > public String getComponentName() // or I guess getRootStyleClass
>> > > would work just as well public List<String> getInterceptedStates();
>> > > // Returning the list of states to intercept.
>> > >
>> > >
>> > > Makes sense?
>> > >
>> > > ~ Simon
>> > >
>> > > On 8/21/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
>> > >
>> > >>
>> > >> More comments inline.
>> > >> Which way are you leaning?
>> > >>
>> > >> - Jeanne
>> > >>
>> > >> Simon Lessard wrote:
>> > >>
>> > >> > Hello Jeanne,
>> > >> >
>> > >> > Thanks for the complete answer.
>> > >> >
>> > >> > On 8/21/06, Jeanne Waldman <[EMAIL PROTECTED] > wrote:
>> > >> >
>> > >> >>
>> > >> >> Hi Simon,
>> > >> >> Thanks for the email.
>> > >> >>
>> > >> >> [EMAIL PROTECTED] wrote:
>> > >> >>
>> > >> >> >>We use both syntaxes, and they mean different things.
>> > >> >> >>For example:
>> > >> >> >>af|train::stop:disabled (when this train's stop is disabled,
>> > >> >> >>af|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.
>> > >> >> >
>> > >> >> >
>> > >> >> We generate the css file before we render the components, so
>> > >> >> when
>> > you
>> > >> >> say we should intercept all pseudo-classes and if it can be
>> > >> resolved on
>> > >> >> the Java side, we should resolve it. But how would we know at
>> > >> >> this
>> > >> point
>> > >> >> where we are going to render the pseudo-class? that
af|foo:hover
>> > will
>> > >> be
>> > >> >> generated on a link? Maybe af|foo:hover is on a <span>, but
>> > >> >> af|foo::step:hover is on the link. (we would know if we kept
the
>> > >> >> skinning-key -> pseudo-class to resolve map). Or do you mean
>> > >> literally
>> > >> >> that if we can resolve it on the Java side -- even if the
>> > >> >> browser
>> > can
>> > >> as
>> > >> >> well -- we go ahead and do that?
>> > >> >
>> > >> >
>> > >> >
>> > >> > I mean litterally that we make a list of pseudo-classes that we
>> > >> > know we can always resolve during rendering, like :disabled, and
>> > >> > always intercept it. In a sense it would be a way to cover
>> > >> > browsers' lack of support for
>> > those
>> > >> > pseudo-classes.
>> > >> >
>> > >> > In the case of :hover, do we pass that through for IE or not?
>> > >> > Let's
>> > >> say
>> > >> >
>> > >> >> we don't pass it through for IE. Then we'll need some code that
>> > >> >> gets :hover and says, oh, we are on IE, so don't pass this
>> > >> >> through but instead do some onmouseover + css magic. This seems
>> > >> >> like it could
>> > get
>> > >> >> messy fast.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Fair point, the renderers would have to check if there's a
>> > >> > selector
>> > >> using
>> > >> > :hover defined in the current skin and add some JS, it's messy
>> > indeed.
>> > >> >
>> > >> >> 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).
>> > >> >> >
>> > >> >> >
>> > >> >> I don't think of this as a performance hit, since this will
>> > >> >> happen
>> > at
>> > >> >> the css generation time, not with every renderer. And we cache
>> > >> >> the generated css file.
>> > >> >> It would be like the map I have now in FileSystemStyleCache.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Small question here. When is the CSS generated exactly? Is it at
>> > >> > startup or at the first request for a given skin family? If it
is
>> > >> > during
>> > startup,
>> > >> > the
>> > >> > performance hit is indeed a non issue.
>> > >>
>> > >> rendered in StyleSheetRenderer. We get it out of the cache if it
is
>> > >> there, otherwise we generate it.
>> > >>
>> > >> >
>> > >> > However, we would need to keep the renderer and this map in
sync.
>> > >> For my
>> > >> >
>> > >> >> renderer 'foo', I know that I want to handle 'hover' myself, so
>> > >> >> I
>> > put
>> > >> >> the hover -> p_AFHover in the map that will be consulted when
we
>> > >> >> generate the css file. af|foo:hover does not pass through. All
>> > >> >> other :hover passes through. I don't think this is that
>> > >> >> terrible. I like
>> > >> this
>> > >> >> better than the prefix, because if, down the line, we decide
>> > >> >> that we
>> > >> can
>> > >> >> pass through the pseudo-class, the user's skin will not have to
>> > >> change,
>> > >> >> but our code will get simpler.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Not that bad, but I kind of dislike hard coded lists as
component
>> > >> > developers won't be able to use the skinning feature without
>> > >> > giving it to
>> > >> Trinidad
>> > >> > project since they will have to hack Trinidad's jar file to add
>> > >> > their
>> > >> own
>> > >> > states to the map. If that way is chosen, I would rather use
>> > >> > another configuration file or some faces-config meta-data
>> > >> > entries. For now skin is not a public API, but I'm prety sure it
>> > >> > will become one at some
>> > >> point in
>> > >> > time.
>> > >>
>> > >> We definitely need to get it out of FileSystemStyleCache. No doubt
>> > about
>> > >> it.
>> > >>
>> > >> >
>> > >> >> 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.
>> > >> >> >
>> > >> >> >
>> > >> >> We would definitely document all the -tri- pseudo-classes per
>> > >> skinning
>> > >> >> key. For example:
>> > >> >> af|inputText:-tri-required, af|inputText:-tri-read-only,
>> > >> >> af|inputText:-tri-disabled. But for af|train::stop-link,
>> > >> >> we'd document that they can use :hover.
>> > >> >
>> > >> >
>> > >> >
>> > >> > It works, but it's a bit ugly imho. Furthermore, as you pointed
>> > >> > out,
>> > >> such
>> > >> > solution would force skin CSS changes if we beside to let any
>> > >> > given
>> > >> state
>> > >> > pass through in the future.
>> > >>
>> > >> true.
>> > >>
>> > >> >
>> > >> >> 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.
>> > >> >> >
>> > >> >> >
>> > >> >> I don't have a problem with saying -icon-style when what you
>> > >> >> mean is that you want to style the icon, and ending the key
with
>> > >> >> -icon
>> > >> when it
>> > >> >> means an icon.
>> > >> >
>> > >> >
>> > >> >
>> > >> > It's not that bad, true, but do we have a doc somewhere to
>> > >> > document
>> > >> this
>> > >> > kind of skinning rules? If not, should I add a wiki entry for it
>> > >> > even if the API is not public yet? Other things interesting I
see
>> > >> > are
>> > >> FileSystemCache
>> > >> > and the mandatory "af" namespace.
>> > >>
>> > >> We don't have a skinning document for Trinidad developers (as
>> > >> opposed
>> > to
>> > >> application developers using Trinidad).
>> > >> Starting a wiki would be great. I can populate it with some
>> > >> information I have.
>> > >>
>> > >> Yeah, the namespace is purely to make it so that the skinner knows
>> > there
>> > >> are Trinidad keys.
>> > >> We need to change these to tr for one thing. The code might be a
>> > >> little bit hardcoded to use 'af', so that will need to change.
>> > >> We don't honor the actual namespace in that you can't add
>> > >> @namespace to the top of the css file and then be able to use
>> > >> whatever prefix you want. That was very low priority when I was
>> > >> doing the skinning, and I'm not so sure we'd want to do that
>> > >> anyway, becuase what would we do, substitute the namespace for the
>> > >> prefix? Then our css would be huge. :) Maybe some day the browsers
>> > >> would work with the @namespace, and when that happens we can
render
>> > >> it out to our css.
>> > >>
>> > >> >
>> > >> > - Jeanne
>> > >> >
>> > >> >>
>> > >> >> >
>> > >> >> >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,
>> > >> >> >af|then
>> > >> style
>> > >> >> >the stop like this)
>> > >> >> >af|train:disabled::stop (when the entire train is disabled,
>> > >> >> >af|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.
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >>
>> > >> >>
>> > >> >
>> > >>
>> > >>
>> > >
>> >
>> >
>>
>>
>>
