If setting the expando to a function, rather than a boolean, prevents
it from persisting when it should not, then that's fantastic. It'd
also solve the similar problem where cloned nodes say they're extended
but are not. Write a patch!
Andrew
On Feb 8, 12:05 pm, Mislav Marohnić [EMAIL
Thanks for the compliments, guys.
Alex Russell's post on the subject (http://blog.dojotoolkit.org/
2007/02/04/dojoquery-a-css-query-engine-for-dojo) has stirred some
diplomatic talks. It looks like Alex, John Resig, Jack Slocum, Dean
Edwards, and I are going to pitch in toward some sort of site
On Feb 18, 12:22 pm, Marius Feraru [EMAIL PROTECTED] wrote:
So, the only issue still standing in this paragraph is how to detect
different versions. People [1] think the right choice is not browser
detection, but object detection. This is a very weary subject, I don't
really want to reiterate
If you bleeding-edgers do an SVN update you'll notice that there's a
new selectors branch. The version of selector.js contained therein is
another major advancement from the previous version (attached to patch
#7658). Christophe's excellent code reviews and revisions have been
indispensible;
On Feb 23, 4:37 pm, Colin Mollenhour [EMAIL PROTECTED] wrote:
Man this is getting annoying.. I wish json.org would change their code
or Prototype would use $H().each in setRequestHeaders or both
(preferable) would happen soon. This is popping up on Rails Spinoffs
at least twice a day it
#4 looks fine to me.
On #1 and #2: perhaps the answer is...
{ foo: undefined } = foo=
{ foo: null } =
I don't know if this is useful or not, but it would allow you to
distinguish between these two cases, since null and undefined are
distinct values with different meanings.
I have no opinion
You act as if the web isn't built upon conventions, even arbitrary
ones.
I think this is a POLS issue, only we disagree on which behavior is
least surprising. But since Prototype is designed to go hand-in-hand
with Rails, and since JavaScript methods can be redefined at runtime,
I think the
want this to be
decided only by the handful of people who've posted in this thread.
Cheers,
Andrew
On Mar 15, 6:30 pm, Marius Feraru [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Dupont wrote:
You act as if the web isn't built upon conventions, even arbitrary
This is what I came up with for the XPath version: http://pastie.caboo.se/47671
It's a direct port of the logic of parseNth (albeit not yet tested).
I'll look at yours and see if it makes more sense, though.
Cheers,
Andrew
On Mar 17, 4:51 pm, Trevan Richins [EMAIL PROTECTED] wrote:
Andrew
That's an interesting idea.
Parts of CSS3 parser could be reused. You could certainly use the
regexen we define to identify various CSS tokens.
My first thought was that combinators should not be allowed in that
syntax (i.e. new Element('div#mynode div.someClass'), but then I
suppose you could
After a whole bunch of heated discussion about a subject that I had no
idea was so controversial, my inclination is to stick to a very spec-
compliant and unambitious Hash serializer for 1.5.1.
Those who need more out of their serialization (proper handling of
nested hashes, arrays, etc.) can
I don't know much about the code in question, but I believe those
catch blocks are in place to intercept thrown exceptions that are
extraneous (i.e., can occur sporadically without changing the result
of the code or have no bearing on the result). I can't be sure,
though, so let's take them one
Dan Webb wrote:
It's not a bad cause, I just think the solution is a performance eater.
Imagine: the loop runs on every object instantiation. It wraps every
function inside another and it needs $A for that. After that, every function
call internally calls another, triggering $A one more
Would it? ;)
The new Event code binds whatever it gets in IE to someElement. It doesn't
know anything about Foo.
I wasn't being very clear -- sorry. Those first two examples
illustrate what would happen if we implemented *both* the stuff in the
events branch as it is now *and* Dan's
On May 23, 7:16 am, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
With the latest prototype (1.5.1), the next() function (and probably
also prev() and the rest of the navigation function) cause a
tremendous slowdown in IE if they are used with the following syntax:
next(Number). From what I saw
On May 24, 5:53 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
Andrew, it doesn't matter - getElementsByClassName tends to extend EVERY
node in the document! If that isn't slow I don't know what is.
No, it doesn't. It extends only those nodes that match the class
name. I've personally spent
On Jun 3, 9:06 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
That doesn't make any sense. element.form.serialize should work in
FF andOpera because they support native DOM prototypes. It
shouldn't work in IE because the form element is not DOM extended by
Prototype. And now you're telling us
On Jun 17, 8:34 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
Am I right when saying that this will fail if the ID was dynamically set (in
other words, it was not an attribute in HTML source)?
Adam's test is correct -- even dynamically-set ID attributes will
still be picked up by readAttribute
On Jun 18, 2:01 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
There are only 3 possible options we're facing:
1. Don't change the $ function, leave everything as-is;
2. Fix the issue in $ by using $$('*[id=foo]');
3. Don't fix the issue, throw error instead.
My vote is for #1. The $
On Jun 21, 6:30 am, Rebecca Blyth [EMAIL PROTECTED] wrote:
Finally, an aside on not having control over the HTML source:
I ran into this issue when using the radio_button_tag helper method in
Rails, which inconveniently used the name of the input as the id -
unhelpful, as all the radio
On Jun 21, 2:35 pm, sed [EMAIL PROTECTED] wrote:
I'm not sure why this worked before, it must be related to the html/
script being generated into the div from the ajax.updater rather than
just being on the page.
Nope. It's sillier than that. Let's say you've got an element with an
ID of foo
It's got nothing to do with luck. Arrays are implemented as a very
light veneer on top of Objects; the only real difference between them
is the literal syntax ([]) and the magic length property that counts
your numeric keys. (In fact, the numeric keys aren't really numbers,
since all object
On Jun 25, 4:41 am, Gareth Evans [EMAIL PROTECTED] wrote:
Is Base an option for the naming of the parent class?
I'd vote against it assiduously. It was my problem with Dean's
original naming as well. In a deep class structure (Organism Animal
Cat) it implies that the method being called is
I agree with everything Mislav said and would adopt that syntax in a
heartbeat.
My only concern is with the signature of Class.create and
Class.extend. I feel like having instance methods and class methods in
adjacent arguments can hurt the readability of the code. If you're
skimming a file you
On Jun 25, 11:29 am, Ken Snyder [EMAIL PROTECTED] wrote:
I'd also like to throw in the idea that we need to prove the final
OO-design decisions with use cases. We can write animal-sounds code all
day long, but JavaScript is such a unique language, I think we ought to
prove the design by
for(element in elements) {
That's the problem. Use elements#each [1] or a for loop with an index
to iterate through arrays. You can read more about this issue here
[2].
Cheers,
Andrew
[1] http://prototypejs.org/api/enumerable/each
[2]
On Jul 4, 1:52 pm, Vincent [EMAIL PROTECTED] wrote:
I agree on the multiple declaration syntax, but in the cases above,
those variables have already been declared earlier in the code and are
simply assigned new values in the reported lines.
Yeah, it's a mistake, but it's an innocuous one.
Have you tried *[id='myForm:myName']? That ought to work, though it
wouldn't surprise me if it did not.
A colon is a valid character in ID attributes, so it should be
supported. Part of me thinks that the attribute selector approach (if
it works) would be sufficient -- but another part of me
No - that'd be incorrect in both cases. Semicolons are needed when a
line is ended with the closing brace of a function literal or object
literal, but not when a line is ended with the closing brace of a
control structure.
Cheers,
Andrew
On Aug 7, 1:09 pm, Mislav Marohnić [EMAIL PROTECTED]
This is probably the most glaring flaw in RC0: any event types that
are not part of the DOM L2 Events spec, but are nonetheless honored by
one or more browsers, are handled incorrectly by Prototype as custom
events.
We've got to figure out a way around this, even if it means we create
a
On Aug 31, 2:12 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
On 8/31/07, Jeff Watkins [EMAIL PROTECTED] wrote:
Let me see if I'm getting this correctly. You are saying that you need to
inject content in the DOM received by XHR ... while the current page is
still being loaded? That is
On Sep 1, 5:18 pm, Nicolás Sanguinetti [EMAIL PROTECTED] wrote:
Anyway, the custom event solution seems tidy enough. What do the w3c
specs say on xmlhttprequests and contentloaded, if anything?
They don't. Despite its name, the DOMContentLoaded event is not part
of any standard.
That very blog post points to HTML5 work on the issue. If you're
brave, Mislav, you could ask for a spec clarification on the HTML5
mailing list.
Cheers,
Andrew
On Sep 5, 10:20 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
On 9/5/07, jdalton [EMAIL PROTECTED] wrote:
I just saw a post on
The CSS2 and CSS3 specs disagree on this, annoyingly enough. [1] I'd
originally written :not to throw an exception on selectors with more
than one token, but then I saw the conflicting definitions and
relented. All the other major libraries seem to allow this confusing
syntax.
Not being able to
Historically the JS libraries haven't seen enough patch volume to
justify the process overhead. I feel like we're turning the corner
there, though; we should probably start following the Report 12
process for Prototype. What does the rest of Core think?
Any message that proposes a new feature is
I'm not crazy about it. Deviations from the CSS3 spec are troublesome
because they're not discoverable and they violate POLS. If we're going
to go down that slippery slope, selector.js will get even larger than
it already has.
The extended Enumerable#grep semantics in 1.6 make kangax's
Prototype script.aculo.us don't release official compressed
versions, but there are a few different people who make unofficial
compressed versions for each major release. I'm sure one will be
available shortly after the 1.6 final release (which will be soon).
Cheers,
Andrew
On Nov 1, 8:25 pm,
There are other popular scripts that rely on this behavior, most
notably Dean Edwards's original base.js inheritance script.
It should also be noted that this behavior does not comply with
ECMA-262, which states that Function.prototype.toString shall return a
string that has the syntax of a
On Nov 22, 10:29 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
Because of the silence of other core members at the moment,
Keep in mind the western faction has been asleep, and it is a holiday
in America. ;-)
it would be best
for you to make a plug-in script that is included after
The Selector class translates to XPath in browsers that support it.
Some of the Selector unit tests failed in Safari 3 -- seemingly because
WebKit doesn't correctly implement some XPath functions. If I recall,
the failures are related to the :first-of-type/:first-child
pseudoclasses (and their
I think our official recommendation is that anyone who needs
Event.unloadCache should write it and make its contents the same as
that of destroyCache. The code duplication is small enough that it
doesn't bother me; anyone who's doing proactive GC probably has
written enough JS already that they
I think he meant it as a workaround, not as a bug fix.
Thanks, David!
Cheers,
Andrew
On Jan 10, 11:06 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
In other words, you eliminated the cache?
We would rather fix the problem than lose the cache (and the speed increase
it provides). You could
On Jan 29, 3:41 am, artemy tregoubenko [EMAIL PROTECTED]
wrote:
Well, I'm using this one:
Object.extend(String.prototype, {
parseInt: parseInt.methodize(),
parseFloat: parseFloat.methodize(),
});
Clever. :-)
In ECMAScript 4, parseInt and parseFloat are becoming static
On Mar 27, 9:29 pm, Nouv Vitou [EMAIL PROTECTED] wrote:
But if I have two different domains taiyocambodia.com and khmer-web.com.
I would like to use the session to be used for both. How can I?
Can't do it with cookies. Track your sessions on the server-side.
Again let me suggest that this
http://github.com/sstephenson/prototype/
http://github.com/madrobby/scriptaculous/
Those are the GitHub pages for Proto/Scripty, respectively. Those
pages have the repo URLs for each — or you can download tarballs from
there if you're not keen on git.
Everything else works the same way.
[1] http://msdn.microsoft.com/en-us/library/ms536956(VS.85).aspx
[2] http://msdn.microsoft.com/en-us/library/ms536910(VS.85).aspx
(Just pretend I included these in the original message.)
On Jun 12, 8:20 pm, Andrew Dupont [EMAIL PROTECTED] wrote:
On Jun 12, 5:46 am, Nick Stakenburg [EMAIL
I think this was during the one day that Lighthouse's spam
verification service went down and it was marking everything as spam.
Would you mind re-submitting the ticket? I can't seem to find a way to
un-mark it.
Thanks,
Andrew
On Sep 1, 9:34 am, Ihárosi Wiktor [EMAIL PROTECTED] wrote:
Hi,
I
I believe we've fixed this since 1.6.0. Update to 1.6.0.2 and see if
it still happens.
Cheers,
Andrew
On Sep 2, 8:47 am, therutz [EMAIL PROTECTED] wrote:
Using prototype.js 1.6.0 and Firefox 2.0.0.x and Event.element()
returns the wrong element. Instead of an HTMLImageElement it's
returning
On Sep 22, 7:16 pm, Valentin [EMAIL PROTECTED] wrote:
I didn't hijacked anyone's thread. This is about the upcoming 1.6.0.3
so what I posted is directly related. The purpose of a JS library is
to 1) provide compatibility among browsers using the same code 2)
reduce the time the programmer
Google's version is gzipped. Prototype 1.6, when gzipped, is only 28K
over the wire. And with Google's content distribution network and
proper cache settings, it'll be downloaded only once. This is what
people should be using if they want a compressed version.
I shall end the shitstorm here and now.
To quote the rhino book:
Once we've created a string object S [through `new String`], what can
we do with it? Nothing that we cannot do with the corresponding
primitive string value. If we use the `typeof` operator, it tells us
that S is indeed an object,
for the `typeof` problem.
If the fix weren't so simple I'd have pushed back hard.
Cheers,
Andrew
On Oct 8, 2:15 pm, Tom Gregory [EMAIL PROTECTED] wrote:
On Oct 8, 2008, at 11:29 AM, Andrew Dupont wrote:
I shall end the shitstorm here and now.
... he probably can't think of a single case
Only in the sense that Prototype seems not to be safe to use inside a
Firefox extension. But even that isn't clear. I posted in the thread
to try to cut through the hearsay and speculation. Thanks, Richard.
Cheers,
Andrew
On Oct 14, 8:49 am, Richard Quadling [EMAIL PROTECTED]
wrote:
Hi.
Write up your proposed additions in a text file, create a ticket on
Lighthouse, and attach your additions as a patch.
Thanks!
Cheers,
Andrew
On Oct 13, 1:08 pm, ijayasin [EMAIL PROTECTED] wrote:
Hi,
I was wondering how people could contribute to the Prototype
documentation.
One part of
Here's what this would look like when genericized into an imaginary
API: http://gist.github.com/24571
A couple of things:
(1) I'm altogether in favor of this new approach, but it will result
in less implicit organization of code. A reader of the code will
likely find it harder to scan for the
On Nov 16, 1:58 am, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Here is my take,
I'm also altogether with this incoming pattern.
PDoc blocks could indeed demarcate those sections, and be used to
provide (browser|feature)-specific technical documentation.
My proposal is the following
I'm thinking about how we can flatten the learning curve. If you were
to teach someone how to use Prototype in 10 incremental steps, what
would they be?
I've got only nine so far, but here they are:
1. Master the $ Function
2. Use instance methods to perform common tasks on elements
3. Master
On Nov 18, 4:11 am, T.J. Crowder [EMAIL PROTECTED] wrote:
That list falls neatly into two categories: Basic techniques not
requiring *too* much in terms of conceptual understanding (the first
five items), then more conceptual (and powerful) stuff (the last five
items). I probably would
I've just committed a couple large API additions in a layout branch
in our Git repository:
http://github.com/sstephenson/prototype/tree/layout
http://github.com/sstephenson/prototype/blob/9d28f04d98307f652a2d85ff35e869f2e0ac7f38/src/dom/layout.js
It's still very preliminary, but Element.Layout
to and pointed TEMP/TMP at it instead. The directory got
used, but I got the same result.
-- T.J. :-)
On Mar 31, 6:23 am, Andrew Dupont goo...@andrewdupont.net wrote:
Christ, that's weird. It's saying you don't have permission to read
the temporary file we create to build
*headdesk*
Had local changes to my PDoc checkout that I had not pushed back to
the repo. Fixed now.
git pull git submodule update
...should do the trick.
Cheers,
Andrew
On Apr 3, 9:28 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Richard,
I'm really stumped here. I wonder if the
is a bug in Sprockets that I've
passed along to Sam, so expect a fix for that sometime soon.
T.J., let me know if you have any further problems.
Cheers,
Andrew
On Apr 3, 11:22 am, Andrew Dupont goo...@andrewdupont.net wrote:
*headdesk*
Had local changes to my PDoc checkout that I had not pushed
Language Section from the menu, if I click
on $A on the Utilities line on the page, I get a 404 for language
\dollara.html.
Haven't had a chance to try Ubuntu yet.
-- T.J.
On Apr 3, 6:56 pm, Andrew Dupont goo...@andrewdupont.net wrote:
OK, once I commented out that File.utime
On Apr 8, 2:26 am, Richard Quadling rquadl...@googlemail.com wrote:
Having refreshed my prototype checkout (along with the submodules),
the sprockets issue is still present.
Ball's still in Sam's court on that one. If it doesn't get fixed soon
I'll ask him for commit access to the Sprockets
On Apr 16, 10:44 am, mr_justin gro...@jperkins.otherinbox.com wrote:
Has the topic ever came up to add the ability to serialize elements of
a form just but only within a certain container element?
Not as such, no. But we've had thoughts to make the serialization
logic itself pluggable. The
On Jun 4, 2009, at 8:36 PM, Luisgo wrote:
1. Is there a better way to handle callback definition? See lines
7-11.
You've got the right idea here. I'd use `Prototype.emptyFunction`
instead because there's no reason to define more than one empty
function, but this is of negligible
On Sep 13, 2009, at 5:24 PM, T.J. Crowder wrote:
This is already fixed in the latest trunk and so will be fixed quite
soon the next time the docs are re-generated from the source.
In fact, I re-generated the docs earlier today.
Cheers,
Andrew
Unless anyone has serious objections, or has a better idea, I'm going
to add these as aliases of `Prototype.emptyFunction` and
`Prototype.K`, respectively. They belong better there, since in theory
the `Prototype` namespace is for internal stuff, not for stuff that
has value to end-user
We've talked about doing this before, but there are a couple problems.
First, we can't do what you're suggesting for Element#remove — the
function returns the removed element, which may then be appended
somewhere else in the document. If the element is going to be
discarded, then one ought
Weighing in again, decades after starting the thread.
First, I'm fine with calling it Function.IDENTITY instead of Function.K.
On Sep 25, 2009, at 1:26 AM, T.J. Crowder wrote:
Make sense. Shouldn't that be Function.empty and Function.k, though,
to follow our naming rules? And perhaps
the only one who thinks of them that way, I'll shut up.
But I want to hear from more people.
Cheers,
Andrew
-- T.J. ;-)
On Oct 15, 1:08 am, Andrew Dupont goo...@andrewdupont.net wrote:
Weighing in again, decades after starting the thread.
First, I'm fine with calling it Function.IDENTITY
Yes, the Element.Layout class is imminent. In fact, it's already here.
Take a look:
http://github.com/sstephenson/prototype/blob/layout/src/dom/layout.js
I've posted layout code before; this is the same code with a couple
more refinement passes. You can read the included PDoc comments to get
an
On Nov 3, 2009, at 3:54 AM, Richard Quadling wrote:
According to [1], you will get a string back, not an array of strings.
Nope — that's the notation for returning an array of strings.
Can you supply an example page?
I second this request.
Cheers,
Andrew
Thanks, Joran. We have plans to start from scratch with Ajax in
Prototype 2.0; I think our ideas are mostly along the same lines as
yours.
I also want to fix some of the annoyances of the current API,
hopefully for 1.7.
Cheers,
Andrew
On Dec 11, 2009, at 7:07 AM, Joran Greef wrote:
On Feb 8, 12:22 pm, Clint Priest cpri...@warpmail.net wrote:
I've been playing with getters and setters lately, namely the get
XXX() { } and set XXX(value) { } format and I've noticed that
prototype 1.6.1 doesn't play well with them.
What doesn't work, specifically? I have a couple ideas,
I like this. I don't particularly care what we call it.
Too late for 1.7, naturally, but perhaps 1.7.1 or 1.8...
Cheers,
Andrew
On Apr 23, 2010, at 10:15 AM, Mislav Marohnić wrote:
On Fri, Apr 23, 2010 at 15:00, Titi Alailima tigreti...@gmail.com wrote:
debounce is a technical term, and it
I think jQuery figured out a solution for this — care to do some research,
Mislav?
Cheers,
Andrew
On Apr 23, 2010, at 12:45 PM, Mislav Marohnić wrote:
The submit event doesn't bubble up in Internet Explorer after it originates
in a form. That makes it impossible to catch with event
Tom, the margin-height key does the same thing.
Cheers,
Andrew
On May 9, 2010, at 8:02 AM, Tom Nijns wrote:
Hi,
I love the new measure and layout features but like to see something
added.
When creating userinterfaces, I regulary need to know the surrounding
height or width of an element
I can't say that we're considering adding this into core, but seems
like it would be an excellent plugin. I know I'd use it.
Cheers,
Andrew
On Jul 6, 12:38 pm, John W. Long m...@johnwlong.com wrote:
Yes please. Better support for CSS rules would be awesome.
--John
On Thu, Jul 1, 2010 at
Well, this is the entire change; only unit tests are missing, and I think we
can add those ourselves if need be. Thanks, Andy!
I think this is small enough that it can still make it into 1.7 (which we're
days away from releasing), but others may disagree.
Cheers,
Andrew
On Oct 20, 2010, at
This is great stuff. Due to its breadth, however, it will have to wait until
1.7.0.1, for which we've got a bunch of other ES5-compatibility fixes planned.
If you and kangax think it would be worth getting the initially-proposed fix
into 1.7, then I'll try my best to do so.
Cheers,
Andrew
On
It doesn't sound like it's a JSON issue.
Can you set a breakpoint on the first line of _destroyCache and see what path
it's taking through the code? That function shouldn't get anywhere near the
call stack limit, so I suspect there's accidental infinite recursion happening
somehow.
Cheers,
On Mar 3, 2011, at 2:40 AM, andris wrote:
The question is, should Prototype address it or is it a developers
problem? Isn't the work of a JS library to smooth out these kind of
inconsistencies - for example either falling back to a non native
encoder with WebKit or forcing other browser to
I had to look it up, because that's part of Sizzle [1], but accessing that
property does have a side effect, apparently. It makes the `selected` property
work correctly when something is selected by default.
That strikes me as a spurious thing for GCC to warn about — you wouldn't
typically
On May 18, 2011, at 3:22 AM, Richard Quadling wrote:
OOI, the Sizzle code wraps the access in a condition. Should this be
ported to Prototype?
We'll update to the latest version of Sizzle when we release 1.7.0.1.
--
You received this message because you are subscribed to the Google Groups
85 matches
Mail list logo
