implement borderBox()?

[bill]

Widgets like Combobutton/FilteringSelect? and DropdownButton/Combobutton? need to size the drop down to be at least as wide as the button/input itself... "wide" referring to border-size. Should we implement a borderBox() function, similar to marginBox()/contentBox() ?

[Eugene Lazutkin]

dojo.dnd.parentConstrainedMover (at the bottom of dojo/trunk/dnd/move.js) implements all four boxes including the border box and the padding box using existing dojo/_base/html.js function. You can use it as a cheat sheet to implement the required functionality.

[alex]

calculating the border box is tremendously expensive and the primary reason that many of the widgets that required layout were so damned slow in 0.4.x. In the cases you describe, we need to size the margin box of the drop downs to the content box of the container for the button's visible rendering. If the button needs a margin, it'll be cheaper to add another node to the template than to do these calculations at runtime.

I'm not inclined to add borderBox().

[bill]

I guess we could do that but are you saying that calculation a border box is more expensive than a margin box/content box? (If so, why? It seems like either one is just getComputedStyle() followed by some math. Was it the issue w/converting em to px?)

[alex]

border box is much more expensive. Margin and content box were chosen due to their relative cheapness and for the fact that you can do nearly anything with just those primitives. The issue isn't em/px conversion, but rather the number of times you need to get computed styles.

I'm marking this wontfix.

[bill]

test of speeds of various functions

[bill]

Not true at all. Border box is always faster than margin box (both get and set). getBorderBox() is faster than getContentBox(). setBorderBox() is slower than setContentBox() but still faster than setMarginBox(). I've attached a testcase, which I ran on IE6, FF2, and Safari3.

So let's talk again; if you don't want this in dojo we can add it to dijit instead, but let's not drop it based on the claim that "border box is much more expensive".

[sjmiles]

[ed: I'm burying the punch-line as usual, jump down to the last two paragraphs if you want to ignore my meta-ramblings.]

Whether or not calculating borderBox is faster or slower than other boxes depends on the box-model applied to the node in question. But the speed of the method is not really what gives me pause.

The bigger concern is keeping the API simple. There are numerous permutations for these calculations, and the more we can constrain folks to do things in a standard fashion, the better.

My general complaint is that border-box could be translated as: "I put padding on this node but now I want to ignore it". I suspect one usually wants either a node with no-padding, or one really wants to honor the padding.

Technically, more box methods means more code which involves various factoring tradeoffs. Factoring incurs function call overhead that is not insignificant for these time-critical functions.

Having said all that, I can't be sure there isn't some legitimate use for border-box that I haven't considered. My current thinking is that there needs to be at least low-level support for border-box, if not the full treatment that the other two "primary" box models have.

I have to take another run at html.js anyway to tighten up erosion that has occurred while adding/patching code for positioning (DnD) and for browser peculiarities. I will try to split the differences and come up with some solution.

[bill]

My general complaint is that border-box could be translated as: "I put padding on this node but now I want to ignore it". I suspect one usually wants either a node with no-padding, or one really wants to honor the padding.

I think it's more like "I put margin on this node and now I want to ignore it.", but I understand what you are saying about not supporting too many methods.

The original goal was to make drop down menus as wide (or wider) than the button they drop down from (regardless of the margin on the button). Slightlyoff suggested setting the menu's contentBox equal to the button's content box, and making the menu's border and padding equal to the button's. I guess that will work.

[sjmiles]

I think it's more like "I put margin on this node and now I want to ignore it.", but I understand what you are saying about not supporting too many methods. <<

You've hit upon the problem of reference frames. Whether a particular box is measured from the inside or the outside is unclear. Iow, are we needing to position a node, or children inside a node?

This is already a source of confusion for the two box functions that exist. Existing convention is that marginBox is for positioning nodes, and contentBox is for positioning children inside that node.

I mention this because the problem is not just "supporting too many methods", there really is an issue of permutations.

[sjmiles]

I realize I was unclear about what I hope to achieve, which is a way for you to get your border box. I can see the sense in your original problem, and it has also come up wrt DnD.

[sjmiles]

In r9341 (#3552), I introduced _getBorderBox method. The returned box is in the coordinate system of the children of node (just like contentBox methods).

[sjmiles]

Marking this as fixed. There may be more issues surrounding borderBox that we can handle as we find them.