Ok. That makes sense.
- Pavitra -----Original Message----- From: Jeanne Waldman [mailto:[EMAIL PROTECTED] Sent: Thursday, August 24, 2006 11:46 AM To: [email protected] Cc: [EMAIL PROTECTED] Subject: Re: ADFFACES-49 inputText::content:required or inputText:required::content 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 >> > >> >> >>af|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 >> > >> >> af|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. >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> >> > >> >> >> > >> > >> > >> >> > >> >> > > >> > >> > >> >> >>
