Slow-motion view of effects in MochiKit.Visual

[Per Cederberg-2]

While testing some fixes for MochiKit.Visual, I updated the demo page
for MochiKit.Visual to also include a slow-motion alternative:

http://mochikit.com/examples/effects/index.html

Kind of cool with effects running in slow-motion. But it also shows
issues with element padding and MochiKit.Style.getElementDimensions
quite clearly (or is it perhaps #286).

/Per

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christoph Zwerschke]

Per Cederberg schrieb:
 > While testing some fixes for MochiKit.Visual, I updated the demo page
 > for MochiKit.Visual to also include a slow-motion alternative:
 >
 > http://mochikit.com/examples/effects/index.html

Good idea. Maybe we should use a checkbox to activate slow-motion and/or
use rounded buttons or a drop-down list to select the various effects?
Or normal links? Clickable text isn't really attractive.

 > Kind of cool with effects running in slow-motion. But it also shows
 > issues with element padding and MochiKit.Style.getElementDimensions
 > quite clearly (or is it perhaps #286).

Do you mean that slideDown etc. make the box too big and then shrink
back to the original size?

-- Chris

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg-2]

Your suggestions are all good. Don't like clickable text either, but I
just took the fastest route... :-)

Yes, the box becomes too big and is then corrected when the finalize
function restores the original values for position and size.

/Per

On Sat, May 24, 2008 at 11:14 AM, Christoph Zwerschke <cito@...> wrote:

>
> Per Cederberg schrieb:
>  > While testing some fixes for MochiKit.Visual, I updated the demo page
>  > for MochiKit.Visual to also include a slow-motion alternative:
>  >
>  > http://mochikit.com/examples/effects/index.html
>
> Good idea. Maybe we should use a checkbox to activate slow-motion and/or
> use rounded buttons or a drop-down list to select the various effects?
> Or normal links? Clickable text isn't really attractive.
>
>  > Kind of cool with effects running in slow-motion. But it also shows
>  > issues with element padding and MochiKit.Style.getElementDimensions
>  > quite clearly (or is it perhaps #286).
>
> Do you mean that slideDown etc. make the box too big and then shrink
> back to the original size?
>
> -- Chris
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christoph Zwerschke]

Per Cederberg schrieb:
 > Your suggestions are all good. Don't like clickable text either, but I
 > just took the fastest route... :-)
 >
 > Yes, the box becomes too big and is then corrected when the finalize
 > function restores the original values for position and size.

The problem is that offsetWidth/Height gets you the with including
padding and borders, so you can't use this as value for width/height.

I have tried to fix these issues in r1383 and also replaced the
clickable text with form elements.

-- Chris

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg-2]

I like the new look of the effects demo page. Great work!

Question though, why add MochiKit.Style.getElementHeight and
getElementWidth? I think MochiKit.Style.getElementDimensions was
introduced to have one function instead of two (keeping down the size
of the API). But now we have three, which seems redundant to me.

/Per

On Sun, May 25, 2008 at 3:27 AM, Christoph Zwerschke <cito@...> wrote:

>
> Per Cederberg schrieb:
>  > Your suggestions are all good. Don't like clickable text either, but I
>  > just took the fastest route... :-)
>  >
>  > Yes, the box becomes too big and is then corrected when the finalize
>  > function restores the original values for position and size.
>
> The problem is that offsetWidth/Height gets you the with including
> padding and borders, so you can't use this as value for width/height.
>
> I have tried to fix these issues in r1383 and also replaced the
> clickable text with form elements.
>
> -- Chris
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christoph Zwerschke]

Per Cederberg schrieb:
> Question though, why add MochiKit.Style.getElementHeight and
> getElementWidth? I think MochiKit.Style.getElementDimensions was
> introduced to have one function instead of two (keeping down the size
> of the API). But now we have three, which seems redundant to me.

getElementDimensions returns the dimensions including padding and
border, while getElementHeight/Width returns the actual height and
width. The problem was that the visual effects calculated the original
width and height using getElementDimensions which was too big.

I could have put getElementHeight/Width in Visual, but Style seemed more
appropriate. Probably we should add documentation and tests for these?

-- Christoph

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg-2]

Ok, I see. Then we have two issues:

#1. getElementDimensions() and setElementDimensions() isn't currently
a logical pair, since border and padding is included in
getElementDimensions but not in setElementDimensions. This is
confusing and should be better documented:

    http://trac.mochikit.com/ticket/310

# 2. I think the current function names can be a cause of confusion
(hence my previous question). And perhaps a single function returning
a Dimensions object would be more in line with existing MochiKit code?
See also the following Trac ticket for other related add-ons to
MochiKit.Style:

    http://trac.mochikit.com/ticket/84
    http://trac.mochikit.com/wiki/MochiKitStyleExtensions

Perhaps a solution would be to change getElementDimensions() to return
an object containing also the CSS width and height? I.e. { w, h, cssW,
cssH }

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.

Cheers,

/Per

On Tue, May 27, 2008 at 3:25 PM, Christoph Zwerschke <cito@...> wrote:

>
> Per Cederberg schrieb:
>> Question though, why add MochiKit.Style.getElementHeight and
>> getElementWidth? I think MochiKit.Style.getElementDimensions was
>> introduced to have one function instead of two (keeping down the size
>> of the API). But now we have three, which seems redundant to me.
>
> getElementDimensions returns the dimensions including padding and
> border, while getElementHeight/Width returns the actual height and
> width. The problem was that the visual effects calculated the original
> width and height using getElementDimensions which was too big.
>
> I could have put getElementHeight/Width in Visual, but Style seemed more
> appropriate. Probably we should add documentation and tests for these?
>
> -- Christoph
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christoph Zwerschke]

Per Cederberg schrieb:
> Ok, I see. Then we have two issues:
>
> #1. getElementDimensions() and setElementDimensions() isn't currently
> a logical pair, since border and padding is included in
> getElementDimensions but not in setElementDimensions. This is
> confusing and should be better documented:
>
>     http://trac.mochikit.com/ticket/310

Exactly.

> # 2. I think the current function names can be a cause of confusion
> (hence my previous question). And perhaps a single function returning
> a Dimensions object would be more in line with existing MochiKit code?
> See also the following Trac ticket for other related add-ons to
> MochiKit.Style:
>
>     http://trac.mochikit.com/ticket/84
>     http://trac.mochikit.com/wiki/MochiKitStyleExtensions
>
> Perhaps a solution would be to change getElementDimensions() to return
> an object containing also the CSS width and height? I.e. { w, h, cssW,
> cssH }

Maybe just width, height instead of cssW, cssH? This should be
accompanied by changing setElementDimensions() to use width, height
instead of w, h if these are present. That way we the functions would
become a logical pair without losing backward compatibility.

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

Good idea. Will do that later.

-- Christoph

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Christoph Zwerschke]

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 mochikit@...
To unsubscribe from this group, send email to mochikit-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg-2]

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 <cito@...> 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 mochikit@...
To unsubscribe from this group, send email to mochikit-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg-2]

Hmm... It looks like using the computed width and height is not a
fail-safe way to proceed. We will need to fallback to getDimensions
from time to time:

http://trac.mochikit.com/ticket/311

/Per

On Fri, May 30, 2008 at 11:59 AM, Christoph Zwerschke <cito@...> 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 mochikit@...
To unsubscribe from this group, send email to mochikit-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---