A few MochiKit questions I couldn't find the answer for elsewhere:
#1. Is there a way to do late binding with MochiKit.Base.bind? I.e.
allowing function names to be resolved when the returned function is
called, rather than when bind() is called. See example below:
obj = {
a: function() {
/18/07, Per Cederberg [EMAIL PROTECTED] wrote:
#1. Is there a way to do late binding with MochiKit.Base.bind? I.e.
allowing function names to be resolved when the returned function is
called, rather than when bind() is called. See example below:
obj = {
a: function() { return
Ehm... I couldn't find the NotificationCenter class anywhere in the
svn repo. Perhaps I'm looking at the wrong place? Found a reference
to the class here, but no source code:
http://clipperz.googlecode.com/svn/trunk/src/js/Clipperz/Crypto/PRNG.js
/Per
On Nov 15, 1:50 pm, Giulio Cesare Solaroli
If I recall correctly, it is HTTP GET requests that are limited in
size (or really URL length). Send your data with HTTP POST instead and
you'll get all kinds of other benefits as well.
/Per
On Nov 28, 2007 1:09 AM, Daniel Fetchinson [EMAIL PROTECTED] wrote:
Does anybody know of a workaround
Have a look at MochiKit.Signal instead of using the onclick handler
yourself. It will give you cleaner code.
In the example below, I think the problem is that alert... is a
string, not a function. Try setting it like this instead:
..., onclick: function() { alert('aaa'); }, ...
/Per
On Dec
Have you enabled debugging in Safari? Does the console show any error messages?
From some examples I found, it looks like people use res.responseXML
directly, without the .documentElement part. I guess you should also
check for malformed XML in the response. Here is some relevant
documentation
Definitely agree. And actually I'm in the process of converting my own
widget library into MochiKit style with the goal of making it open
source in two or three months. If someone is interested in creating
something new, I'd only be happy to collaborate off-list on that.
Personally I started
Interesting comments about YUI. Would be intreresting to hear comments
about ExtJS too, if someone has tried it yet. Parts of their API seem
to reproduce Prototype though.
Starting on square one with a new library seems like a lot of
duplication of effort. But the event handling in a widget
Your code is incorrect. It should be:
LI(null, A(null, 'link'))
/Per
On Sat, Feb 16, 2008 at 7:03 PM, matiu [EMAIL PROTECTED] wrote:
Why does this error, and how can I do it without erroring:
LI(A('link'))
Error:
fileNamehttp://mochikit.com/MochiKit/Base.js
Hi,
Just a simple question (for Bob I guess):
Does someone monitor ticket submissions to trac.mochikit.com? Is it
the best way to submit patches and new stuff for MochiKit, or should I
also cross-post to this list?
Cheers,
/Per
--~--~-~--~~~---~--~~
You
I've finished updating the docs for MochiKit.Visual now. The clarified
version is available on the usual place:
http://mochikit.com/doc/html/MochiKit/Visual.html
Please let me know if you find any issues or typos in this version.
/Per
--~--~-~--~~~---~--~~
You
Function.apply and MochiKit.Base.extend sort of works:
var args = MochiKit.Base.extend([pos, 0], elems);
arr.splice.apply(arr, args);
Not that is looks very nice, though.
/Per
On Tue, Mar 25, 2008 at 10:54 PM, Alexandre Augustus Falcão
[EMAIL PROTECTED] wrote:
I searched out but
Hi Everyone,
I was looking over some pending tickets today (in preparation for a
future 1.4 I hope)... and ran across an issue with
MochiKit.Format.truncToFixed and twoDigitFloat:
http://trac.mochikit.com/ticket/275
It's one of these boring floating-point rounding-errors. I think
twoDigitFloat
Yes, there are event hooks:
http://www.mochikit.com/doc/html/MochiKit/Visual.html#fn-base
But I assume that use are using the combined effect functions (appear,
shake, etc)? If you check the updated docs, they now mention that
hideElement and showElement are always used before or after these
Perhaps the issue is the following ordering issue:
var d = .. create deferred ...
d.addErrback(... error handler ...)
d.addCallback(... handler ...)
If the callback handler throws an error, the errback isn't called in
the above case. The order in which one adds errbacks and callbacks is
An alternative would be to call cloneNode() for each DOM node before
appending to the DOM tree. Here is a small untested function to
illustrate:
function appendChildNodeClones(parent, /* ... */) {
var args = flattenArguments(arguments);
for (var i = 1; i args.length; i++) {
if
I've also been bitten by this same issue, but didn't dig deeper into
it before. Great analysis and nice with a patched solution!
Looking at the code in MochiKit.Signal, I have two comments:
1. connect(src, signal, dst, func) uses late binding to dst[func] for
DOM signals, but uses early binding
Thanks for the patch! The relevant changes have been made, so things
should work properly in svn again.
/Per
On Mon, May 5, 2008 at 4:14 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi,
tried to add this patch to the trac ticket that I raised but couldn't,
so it is here instead.
I liked the ondomready name and structure. Looking at MSDN, they
provide the following solution instead of writing new script tags into
the document (not tested, just pasted):
document.onreadystatechange=fnStartInit;
function fnStartInit()
{
if (document.readyState==complete)
{
//
Antti Koivisto, one of the Safari browser developers, wrote an
interesting blog entry about page loading recently. It explains some
of the difficulties involved from a browser perspective:
http://webkit.org/blog/166/optimizing-page-loading-in-web-browser/
And a small extract of the most
it via DOM calls because you don't
need to change the markup.
-bob
On Thu, May 8, 2008 at 12:16 PM, Per Cederberg [EMAIL PROTECTED]
wrote:
Antti Koivisto, one of the Safari browser developers, wrote an
interesting blog entry about page loading recently. It explains some
I suspect that the error stems from the fact that you are using two
animations/effects from MochiKit.Visual in paralell. If you try using
just one of them I suspect that everything should work, right?
I don't have the time to debug or try to reproduce this right now, but
perhaps you could dig
MochiKit.DOM.insertSiblingNodesBefore(node[, siblingNode[, ...]]):
http://www.mochikit.com/doc/html/MochiKit/DOM.html#fn-insertsiblingnodesbefore
/Per
On Tue, May 13, 2008 at 8:27 PM, Szaijan [EMAIL PROTECTED] wrote:
Is there a MochiKit method similar to appendChildNodes that will
insert
I stumbled across an issue with value attributes in input nodes
about a month ago. It seems the behavior is different when using
node.value vs. node.setAttribute(value..):
http://trac.mochikit.com/ticket/302
So the question now it whether or not to patch
MochiKit.DOM.updateNodeAttribute(). Or
I've been using MochiKit with embedded SVG images for some time. And
to accomplish that, I've also written some helper functions to extend
MochiKit. Yesterday I finally got around to cleaning them up and
posting them to the Wiki:
http://trac.mochikit.com/wiki/MochiKitSVG
Please let me know if
1. All DOM nodes have their own properties and types. Look it up in
the HTML DOM API over at W3C.
2. Variables not holding strings are normally converted to strings
with .toString().
/Per
On Fri, May 16, 2008 at 12:44 AM, Szaijan [EMAIL PROTECTED] wrote:
Thanks for the pointer! Is that only
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
!!
But besides the drawing functions, you have been implementing, it would also
be fine to make the rest of MochiKit
(at least that parts, that have to do with DOM..) compatible to SVG files.
Helmut
Per Cederberg schrieb:
I've been using MochiKit with embedded SVG images for some time
Have you tested in version 1.4 also? Think most people uses that.
/Per
On Wed, May 21, 2008 at 11:15 AM, alexander krohn [EMAIL PROTECTED] wrote:
hi.
is this considered a bug?
no cure?
regards,
alexander
--~--~-~--~~~---~--~~
You received this
:35 AM, Per Cederberg [EMAIL PROTECTED] wrote:
Yes, I noted the same on Firefox 3 under Linux yesterday. There's a
strange character range error visible in Firebug.
But in Safari on Mac everything works as usual... And looking through
the recent changesets I see nothing relevant. Perhaps
, function (e) {
logDebug (getElementsByTagAndClassName(null, 'rect-class')) });
]]
/script
/svg
Per Cederberg schrieb:
Ok. I don't have any problems with $ or getElement, but then I'm using
Firefox and Safari with inline SVG. Are you using the Adobe plugin? I
think it would be good
)) });
connect ($(get-element-by-tag-and-class-1), onclick, function (e) {
logDebug (getElementsByTagAndClassName('rect', null)) });
connect ($(get-element-by-tag-and-class-2), onclick, function (e) {
logDebug (getElementsByTagAndClassName(null, 'rect-class')) });
]]
/script
/svg
Per Cederberg
I just ran across http://berniecode.com/writing/animator.html, which
seems to provide quite nice visual effects (similar to
MochiKit.Visual). Think there are a few transitions there that might
be useful for MochiKit.Visual too. And some nifty CSS class morphing.
Also, the actual examples are very
, if it was as slick as the Animation
library appears to be (I've only toyed with a few examples in a single
browser so far), I could totally see myself going back to it.
Jeremy
On May 22, 2:14 am, Per Cederberg [EMAIL PROTECTED] wrote:
I just ran acrosshttp://berniecode.com/writing/animator.html, which
[EMAIL PROTECTED] 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
seems redundant to me.
/Per
On Sun, May 25, 2008 at 3:27 AM, Christoph Zwerschke [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote:
Per Cederberg schrieb:
Question though, why add MochiKit.Style.getElementHeight
Think this a question for Bob, but I think it would be nice if we
could offer this. But that would of course only be version 1.3.1...
Which brings further motivation for pushing forward with a release of
version 1.4 (which I hope for before the end of August).
Personally, I don't see the Google
:
On Tue, May 27, 2008 at 9:14 PM, Per Cederberg [EMAIL PROTECTED] wrote:
We should probably offer this service, though.
If you have the means, that would be awesome. I imagine bandwidth
could quickly become a factor.
If you can provide this kind of hosting, you could even offer specific
SVN
The page works fine for me. Try Ctrl-R to force a reload (in FF).
Perhaps the browser is just caching a previous 404?
/Per
On Sun, Jun 1, 2008 at 7:42 PM, machineghost [EMAIL PROTECTED] wrote:
Anyone know why the DOM API page (http://www.mochikit.com/doc/html/
MochiKit/DOM.html) is down? I
getElementsByTagAndClassName (null, 'classname') = ok
getElementsByTagAndClassName (null, 'classname', 'parentid') = ok
where the element has one or two classnames (separated by space).
Thanks for the quick fix!
Helmut
Per Cederberg schrieb:
I've just committed a fix to MochiKit.DOM
Thanks! I'll apply this patch shortly to the svn repository. It will
be committed in parts, separating the actual mouse wheel stuff from
code fixing other issues in signal(), etc.
One question though. I see that the Mozilla event.details value is
considered equivalent to -event.wheelDelta / 40.
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 [EMAIL PROTECTED] wrote:
Per Cederberg
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
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
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
from
getElementDimensions for performance reasons I think.
Cheers,
/Per
On Wed, Jun 11, 2008 at 10:50 AM, Christoph Zwerschke [EMAIL PROTECTED] wrote:
Per Cederberg schrieb:
After investigating this, I think the main problem here was introduced
in revision 1383. That change introduced
(as the current version). That way, no
change would be needed to setElementDimensions at all.
Cheers,
/Per
On Wed, Jun 11, 2008 at 1:32 PM, Christoph Zwerschke [EMAIL PROTECTED] wrote:
Per Cederberg schrieb:
I did something similar once, but it is a bit of a pain to read 4
computed values (which
changes to trac.
On the MochiKit.Animator reference, I'm not seeing it in the mochikit
repository, I assume this is part of another repository or maybe not
in trunk. Hopefully I'm not duplicating any effort here.
On Jun 11, 4:14 am, Per Cederberg [EMAIL PROTECTED] wrote:
I've added the original
that and add the new patch with all current changes to trac.
On the MochiKit.Animator reference, I'm not seeing it in the mochikit
repository, I assume this is part of another repository or maybe not
in trunk. Hopefully I'm not duplicating any effort here.
On Jun 11, 4:14 am, Per Cederberg [EMAIL
Yes, well. I was thinking simpler is better. So I though a single flag
would be sufficient to either remove both padding and borders, or to
keep the values unchanged (as today). If someone wants more detail,
there is always the helper functions for retrieving padding and border
widths.
I was
packed/MochiKit/MochiKit.js
Cheers,
/Per
On Thu, Jun 12, 2008 at 2:31 PM, Ragnar Rova [EMAIL PROTECTED] wrote:
Is there a recommended way of combining MochiKit stable to a
single .js file to reduce the number of http requests?
--~--~-~--~~~---~--~~
You
9.5
o IE/Mac 6.0 (emulated in CrossOver)
I'd be interested to know if this works in MSIE 7 and FF 3 (on Windows).
http://mochikit.com/examples/mouse_events/index.html
http://mochikit.com/tests/index.html
Cheers,
/Per
On Thu, Jun 12, 2008 at 3:25 PM, Per Cederberg [EMAIL PROTECTED] wrote
({type:hidden, name:myName,
value:myValue});
2) var a = HIDDEN({name:myName, value:myValue});
3) var a = HIDDEN(myName, myValue);
Personally, I'd much rather have #3 in my code, especially if I'm
making a lot of INPUTs at the same time.
Jeremy
On Jun 11, 12:05 am, Per Cederberg [EMAIL PROTECTED
requiring them or invalidating
the standard syntax.
Jeremy
On Jun 12, 12:21 pm, Per Cederberg [EMAIL PROTECTED] wrote:
If I understand you correctly, I think createDOMFuncExt already
accomodates this:
CHECKBOX = createDOMFuncExt(null, input, [name], { type: checkbox });
HIDDEN
I haven't tried jQuery, but l find myself browsing through the
Prototype API:s from time to time. And as far as I can see, it seems
to provide much the same functionality like MochiKit, but with an
object-oriented syntax and approach (extending built-in object
prototypes with stuff that should
Use the content in the packed folder.
Cheers,
/Per
On Wed, Jun 18, 2008 at 8:06 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
I downloaded the release version. The basic file structure is:
/ - Changes, LICENSE.txt, MANIFEST, META.json
/doc
/examples
/include
/lib
/packed
/tests
,
/Per
On Wed, Jun 18, 2008 at 11:03 PM, Per Cederberg [EMAIL PROTECTED] wrote:
Use the content in the packed folder.
Cheers,
/Per
On Wed, Jun 18, 2008 at 8:06 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
I downloaded the release version. The basic file structure is:
/ - Changes
The MochiKit documentation sources are in rst format. See Python
docutils for information if something different than HTML can be
generated from that.
Cheers,
/Per
On Wed, Jun 25, 2008 at 12:59 AM, Prodoc [EMAIL PROTECTED] wrote:
I'd like to create a MochiKit add-on pack for the DevBoi
with just the core attrs
syntax would be better than one that can only set the name attribute.
Jeremy
On Jun 16, 12:20 am, Per Cederberg [EMAIL PROTECTED] wrote:
Ok, so perhaps we should modify createDOMFuncExt to treat the argument
array as a list of optional arguments? With scalar I suppose you
Check out the afterFinish property (works for all animations).
Assign it to an event handler function and off you go.
http://www.mochikit.com/doc/html/MochiKit/Visual.html#fn-base
Cheers,
/Per
On Sun, Jun 29, 2008 at 3:52 AM, Giulio Cesare Solaroli
[EMAIL PROTECTED] wrote:
Hello,
I have
Could you provide a simple example on how this MochiKit.DOMSelector
class is supposed to be used. Compared to the current way to do
things.
I agree that there is some utility to mixing in additional functions
into DOM objects, like for instance Prototype does. But I'm not so
sure that it should
Sorry to hear that you are discontent with MochiKit and are migrating
away from it. But I do understand your reasoning. Development has been
pretty stagnant here for a while, since we are only a small community
with a serious lack of developer time.
It has not been my intent to discourage
21, 11:08 am, Per Cederberg [EMAIL PROTECTED] wrote:
Could you provide a simple example on how this MochiKit.DOMSelector
class is supposed to be used. Compared to the current way to do
things.
pre
// hide all DIV elements with CLASS hideme
MochiKit.get('div.hideme').fade({from: 1.0, to: 0.0
The Highlight effect must modify the style, but there should be an
option to restore any modified style after completion. Actually, there
is an undocumented restoreAfterFinish flag for the Scale effect that
does just that.
Perhaps what we should do is to add support for such a flag to all the
Slow response here, sorry. I think the behavior you describe below
merits a bug report:
http://trac.mochikit.com/ticket/318
Cheers,
/Per
On Mon, Jun 30, 2008 at 10:12 PM, diefans [EMAIL PROTECTED] wrote:
hello,
since IE is complaining (stopping execution of running function) about
bad
. MochiKit.Query.select - a function that returns instance or Query
3. MochiKit.select = MochiKit.Query.select
Regards
..
Amit Mendapara
On Aug 27, 3:39 pm, Per Cederberg [EMAIL PROTECTED] wrote:
Ok, I think I understand how you mean. Don't think it is a bad idea,
but it is partially breaking
See http://trac.mochikit.com/report/3 for the bug report summary. I've
been occupied elsewhere most of the summer, so not much progress there
from me. Hope to start working on MochiKit again next week or so.
I guess people might object to a MochiKit.Widget module due to
footprint. My current
After the recent discussions on the list, I thought it best to publish
the draft MochiKit.Widget module that I've been working on:
http://github.com/cederberg/mochikit-patches
Please consider the following issues before using the above code:
o No MochiKit-style documentation (currently using
It is a bit hard to comment this without seeing the API:s or so.
Personally, I'm not a fan of chained API:s, so other people are sure
to value that more than me. But what would be interesting is a jQuery
compability module, mapping jQuery calls into MochiKit ones. At least
so that some jQuery
I guess it is just a matter of taste, but I'd use
MochiKit.DOM.replaceChildNodes instead of multiple insert and remove
calls.
Cheers,
/Per
On Mon, Sep 8, 2008 at 3:44 PM, Amit Mendapara [EMAIL PROTECTED] wrote:
Yes, exactly. In that case:
var old = $('thisisatd');
var tr = TR(null);
var
I guess this is a question for Bob, but others might have some clues
here also. Thus sending it to the list.
I've recently done some Python coding and found the % string formating
there very convenient. Now, as MochiKit is so inspired by Python, I
find it a bit odd that there is no generic
Thank you everyone for the interesting comments. I had a look at PEP
3101 (Python 3), the (new) Java 1.5 Formatter API and a popular
sprintf implementation for JavaScript. And in the end, it seems hard
to strike a good balance between readable syntax, power features and
localization. Actually, I
The draft version of MochiKit.Format.format() and formatter()
functions are now ready for testing. They are not documented much,
except for my previous email in this thread. And the API shouldn't be
considered stable.
So I push the bits into my temporary patch repository instead:
The packed version of MochiKit still doesn't include the modules
DragAndDrop and Sortable. I found a previous discussion of that in
this thread:
http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99
None of the two modules have been much modified lately,
Perhaps the problem is that you've already used bindMethods on the
Helper class before subclassing? That might break the inheritance
depending on how the code looks, since it reassigns the this object
pointer to another instance.
Also, you must use the new keyword, or it won't work:
While fixing some stuff in MochiKit.Logging, I happened to notice the
existance of a MochiKit.Test package... It seems pretty similar to the
SimpleTest.js file used for powering the normal test suite when run
inside a browser, but it seems to only be used when standalone testing
is performed
Ok. I added an enhancement ticket so that I won't forget about it:
http://trac.mochikit.com/ticket/320
Thanks for the info!
/Per
On Wed, Oct 8, 2008 at 4:20 PM, Leo Soto M. [EMAIL PROTECTED] wrote:
On Wed, Oct 8, 2008 at 9:46 AM, Per Cederberg [EMAIL PROTECTED] wrote:
While fixing some
On Wed, Oct 8, 2008 at 4:26 PM, troels knak-nielsen [EMAIL PROTECTED] wrote:
9.50 Alpha .. 8 failures in test_MochiKit-Style.html
not ok - initial x position: got 444, expected 400
not ok - initial y position: got 111, expected 100
not ok - updated x position: got 544, expected 500
Well... I think your case here is pretty uncommon. This is because the
__dom__() function is really supposed to create a *new* DOM node.
Otherwise people might run into issues when adding an object twice
into the DOM tree.
But sure, there is an inconsistency here. My suggestion would be to
just
On Thu, Oct 9, 2008 at 6:50 PM, Jason Bunting
[EMAIL PROTECTED] wrote:
Well... I think your case here is pretty uncommon. This is because the
__dom__() function is really supposed to create a *new* DOM node.
Otherwise people might run into issues when adding an object twice
into the DOM tree.
with MochiKit.Selector while testing
MochiKit.Query module. As `Per Cederberg` is preparing for 1.4
release, I think MochiKit.Selector should not be included in 1.4, but
let we get something really useful with Sizzle which is going to be
integrated in MochiKit (hopefully MochiKit 1.5)...
- Amit Mendapara
On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara
[EMAIL PROTECTED] wrote:
Once, I filed a bug report on the trac (related to Sortables), but I
was unable to change/comment it later. That's why I never submitted
again.
Yes, this is very unfortunate. I used to have the same problem, so I
hear
:38, Per Cederberg [EMAIL PROTECTED] wrote:
The packed version of MochiKit still doesn't include the modules
DragAndDrop and Sortable. I found a previous discussion of that in
this thread:
http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99
None
Google code seems fine by me. Especially if we get better access for
normal users.
The only issue I come to think of is that the mochikit.com web site
automatically updates from svn trunk. Don't know if it would be easy
to keep that link. Something which is pretty good to have from time to
time.
On Mon, Oct 13, 2008 at 2:24 PM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Minor usability pointer: When unselecting a module, instead of
unselecting everything that depends on it - highlight the relevant
part of uses XXX of those in some /error/ color.
I fooled around a bit with the visual
On Wed, Oct 15, 2008 at 1:01 PM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Done. Yup, the number of nodes is not correct (or at least as correct
as th other frameworks). Performance takes a minor hit, mainly because
it is so bad to begin with :)
Ah, you mean now correct... :-)
Disturbing that
:21 AM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Hi Per,
On Wed, Oct 15, 2008 at 10:15, Per Cederberg [EMAIL PROTECTED] wrote:
On Wed, Oct 8, 2008 at 9:28 PM, Arnar Birgisson [EMAIL PROTECTED] wrote:
div p
MK trunk returns 142 elements while others return 140 (both numbers
are reported
Hi everyone,
This is just to say that I'm still planning to do the MochiKit 1.4
release on the 21:st of October. All outstanding bugs remain fixed and
I've heard of no test breakage. Please let me know if you find any
last-minute-issues.
Cheers
/Per
Noone has opinions on this?
Cheers,
/Per
On Wed, Oct 8, 2008 at 3:51 PM, Per Cederberg [EMAIL PROTECTED] wrote:
The two functions MochiKit.DOM.isChildNode and isParent have both been
added in version 1.4 of MochiKit (not yet stable). But they are
virtually identical (except for a few bugs
Attempting two answers in one below...
On Sat, Oct 18, 2008 at 12:23 AM, Jason Bunting
[EMAIL PROTECTED] wrote:
Who is Noone? :P
Sigh... The endless joys we bring you native English speakers... ;-)
On Sat, Oct 18, 2008 at 5:54 PM, Christoph Zwerschke [EMAIL PROTECTED] wrote:
Hm, if I read
Ok, since r1433 MochiKit.DOM.isParent is no more.
/Per
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group,
Of course, FF 3.1 includes querySelectorAll:
http://ejohn.org/blog/queryselectorall-in-firefox-31/
And in fact, there is a slight bug in Sizzle here, causing it to not
use that version when not sending in an explicit 2:nd argument:
Sizzle(..., document)
The problem is here:
if (
MochiKit 1.4 has now been released and is available on the web site:
http://mochikit.com/download.html
The full change history from version 1.3.1 is rather lengthy, but you
can find it on our web site:
http://mochikit.com/doc/html/MochiKit/index.html#version-history
As far as I know,
My guess would be that the speed difference stems from the Sizzle
strategy of searching inside-out from the expression. I.e. using the
last part of the query first, and then filtering that set using the
previous parts. Perhaps other libraries search outside-in?
In the case of ul .tocline2 the
to reluctantly inaugurate a
brand new svn branch for 1.4. Please add any regression fixes to 1.4
there (and drop a mail on the list).
Thanks,
/Per
On Fri, Oct 24, 2008 at 8:51 AM, Per Cederberg [EMAIL PROTECTED] wrote:
Yes, I noted the same thing yesterday. Seems to be an issue
(on Linux). Please make sure that it's packaged properly
with correct access permissions.
- Amit Mendapara
On Oct 21, 3:32 pm, Per Cederberg [EMAIL PROTECTED] wrote:
MochiKit 1.4 has now been released and is available on the web site:
http://mochikit.com/download.html
The full change
Actually, I think the documentation for roundElement and roundClass
should be clearer regarding these limitations. From reading the docs,
it is not obvious that only block elements are accepted (my guess).
And what do these methods really change in the DOM tree? A simple
explanation might help
On Mon, Oct 27, 2008 at 11:34 AM, SanderElias [EMAIL PROTECTED] wrote:
ltrim -- Trims all the left spaces in a string
rtrim -- Trims all the right spaces in a string
alltrim -- Trimms all (left an right) spaces in a string.
These are available as strip(), lstrip() and rstrip() in
I just ran into a bug that I can't resolve. At least I'm out of ideas right now:
http://trac.mochikit.com/ticket/325#comment:2
The problem is when using getElementDimensions() on elements having
display: none set in the CSS class. Or in a parent element. Is there
a work-around for this? Or
1 - 100 of 173 matches
Mail list logo
