[dojo-contributors] BorderContainer etc. styling

Adam L. Peller adam at peller.org
Thu May 22 00:08:25 EDT 2008

Thanks for the explanation of why these changes are necessary.  It makes me
fear them less :-)

Still, I am concerned that making something "look good out of the box" is
making assumptions about the use case.  In this case, it's themeTester.
 Presently, BorderContainer in the simplest cases, like LayoutContainer
before it, makes no mention of splitters. They're an add-on.  So it's not
unreasonable to assume that people are using them with simple content
(rather than nested _Container widgets) and expect panes to abut each other
-- and that looks fine out of the box to them, but if space suddenly
appeared, it might not.  Such a change isn't just look and feel, in my view,
it breaks the contract of the widget, which is to simply position
rectangles.  Are people going to complain?

I agree that 'magic' to connect the concepts of container margins with panel
spacers, or 'gutters' in designer-speak, doesn't feel right.  I like the
idea of an attribute (on the container should be sufficient? or maybe child
selector CSS?) to control this behavior, but requiring users to put in a
setting to get the 1.1 behavior might be a viewed as a breaking change.  Is
it possible we could flip the logic around and have the 1.1 behavior be the
default?  gutters=true?


On Mon, May 19, 2008 at 3:51 AM, Bill Keese <bill at dojotoolkit.org> wrote:

> There are a couple issues that Nikolai and I have been working on w.r.t.
> BorderContainer styling, and I want to get the group's opinion.   The
> issues are:
>  - missing splitter borders (http://trac.dojotoolkit.org/ticket/6438)
>  - nested border problem (http://trac.dojotoolkit.org/ticket/6437)
> The obvious solution to the missing splitter borders is to add borders
> to the splitters, except that those borders would conflict (compound?)
> with the borders of TabContainer/AccordionContainer/etc (see #6437).  So
> we are actually looking instead at having borders on all the panes
> (which the user will perceive as borders on the splitters), and adding
> in spacing so no borders touch other borders.
> The end result will look something like this:
> http://dojocampus.org/dojodev/dijit/themes/themeTester.html
> (it's a slow link; be patient) and will have the following changes from
> the 1.1 release:
>  - spacing: every pane conceptually has a margin around it (on all
> sides), separating it from other panes and from the border of the
> BorderContainer itself.
>  - all panes have borders:
>     * the ContentPane has a border
>     * TabContainer has a border that goes all around, including
> wrapping around the tab labels (see
> http://dojocampus.org/dojodev/dijit/tests/layout/test_TabContainer.html
> although there are still some glitches).
>  - removed shading from sliders, to make them match BorderContainer
> padding.   (padding and sliders are same width)
> As a corollary to all of this, even when panes aren't resizable, the
> default should be to have that spacing, see:
> http://trac.dojotoolkit.org/ticket/6768
> As is probably obvious, the relevant dijit principles here are:
>  1. looks good out of the box
>  2. allow customization of look by themes and/or web developers
>  3. works on IE
> Look good out of the box
> ========================
> #1 means that (if at all possible) simple markup w/out any flags will
> look decent.   For example, this markup should show up with the
> padding/margin/borders that I described above:
> <div dojoType=BorderContainer>
>   <div dojoType=AccordionContainer region=left style="...">
>        ...
>   </div>
>   <div dojoType=TabContainer region=center>
>        ...
>   </div>
> </div>
> One possible issue is to support different looks for widgets that are
> inside BorderContainer vs. stand-alone.   For example, perhaps
> TabContainer should only have that tab-label border when appearing
> inside a BorderContainer.  Not sure how to implement that though.
> We can obviously have different CSS classes, like .dijitTabContainer and
> .dijitTabContainerFullBorder, but it's inconvenient (and requires a
> learning curve) for developers to type
> <div dojoType=TabContainer class="dijitTabContainerFullBorder">
> so I'd like to avoid that.
> The options I can think of are:
>  - just always display the TabContainer w/that top border around the
> labels.
>  - require user to manually set things via class="..." (and to memorize
> the name of each class, yuk).  But this violates the principle of simple
> markup looking good out of the box.
>  - have a flag like layout="true"... again requiring the user to set
> this violates the principle of having simple markup look good out of the
> box.
>  - some kind of magic so that widgets change their look when inside a
> BorderContainer.  The obvious CSS rule is
>   .dijitBorderContainer > .dijitTabContainer { ... }
> but that won't work on IE so we need to use something less obvious, and
> more complicated.
> It's worth reiterating that we aren't making assumptions about what look
> the developer wants, but merely setting up defaults that can be overridden.
> Customization
> =============
> #2 is the most complicated issue and refers to how a dojo developer
> customizes the look.  In particular a developer may want no spacing
> between non-resizable panes.
> There are a couple of APIs I can think of:
>  - query margin settings for each pane and use those to lay out the
> panes w/appropriate spacing between them.  This might be too much magic,
> and also doesn't mesh with the existing system where the space between a
> resizable pane and the center pane is specified by the CSS definition of
> the splitter
>  - use padding of BorderContainer itself to indicate spacing between
> panes.   Same problems as above.
>  - in the same way that resizable panes have a draggable splitter <div>,
> make a non-draggable splitter <div> for non-resizable panes, and have
> that controllable via some CSS rule like
>    .dijitNonMovableSplitterH { width: 5px; }
> This seems like the best option although it makes it difficult to
> control the width of each non-movable splitter individually.  Probably
> if the BorderContainer had id="foo" then the splitters would have id's
> like foo_top_splitter, to allow customization per splitter.
>  - have a flag on each pane to control whether or not to have spacing
> between a non-resizable pane and the center pane.  I don't really like
> this option since we try to restrict styling issues to CSS, but perhaps
> it's practical.
> IE
> ==
> #3 is simply a reminder that we can't use selectors like
>  - .dijitBorderContainerChild.dijitTabContainer (the "and" condition on
> a single node)
> or
>  - .dijitBorderContainer > .dijitTabContainer
> So, that's a very long explanation but hopefully some have read to the
> end.  Comments?
> Bill
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20080522/f90706af/attachment.htm 

More information about the dojo-contributors mailing list