I used FireBug to look at inhibiting that style. If I inhibit the style
then the text becomes spaced out on FireFox (but not IE), but if you use the
DOCTYPE from the Bob's example then it fixes itself. So I guess it was put
there originally to correct a FireFox quirk for our default doctype.
On 8/7/07, Adam Winer <[EMAIL PROTECTED] > wrote:
>
> The downside of switching to DIVs is that anyone who wanted
> messages on the right:
>
> MyLabel [.... input field ]
> MyLabel2 [.....input field ] ERROR!
>
> wouldn't be able to do it, right? Dunno that I care that much.
>
> FWIW, I'm almost certain that the big problem is:
>
> <style selector=".OraInlineInfoText">
> <includeStyle name="AFVerySmallFont"/>
> <includeStyle name="AFDarkForeground"/>
> <includeStyle selector=".p_OraDisplayBlock"/>
> </style>
>
> ... specifically the .p_OraDisplayBlock entry, which is
> just really an alias for display:block. HUH?!? What's
> that doing there? And, for that matter, what's the
> point of this style at all? I think we should kill this style,
> and attach styles directly to each message section.
>
> I suspect that a skinner can simply override the style
> of OraInlineInfoText to remove the "display" property
> with something like:
>
> .OraInlineInfoText {
> -tr-inhibit: display;
> }
>
> -- Adam
>
>
> On 8/6/07, Danny Robinson < [EMAIL PROTECTED]> wrote:
> > Good question. Did a quick test and it's the style, but it's not that
> easy
> > looking at the code!!! The MessageRenderer isn't the simplest piece of
> > code. Really hard to understand just what gets rendered when. Before
> you
> > discovered it's the style, I did a quick refactor that seemed to fix the
> IE
> > problem.
> >
> > As the inline validation is now the default it seems to make sense to
> have
> > it output div's for each message section (help, message,
> inline-message).
> > Prior to this, it was pushing out span-br-span or span-br-span-br-span
> > depending on the scenario. We should try and keep things consistent for
> > successful skinning - as it stands now, changes to OraInlineInfoText
> would
> > unintentionally appear in OraInlineErrorText.
> >
> > I've attached a patch file - see what you think. There's definate
> further
> > improvements that could be made.
> >
> > D.
> >
> >
> > On 8/6/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > Is it the span, or the OraInlineInfoText style that's to blame?
> > >
> > > -- Adam
> > >
> > >
> > > On 8/6/07, Danny Robinson <[EMAIL PROTECTED]> wrote:
> > > > I can see it also. Not tracked this down in the renderer, but just
> > saved
> > > > the output html and played with it.
> > > > Would seem to be related to the outer SPAN inside the DIV that
> renders
> > under
> > > > each input field.
> > > >
> > > > <DIV class=af_panelFormLayout_message-cell
> > style="DISPLAY:
> > > > none"><!--Start:
> > > > org.apache.myfaces.trinidad.Input["_idJsp3"]--><SPAN
> > > > class=OraInlineInfoText><SPAN class=OraInlineErrorText
> > > > id=_idJsp1:_idJsp3::msg
> > > > style="DISPLAY: none"></SPAN></SPAN></DIV>
> > > >
> > > > With the SPAN removed it seems to behave.
> > > >
> > > >
> > > >
> > > > On 8/6/07, Butash, Bob < [EMAIL PROTECTED] > wrote:
> > > > > Adam,
> > > > >
> > > > > I'm testing with IE 6. Here is the simple.jsp page that I
> created:
> > > > >
> > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> > > > > " http://www.w3.org/TR/html4/loose.dtd";>
> > > > > <%@ page
> > contentType="text/html;charset=windows-1252"%>
> > > > > <%@ taglib uri="http://java.sun.com/jsf/html " prefix="h"%>
> > > > > <%@ taglib uri=" http://java.sun.com/jsf/core " prefix="f"%>
> > > > > <%@ taglib uri="
> > > > http://myfaces.apache.org/trinidad";
> > > > prefix="tr"%>
> > > > > <f:view>
> > > > > <tr:document>
> > > > > <h:form>
> > > > > <tr:panelFormLayout>
> > > > > <tr:inputText label="Label 1" required="true"/>
> > > > > <tr:inputText label="Label 2" required="true"/>
> > > > > <tr:commandButton action="/jsp/simple.jspx"/>
> > > > > </tr:panelFormLayout>
> > > > > </h:form>
> > > > > </tr:document>
> > > > >
> > > > > </f:view>
> > > > >
> > > > > I enter a value in the first field and then click on the
> button....I
> > get
> > > > > whitespace below the first field and I properly get the error
> message
> > > > > under the second field. If the Trinidad <client-validation> is
> set to
> > > > > DISABLED the weird spacing goes away, but then this takes away the
> > > > > client side validation. Obviously if it is set to ALERT, the
> > JavaScript
> > > > > alert box is shown. We were hoping to get a consistent look and
> feel
> > > > > with the messages that need to come from the server and the ones
> that
> > > > > could be checked on the client.
> > > > >
> > > > > I have attached some screen shots, not sure if they will make it
> to
> > the
> > > > > distribution list.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Bob
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Adam Winer [mailto: [EMAIL PROTECTED]
> > > > > Sent: Monday, August 06, 2007 2:03 PM
> > > > > To: MyFaces Discussion
> > > > > Subject: Re: Trinidad Migration to 1.0.1
> > > > >
> > > > > I've just tested with the current Trinidad 1.0.2 code and IE 7,
> and
> > > > > don't see a problem. Are you seeing problems with IE 6 or IE
> 7? If
> > IE
> > > > > 7, could you post the simplest page you can think of that shows a
> > > > > problem?
> > > > >
> > > > > -- Adam
> > > > >
> > > > >
> > > > > On 8/6/07, Perkins, Nate-P63196 < [EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > >
> > > > > > I have this issue as well. I have not found a solution to it
> yet.
> > > > > >
> > > > > >
> > > > > > Nate Perkins
> > > > > > 480-441-3667
> > > > > > [EMAIL PROTECTED]
> > > > > >
> > > > > > This email message is for the sole use of the intended
> recipient(s)
> > > > > > and may contain GDC4S confidential or privileged information.
> Any
> > > > > > unauthorized review, use, disclosure or distribution is
> prohibited.
> > > > > > If you are not an intended recipient, please contact the sender
> by
> > > > > > reply email and destroy all copies of the original message.
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: Butash, Bob [mailto: [EMAIL PROTECTED] ]
> > > > > > Sent: Monday, August 06, 2007 10:42 AM
> > > > > > To: [email protected]
> > > > > > Subject: Trinidad Migration to 1.0.1
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hello -
> > > > > >
> > > > > > I'm migrating from a Snapshot build of Trinidad to version 1.0.1and
> > > > > > I'm noticing differences between Firefox and Internet Explorer
> when
> > > > > > I'm using the required attribute on a form field. The issue
> that
> > I'm
> > > > > > having is that when I submit the page with Internet Explore I
> see a
> > > > > > flash of the screen with the input fields expanded as if there
> was
> > > > > > room for the error messages to be displayed between the
> fields. If
> > I
> > > > > > submit the form with a missing required field, I get the error
> > message
> > > > >
> > > > > > properly but once again all of the other fields have been spaced
> for
> > > > > > error messages. These pages look fine with Firefox.
> > > > > >
> > > > > > Has anyone else seen this behavior? I'm assuming that it has
> > > > > > something to do with the new AJAX validation instead of the
> > javascript
> > > > >
> > > > > > validation, but I did not think that it would cause all of the
> > screen
> > > > > > flashes and spacing issues.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Bob
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Chordiant Software Inc.
> > > > www.chordiant.com
> > >
> >
> >
> >
> > --
> >
> > Chordiant Software Inc.
> > www.chordiant.com
> >
>
--
Chordiant Software Inc.
www.chordiant.com
