Ah magic numbers don't you love them :)
The following link points to a blog entry that goes into detail
about normalising the mouse wheel event so that it can be used
cross browser without going insane.
http://blog.paranoidferret.com/index.php/2007/10/31/javascript-tutorial-the-scroll-wheel/
Mo
Your patch notes indicate not using getElementWidth and
getElementHeight, what are the preferred?
In a fit of trying to get horizontal scaling to happen at the same
time as sliding a pair in the case where they were not the same size,
I had already migrated some of the duplications to helper func
Christoph Zwerschke schrieb:
> Or, to make clearer what is returned, we could use withPadding=true
> instead of innerSize=false.
Sorry, I meant withBorder=true. getElementDimensions returns the size
including padding and border.
-- Christoph
--~--~-~--~~~---~--~---
Per Cederberg schrieb:
> getElementDimensions(element[,innerSize=false])
Yes, that's what I meant.
Or, to make clearer what is returned, we could use withPadding=true
instead of innerSize=false. We could then also provide additional
parameters withPadding and withMargin, or just a single param
I like the idea of adding a boolean parameter to
getElementDimensions(). But we needn't return the actual values found
I think. Like this:
getElementDimensions(element[,innerSize=false])
So calling getElementDimensions(elem, true) would return the inner
dimensions instead of the outer (as the cu
Per Cederberg schrieb:
> I did something similar once, but it is a bit of a pain to read 4
> computed values (which is slow) instead of just using offsetHeight.
> But since it is just used during initialization, speed won't be a
> problem here. But we should still keep it separate from
> getE
Ok, it would be great if you looked at this!
I did something similar once, but it is a bit of a pain to read 4
computed values (which is slow) instead of just using offsetHeight.
But since it is just used during initialization, speed won't be a
problem here. But we should still keep it separate f
Per Cederberg schrieb:
> After investigating this, I think the main problem here was introduced
> in revision 1383. That change introduced the new functions
> MochiKit.Style.getElementHeight and MochiKit.Style.getElementWidth and
> changed MochiKit.Visual to use them in several places. There a
I've added the original patch to Trac #312:
http://trac.mochikit.com/ticket/312
New functionality in MochiKit.Visual is low priority right now, so I
moved it to version 1.5. I also think more generic helper functions
are needed to make new functions like these most compact and readable.
Perhaps
Thanks for all your work on this! We very much appreciate patches and
bug reports, although people are sometimes too busy to respond to
email. :-(
After investigating this, I think the main problem here was introduced
in revision 1383. That change introduced the new functions
MochiKit.Style.getEl
You can send patches to the list, no problem. I don't get
notifications from Trac, so I'm likely to not reply so quickly there.
Which version of MochiKit is this? In MochiKit 1.4 (svn trunk) I found
the following test case, which seems to test this:
var res = parseQueryString("x=1&y=2");
The tab indentation is now fixed in svn trunk [1384].
Regarding the createINPUT and createINPUTFunc functions, I think it
would be better with a more generic solution. When creating SVG DOM
nodes I wrote a createDOMFuncExt function that should work here also.
See http://trac.mochikit.com/wiki/Moc
12 matches
Mail list logo
