I think it is computationally cheaper to just retrieve the "width" and "height" attributes instead of all the padding and border attributes (also in the computed style object). But I've never tested your approach, so we need to make sure that it works in all the major browsers (if you haven't already).
I kind of like the idea of the Dimension object, so the proposed solution for backwards compability sounds to me like the right way to go. Somebody else with any opinion on this? Bob? Cheers, /Per On Fri, May 30, 2008 at 11:59 AM, Christoph Zwerschke <[EMAIL PROTECTED]> wrote: > > Per Cederberg schrieb: > > We should probably take a look at how other toolkits (Prototype, Dojo, > > etc) have handled this issue. Might give a few good ideas for creating > > a concise and useful API. > > Prototype has a getDimensions() function pretty similar to mochikit's, > but they have no setDimensions(), so they don't have the problem with > the logical pairing. > > They also have getWidth() and getHeight() but these are only implemented > as getDimensions().width and getDimensions().height. > > YUI has only functions for the element position, not the dimension. Dojo > doesn't have anything of that ilk. > > jQuery has width() and height() functions for getting and setting the > width and height. It seems to calculate them by getting the offsetWidth > and offsetHeight and then explicitly subtracting the padding and border, > instead of reading them from the (possibly computed) style width and > height attributes as I am doing. Don't know which way is better. > > -- Chris > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~---
