[dojo-contributors] BorderContainer etc. styling

Alex Russell alex at dojotoolkit.org
Mon May 19 06:10:52 EDT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Bill, Nikolai:

On May 19, 2008, at 9:51 AM, Bill Keese 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)

Thanks for digging into these! I know that these are non-trivial to fix.

> 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

I like the way this looks and behaves. The borders on the splitters  
"make sense" visually and this solution avoids the "doubled up  
borders" issues we had on 1.0. Nice work!

> (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).

can there be a "noBorder" flag or something similar for uses like this  
which don't find themselves inside of a splitter of some variety?  
Alternately, could there be a CSS rule that makes the determination  
(modulo the IE 6 issue)?

> - 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

That seems reasonable.

> 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.

I'd imagine a flag to get a certain behavior no matter what + an auto- 
detect for when the flag isn't set, perhaps in postCreate().

> 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.

Agreed.

>  - 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.

Something like an explicit rule applied programmatically on IE 6?

> 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.

Sounds great to me.

> Customization
> =============

[ snip ]

> - 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.

I'm for that.

> - 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.

Sounds like it would make folks dive for docs a lot more often...or am  
I missing something on this?

> 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?


1.) this is great work, incredibly thorough, and I couldn't be happier  
to see this issue addressed. Along with many of the other fixes you  
and the Dijit team have been making to the L&F of the toolkit, this is  
going to do a lot to make the toolkit feel more "put together".
2.) it seems like we keep hitting the child-selector thing, and indeed  
it seems a primary contributor to the explosion of the size of the  
Dijit CSS files. Perhaps we need some unified utility or pattern to  
handle it instead of adding ever-more classes to the themes?
3.) the length of some of the CSS names is starting to be a  
contributor to overall toolkit size. Perhaps we should consider some  
shorter abbreviations?

Regards
- --
Alex Russell
alex at sitepen.com  A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFIMVIsz3jiQlnDlyMRAjomAKDl7s8XvYgyRSVTWaJHKKAlBdv43wCeIOAX
w3PicWv/tc7IumNoDs5pk4A=
=lw+7
-----END PGP SIGNATURE-----



More information about the dojo-contributors mailing list