[dojo-contributors] BorderContainer etc. styling

Bill Keese bill at dojotoolkit.org
Mon May 19 03:51:10 EDT 2008


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



More information about the dojo-contributors mailing list