I wasn't really suggesting anything.
By the way, in case you didn't notice, Adam made a change yesterday so
that ALL pseudo-classes get transformed to .p_AF*, except for the css-2
pseudo-classes, which pass through.
This simple change buys us a lot. It satisfies my immediate need for a
pseudo-class solution, and it heads us in the right direction, in that
the pseudo-class api doesn't have to change when we implement the full
solution that gives the component developer's more flexibility.
Thanks, Adam!
- Jeanne
Simon Lessard wrote:
> 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
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,
>> 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,
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.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
