Proposed DOM Functions

0 views
Skip to first unread message

Beau Hartshorne

unread,
Jan 24, 2006, 4:05:05 PM1/24/06
to MochiKit
I'd like to ask for feedback on some possible new DOM functions to
help with element positioning:

MochiKit.DOM.Box, a new object: {t: 0, l: 0, b: 0, r: 0}

getContentBox(someElement), returns a Box
getBorderBox(someElement), returns a Box
getPaddingBox(someElement), returns a Box
getMarginBox(someElement), returns a Box

These will accept a partial box, like {r: 0} if you only want to
change one property:
setContentBox(someElement, aBox)
setBorderBox(someElement, aBox)
setPaddingBox(someElement, aBox)
setMarginBox(someElement, aBox)

getViewportDimensions(), returns a Dimensions object

moveTo(someElement, Coordinates/* optional */, aBoundingBox)
moveBy(someElement, Coordinates, Coordinates)

getStyleBox(someElement), returns a Box
setStyleBox(someElement, aBox)

setOpacity() // will accept 'none' to clear it
getOpacity()
isVisible(), returns true/false
toggleVisible(), uses hideElement and showElement

Thoughts?

Jones

unread,
Jan 31, 2006, 12:06:35 PM1/31/06
to MochiKit
I'd use the visibility and opacity ones (I assume you'd pass the
element as a parameter). However,
http://mochikit.com/doc/html/MochiKit/DOM.html#element-visibility
mentions some difficulty in implementing a general javascript solution.
Good luck,

The move functions sound interesting. Can you describe the parameters?

Talk more about the box functions. How would you use them?

Beau Hartshorne

unread,
Jan 31, 2006, 1:38:33 PM1/31/06
to Jones, MochiKit
I just saw that too, visibility's out. I think it's OK to include
opacity.

So moveTo would look something like:

moveTo: function (elem, coords/* optional */, box) {
elem = self.getElement(elem);
if (box) {
if (coords.x < box.l) {
corrds.x = box.l;
}
// .. etc
}
self.setElementPosition(elem, coords);
},

setElementPosition: function (elem, newPos) {
elem = self.getElement(elem);
self.updateNodeAttributes(elem,
{'style': {'left': newPos.x + 'px', 'top': newPos.y + 'px'}}
);
},

the setBorderBox would look something like this:

setBorderBox: function (elem, box) {
elem = self.getElement(elem);
self.updateNodeAttributes(elem,
// add code that checks which box attrs are set
// apply changes to non-undefined box attrs
{'style': {
'border-top-width': box.t + 'px',
'border-right-width': box.r + 'px',
'border-bottom-width': box.b + 'px',
'border-left-width': box.l + 'px'
}}
);

Bob Ippolito

unread,
Jan 31, 2006, 2:03:21 PM1/31/06
to Beau Hartshorne, MochiKit

All of these look good to me. Personally I would prefer an x,y,w,h
box model, but t,l,b,r is CSS convention so I guess that's more
appropriate.

> isVisible(), returns true/false
> toggleVisible(), uses hideElement and showElement

This is troublesome (as cited elsewhere in the thread). I'd rather
leave these out.

-bob

Beau Hartshorne

unread,
Jan 31, 2006, 2:51:47 PM1/31/06
to Bob Ippolito, MochiKit
x,y,w,h is awkward for padding, margin, and border. DOM.Coordinates
and DOM.Dimensions define {x,y} and {w,h}, I don't think an {x,y,w,h}
Box is really needed. And to really follow the CSS convention, the
properties should be top, left, bottom, and right.

Do you see any problem defining functions like this that assume 'px'
is the working unit? They're creeping in, and I'm not sure if this is
the best thing to do.

Bob Ippolito

unread,
Jan 31, 2006, 3:12:12 PM1/31/06
to Beau Hartshorne, MochiKit
I've never personally seen any code that works in anything but px.
Let's leave out in/em/% support until there's a use case for it..
seems like a lot of work for little practical use. It might be worth
checking for px and raising an exception if it's in some other unit,
though.

-bob

Eoghan

unread,
Feb 1, 2006, 8:46:29 PM2/1/06
to MochiKit
'em's and percentages are a must in my opinion if scripts are going to
be used on flow layed out sites. A possible example of use could be
dragging and dropping, where you calculate an elements position based
on the pixel mouse co-ordinates, but then drop the element with
percentage coordinates calculated from them.

But then updateNodeAttributes(elem, {'style': {'left':
mouse.x/[screenWidth]+ '%', 'top': mouse.y/[screenHeight] + '%'}}
would suffice.

I wouldn't like to see MochiKit get too much stuff like this (that
assumes a certain way of doing things, e.g. pixels), it seems to me to
be extending the scope of the core library too much.

Beau Hartshorne

unread,
Feb 1, 2006, 9:04:02 PM2/1/06
to Eoghan, MochiKit
How's this:

setBox: function (elem, kind, box/* optional */, units) {
var newBox = {};

if (typeof(units) == 'undefined') {
units = 'px';
}

if (typeof(box) == 'number') {
newBox[kind + '-width'] = box + units;
} else {
MochiKit.Iter.forEach(box,
function(e) {
if (typeof(box[e]) == 'number') {
newBox[kind + '-' + e + '-width'] = box[e] + units;
}
}
);
}
MochiKit.DOM.updateNodeAttributes(elem, {'style': newBox});
},

Reply all
Reply to author
Forward
0 new messages