No, we need the column container and column widgets so the renderers know when
to output clearing elements and when not to.
You're not going to solve the problem with CSS alone. The markup has to reflect
what you're trying to accomplish.
What you're describing is a tug-of-war that has been going on as far back as I
can remember. It started with adding multi-column elements to the
GlobalDecorator (a bad idea) and has continued on to today. There is a
fundamental flaw in how multi-column layout is handled, and it needs to be
fixed. Until then we have to be satisfied with kludges like the no-clear CSS
class.
-Adrian
--- On Tue, 1/12/10, David E Jones <d...@me.com> wrote:
> From: David E Jones <d...@me.com>
> Subject: Re: Screen Widget screenlet and the hard coded br class="clear"
> To: dev@ofbiz.apache.org
> Date: Tuesday, January 12, 2010, 10:35 PM
>
> I guess what you mean by this is as part of that larger
> effort you'll have to introduce a new CSS pattern for
> multi-column layouts.
>
> Do we really need a column widget in order to use a better
> CSS pattern for the multi-column layout?
>
> -David
>
>
> On Jan 13, 2010, at 12:28 AM, Adrian Crum wrote:
>
> > I disagree. The stuff we have doesn't work just fine.
> Try removing the clearing element and see what happens. The
> multi-column layout you're working on looks great, but now
> everything else is broken.
> >
> > Our existing multi-column layout is extremely fragile
> and easily broken. That's why I suggested the column
> widgets. It's a bigger issue than dragging columns or
> changing sizes.
> >
> > -Adrian
> >
> > --- On Tue, 1/12/10, David E Jones <d...@me.com>
> wrote:
> >
> >> From: David E Jones <d...@me.com>
> >> Subject: Re: Screen Widget screenlet and the hard
> coded br class="clear"
> >> To: dev@ofbiz.apache.org
> >> Date: Tuesday, January 12, 2010, 10:20 PM
> >>
> >> The point isn't to accommodate multi-column
> layouts, we
> >> already have basic stuff for that which works just
> fine. I'm
> >> not talking about anything like dragging columns
> or
> >> configuring sizes or anything like that. It's an
> interesting
> >> idea, but a different one.
> >>
> >> The question I have is do we really want this
> <br
> >> class="clear"/> tag always inserted when you
> use the
> >> screen widget screenlet element?
> >>
> >> Right now there is a bit of a "hack" in place to
> cause this
> >> tag to do nothing, and that is by wrapping the
> screenlet in
> >> a container with a style of "no-clear".
> >>
> >> So, the point is that is seems like in most cases
> this
> >> clear isn't needed and we can avoid the no-clear
> hack by
> >> having something explicit when it is needed.
> >>
> >> -David
> >>
> >>
> >> On Jan 13, 2010, at 12:13 AM, Adrian Crum wrote:
> >>
> >>> We had a discussion about accommodating
> multi-column
> >> layouts. Search the dev list for Subject =
> "Discussion:
> >> Column Widgets (was: How to add a splitter to
> adjust the
> >> left column width by dragging it?"
> >>>
> >>> -Adrian
> >>>
> >>> --- On Tue, 1/12/10, David E Jones <d...@me.com>
> >> wrote:
> >>>
> >>>> From: David E Jones <d...@me.com>
> >>>> Subject: Screen Widget screenlet and the
> hard
> >> coded br class="clear"
> >>>> To: dev@ofbiz.apache.org
> >>>> Date: Tuesday, January 12, 2010, 10:07 PM
> >>>>
> >>>> I am looking into an issue with formatting
> using
> >> a
> >>>> CSS-based multiple column layout and with
> >> screenlets in each
> >>>> column.
> >>>>
> >>>> The problem is that in the
> >> htmlScreenMacroLibrary.ftl file
> >>>> there is a hard-coded clear on line 148:
> >>>>
> >>>> <br class="clear" />
> >>>>
> >>>> With most browsers these clears are no
> >> context-sensitive,
> >>>> they clear ALL floats. This means that it
> messes
> >> up the
> >>>> multi-column formatting.
> >>>>
> >>>> Would anyone be too disappointed if we
> removed
> >> this, and if
> >>>> you need a clear below your screenlet then
> just
> >> use a
> >>>> container element after the screenlet
> element in
> >> your screen
> >>>> definition?
> >>>>
> >>>> Also, does anyone know the reason this was
> put
> >> there in the
> >>>> first place?
> >>>>
> >>>> Can anyone think of any issues removing
> this might
> >> cause?
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>
