Opened 12 years ago

Closed 12 years ago

#3454 closed task (fixed)

implement borderBox()?

Reported by: bill Owned by: sjmiles
Priority: high Milestone: 0.9
Component: HTML Version: 0.9
Keywords: 4dijit Cc: haysmark@…
Blocked By: Blocking:

Description

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

Attachments (1)

box.html (3.0 KB) - added by bill 12 years ago.
test of speeds of various functions

Download all attachments as: .zip

Change History (14)

comment:1 Changed 12 years ago by 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.

comment:2 Changed 12 years ago by 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().

comment:3 Changed 12 years ago by 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?)

comment:4 Changed 12 years ago by alex

Resolution: wontfix
Status: newclosed

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.

Changed 12 years ago by bill

Attachment: box.html added

test of speeds of various functions

comment:5 Changed 12 years ago by bill

Resolution: wontfix
Status: closedreopened

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

comment:6 Changed 12 years ago by sjmiles

Status: reopenednew

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

comment:7 Changed 12 years ago by sjmiles

Status: newassigned

comment:8 Changed 12 years ago by 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.

comment:9 Changed 12 years ago by 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.

comment:10 Changed 12 years ago by 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.

comment:11 Changed 12 years ago by haysmark

Cc: haysmark@… added; haysmark removed

comment:12 Changed 12 years ago by 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).

comment:13 Changed 12 years ago by sjmiles

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.