Ok, Then if those selectors are ok for you as well Pavitra I'll make the changes to -outer and and -icon-cell tonight and upload the patch as well as a test skin I used.
Regards, ~ Simon On 8/29/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote:
yep, it all makes sense. I can see where you'd want to use a ::content. That would make sense. We don't do this yet in any of our skinning keys, so I am fine with the -content, since we do that all over the place. :) - Jeanne Simon Lessard wrote: > Oups, comments below > > On 8/29/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote: > >> >> one question below >> >> Simon Lessard wrote: >> >> > Hello Pavitra, >> > >> > I had to do about the same changes on my side. Here's my list of >> selector >> > and the rules I used: >> > >> > - af|train::stop combinable with :selected, :disabled, :completed >> (will >> > probably become p_AFVisited) and :unvisited. You can append :readOnly >> > at the >> > end of the result. So af|train::stop:unvisited:readOnly is valid >> > - af|train::link >> > - af|train::join combinable with :disabled, :completed, :unvisited and >> > :outer (:outer is used to add joins outside the edge of the train. I >> > don't >> > think many will use it, but it cost nothing and add more customization >> > possibilities) >> >> Is :outer a state? It sounds to me like it should be >> af|train::join-outer > > > > yes, it could be ::join-outer, was made a state only to fit the other > join > selectors, but it does make more sense to use -outer for that one. > > > Does that make more sense now? > > > Regards, > > ~ Simon > >> - af|train::overflow-start combinable with :disabled and :readOnly >> > - af|train::overflow-end combinable with :disabled, :unvisited and >> > :readOnly >> > >> > I have the following valid suffixes: (I could not use ::content for >> > example >> > since double :: is now prevented from Adam's change to prevent some >> > strange >> > behavior it seem) >> >> I don't think two pseudo-elements make sense, does it? I suppose you >> could have >> a piece of a piece. Adam prevented it because there were bugs in it. I >> can't recall what the bugs were. > > > > I was seeing them more as sub-elements, like ::stop::content (content > of the > stop) > >> -content (for example, the following is valid: af|train::stop-content >> > and >> > af|train::stop:selected-content. This selector refers to the link cell >> fo >> > the train) >> >> What does a :selected-content 'state' mean? >> How is it different than af|train::stop-content:selected? > > > > My bad there, af|train::stop-content:selected is actually what I use. > Even > if a better selector would have been af|train::stop:selected::content > imho. > >> -icon-block (as above but refers to the icon cell) >> >> Could you say -icon-cell? We use 'cell' quite a bit in our skinning >> selectors. > > > > Yes I could, I was using block only because it was in Pavitra document at > first. > >> >> > The icons follow the same rule. >> > >> > On 8/28/06, Pavitra Subramaniam <[EMAIL PROTECTED]> >> wrote: >> > >> >> >> >> Hello Simon, >> >> >> >> I have also almost completed implementing the TrainRenderer using the >> >> new >> >> skin selectors. It's great to know you are done as well. If you >> plan to >> >> check in the train renderer code anytime soon, can we agree on the >> >> common >> >> list of skin selectors, so that I can reuse them for my work >> >> internally at >> >> Oracle? I had to make the following changes and wanted to give you an >> >> update. >> >> >> >> 1. I had to introduce a new state called "read-only". This is >> different >> >> from "disabled" state, like I explained in a previous email. >> >> >> >> 2. I removed some redundant skin hooks - I can send you the updated >> list >> >> of selectors I am using. I also couldn't get the "pass-through >> states" >> >> :visited, :active and :unvisited to work, just as you. So I have >> >> temporarily >> >> defined selectors like Jeanne suggested (using p_AFVisited, >> >> p_AFUnvisited >> >> etc. and renamed :active to :selected). >> >> >> >> 3. Finally I have simplified the rules for determining the state of >> >> joins. >> >> I figured it would be much simpler if we did the following. The join >> >> to the >> >> left of a stop, is 'always in the same state as the stop' (Overflows >> >> could >> >> also follow the same rules as stops). So for instance for a train >> like >> >> >> >> V ----- VR ----- UV ----- A ----- D ----- UVR ----- V >> >> vr uv v d uvr v >> >> >> >> >> >> NOTE: The only exception, is the join to the left of an active >> stop is >> >> visited. Also, UVR and VR are stops that are in 2 states >> >> simulataneously - >> >> 'visited & read-only' and 'unvisited & read-only'. Read-only implies >> the >> >> stop cannot be reached (and hence not clickable) and is dictated >> by the >> >> 'readOnly' property on the component commandNavigationItem. >> >> >> >> Please let me know if the above is ok. >> >> >> >> >> >> Thanks >> >> - Pavitra >> >> >> >> >> >> > -----Original Message----- >> >> > From: Simon Lessard [mailto:[EMAIL PROTECTED] >> >> > Sent: Monday, August 28, 2006 11:43 AM >> >> > To: [email protected] >> >> > Subject: Re: Train selectors >> >> > >> >> > Hmmm you mean somthing like af|train::stop.p_AFVisited? >> >> > >> >> > On 8/28/06, Jeanne Waldman <[EMAIL PROTECTED]> wrote: >> >> > > >> >> > > I was thinking :selected for :active. :selected could be used for >> >> > > other components, too. >> >> > > For :visited/:unvisited, I can't think of a better name. >> >> > I'm thinking >> >> > > that we should use .p_AFVisited, .P_AFUnvisited until we have the >> >> > > pseudo-class support in. These wouldn't in a public api >> >> > format, though. >> >> > > >> >> > > - Jeanne >> >> > > >> >> > > [EMAIL PROTECTED] wrote: >> >> > > >> >> > > >Hello, >> >> > > > >> >> > > >I thought about the following name changes for the selectors: >> >> > > > >> >> > > >:active --> :current or :selected >> >> > > >:visited/:unvisited --> :completed/:uncompleted or :seen/:unseen >> >> > > > >> >> > > > >> >> > > >Do you have any other idea/preference? >> >> > > > >> >> > > > >> >> > > >Regards, >> >> > > > >> >> > > >~ Simon >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > >"Simon Lessard" <[EMAIL PROTECTED]> >> >> > > >2006-08-25 22:49 >> >> > > >Please respond to adffaces-dev >> >> > > > >> >> > > > To: "Trinidad - Dev" >> >> > <[email protected]> >> >> > > > cc: >> >> > > > Subject: Train selectors >> >> > > > >> >> > > > >> >> > > >Yes... again... >> >> > > > >> >> > > >I made a new renderer and it work quite well, but I had to use >> >> > > >:ora-visited and :ora-active for some selectors because those >> are >> >> > > >"pass through" >> >> > > >values. >> >> > > >Anyone have better name suggestion while we implement state >> >> > > >interception on a per component basis? >> >> > > > >> >> > > > >> >> > > >Regards, >> >> > > > >> >> > > >~ Simon >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> >> >> >> > >> >> >
