*mumble*

http://blogs.msdn.com/ie/archive/2005/07/29/445242.aspx

*mumble*

On 8/29/06, Simon Lessard <[EMAIL PROTECTED]> wrote:

Is it possible that IE is so dumb that it interprets

.af_train_join.p_AFDisabled as .af_train_join OR .p_AFDisabled rather than
the specified .af_train_join AND .p_AFDisabled?

My diagnosis makes it looks like it and if it's really the case, it might
be a problem for many or our skinning by state selectors. Anyone knows any
work around?


Regards,

~ Simon


On 8/29/06, Simon Lessard <[EMAIL PROTECTED]> wrote:
>
> Yes it would. I'll start by uploading that damned patch first though...
> And since I have a rendering issue with IE, this will take one more day...
> Damned IE... Oh and I support RTL fine already as well... There's just that
> strange bug if joins under IE...
>
> The generated CSS includes the class and this is the only class using
> that join icon...
>
> .af_train_join.p_AFUnvisited,.xc1.p_AFUnvisited 
{background-image:url('/TrinidadDemo-MenuModel-context-root/skins/train/skin_images/JoinUnvisited.gif');background-repeat:repeat-x}
>
>
> The classes on the content cell are
>
> <td colspan="3" class="p_AFUnvisited x72 x73">
>    <!-- Start: org.apache.myfaces.trinidad.Command["_id5"] -->
>    <a onclick="submitForm('_id2',1,{source:'_id4:2:_id5'});return
> false;" href="#" class="x79">Useless step</a>
> </td>
>
> And the join get rendered for that step in a strange way... ... I hate
> IE...
>
>
> Regards,
>
> ~ Simon
>
>
>
> On 8/29/06, Pavitra Subramaniam <[EMAIL PROTECTED]> wrote:
> >
> > It may also be a good idea to update MVariableResolver.java, the test
> > code that sets up MenuModel #{pageList}, to include the visited, disabled,
> > unvisited + readOnly states. Right now the train golden file only tests for
> > selected and unvisited states.
> >
> > - Pavitra
> >
> >
> > > -----Original Message-----
> > > From: Pavitra Subramaniam [mailto: [EMAIL PROTECTED]
> > > Sent: Tuesday, August 29, 2006 2:46 PM
> > > To: [email protected]
> > > Subject: RE: TrainRenderer using the new train selectors
> > >
> > > Hello Simon, Jeanne,
> > >
> > > I have some comments on both your email exhanges. I have
> > > consolidated all the items below as it was getting hard to read.
> > >
> > >
> > > >>>>
> > > - 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
> > > >>>>
> > >
> > > - Do you think we need to support an
> > "af|train::stop:visited:readOnly"
> > > - I believe Jeanne wanted to have states that don't use camel
> > > case. So readOnly should be read-only
> > >
> > > >>>>
> > > - af|train::link
> > > >>>>
> > > - should this be ::stop-link or ::link good enough?
> > >
> > >
> > > >>>>
> > > - 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)
> > > >>>>
> > >
> > > - :join-outer pseudo element is good enough. Is this used
> > > outside the parent train icons or between the parent train
> > > icons and the overflow (or stop)?
> > > - do we still have the join-overflow? This comes between the
> > > overflow and regular stops. It may be useful in cases where
> > > only these joins need not be displayed.
> > >
> > >
> > > >>>>
> > > - af|train::overflow-start combinable with :disabled and :readOnly
> > > - af|train::overflow-end combinable with :disabled,
> > > :unvisited and :readOnly
> > > >>>>
> > >
> > > - Do you think we should support :unvisited state on
> > > overflow-start? This may be useful in cases where the train
> > > is not sequential? I have a scenario where all stops in the
> > > train are enabled and user can jump around any stop without a
> > > prescribed order.
> > >
> > > >>>>
> > > 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)
> > > -content  (for example, the following is valid:
> > > af|train::stop-content and
> > > af|train::stop:selected-content. This selector refers to the
> > > link cell
> > > af|(of the train)
> > > >>>>
> > >
> > > - I agree with Jeanne. Let's call it stop-content:selected. I
> > > don't think we need stop-content:visited or
> > > stop-content:unvisited. It's an overkill.
> > >
> > > >>>>
> > > -icon-block (as above but refers to the icon cell)
> > > >>>>
> > >
> > > - Perhaps we should have a convention of using -block suffix
> > > for style classes that go on <div> and -cell for styles that
> > > go on td. Is that acceptable?
> > >
> > > >>>>
> > > I use the same join rule as you, that is previous stop
> > > determine the join state, except for the join after the
> > > selected stop. The only exception are disabled stops, those
> > > have disabled joins on both sides.
> > > >>>>
> > >
> > > - the join after the selected stop should ideally have the
> > > state of the following stop. Isn't it? Do you think it will
> > > be easier to just show the left join of a disabled stop as
> > > "disabled". So if an unvisited stop follows the disabled
> > > stop, the join between them will show up as unvisited. At
> > > least this is how I have implemented it. I use the same rule
> > > for displaying joins before overflows.
> > >
> > >
> > > >>>>
> > > I also go rid of the separator, it's redundant as you can add
> > > padding to -content selector. I also added two aliases
> > > .AFTrainContent:alias and .AFTrainIconBlock. So you can add
> > > spacing between stop with something like the following:
> > > .AFTrainContent:alias
> > > {
> > >   padding-left: 8px;
> > >   padding-right: 8px;
> > > }
> > > >>>>
> > > When you say separator, do you mean the spacer that separates
> > > stops? Where is the alias above included? Can you send me a
> > > HTML fragment?
> > >
> > > Thanks
> > > - Pavitra
> > >
> > >
> > > > -----Original Message-----
> > > > From: Simon Lessard [mailto: [EMAIL PROTECTED]
> > > > Sent: Tuesday, August 29, 2006 11:43 AM
> > > > To: [email protected]
> > > > Subject: Re: TrainRenderer using the new train selectors
> > > >
> > > > 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
> > > > > >> >> > > >
> > > > > >> >> > > >
> > > > > >> >> > > >
> > > > > >> >> > > >
> > > > > >> >> > >
> > > > > >> >> > >
> > > > > >> >> >
> > > > > >> >> >
> > > > > >> >> >
> > > > > >> >>
> > > > > >> >>
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>

Reply via email to