[Prototype-core] Re: function for script loading

2008-11-19 Thread Tobie Langel
Why not use JSLoad directly ? Best, Tobie On Nov 19, 12:41 pm, Yaffle [EMAIL PROTECTED] wrote: hello I can't find in prototype.js function, that can load javascript such as jsload http://code.google.com/p/jsload/downloads/list It may be very useful. How about add to prototype lite

[Prototype-core] Re: $$ function needs context attribute?

2007-10-17 Thread Mislav Marohnić
On 10/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think is is good to create a new function called $$$ or something like that to make a short selector function and supports context. We use Element#select to constrain the lookup to a certain element: $(foo).select(img) We

[Prototype-core] Re: $$ function needs context attribute?

2007-10-17 Thread [EMAIL PROTECTED]
Oh, the select method, I haven't use it, and the context is important for the css selector, and in the case Selector.findChildElements supports the context, So only change the $ $ function and to check whether the last argument is HTML element or not is enough. And context is really very

[Prototype-core] Re: $ function

2007-06-28 Thread Rebecca Blyth
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 buttons in a group have the same name in order to group

[Prototype-core] Re: $ function

2007-06-24 Thread [EMAIL PROTECTED]
I'd like to add a bit of OT to the discussion, but relating to the $ function itself. Currently, $ wil not return an element, whose id is a number, whereas getElementById will. The fix, as you can imagine, is pretty simple. I myself just changed the following line: if (typeof element ==

[Prototype-core] Re: $ function

2007-06-24 Thread Mislav Marohnić
On 6/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Currently, $ wil not return an element, whose id is a number, whereas getElementById will. A number is an illegal ID value. --~--~-~--~~~---~--~~ You received this message because you are subscribed to

[Prototype-core] Re: $ function

2007-06-24 Thread Tobie Langel
As advised here: http://www.w3.org/TR/html401/types.html#type-name ID and NAME tokens must begin with a letter ([A-Za-z]) [...] Which clearly implies that ids cannot be number only. On Jun 24, 1:25 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'd like to add a bit of OT to the

[Prototype-core] Re: $ function

2007-06-22 Thread Andrew Dupont
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

[Prototype-core] Re: $ function

2007-06-21 Thread Rebecca Blyth
I know I'm a little late on this one, but as the person who originally filed the bug report, I thought I'd put in a word... Personally, I'm happy with leaving the $() function untouched. People who get caught out by it will now be able to see what the problem is and what the workarounds are, and

[Prototype-core] Re: $ function

2007-06-18 Thread Mislav Marohnić
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: input type=text value=this should be returned name=test id=www / input type=text value=this should not be returned ff2.0 bug not appeared in ff3.0 a5 name=test id=www / This is not valid HTML. It has 2 different elements with the same

[Prototype-core] Re: $ function

2007-06-18 Thread [EMAIL PROTECTED]
My solution, maybe too complicated, one path for opera which is pretty good and with good performance, the path for internet explorer which is complicated, and for my testing it is stable, hope it can make $ to be much more cross-browser, I believe the js framework should fix the browser's bug,

[Prototype-core] Re: $ function

2007-06-18 Thread Mislav Marohnić
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My solution, maybe too complicated, one path for opera which is pretty good and with good performance, the path for internet explorer which is complicated, and for my testing it is stable Your solution may suit you but we will not

[Prototype-core] Re: $ function

2007-06-18 Thread [EMAIL PROTECTED]
The only solution that could be faster than this is to temporary delete the name of the found element and repeat the $() call, after which the name would be restored. Unfortunately it isn't possible. I think my solution is something like what you said, I doubt it will get a better performance,

[Prototype-core] Re: $ function

2007-06-18 Thread Tobie Langel
And for my solution, it is too ugly, I won't use it, just prove you can change the name and fix it. Ya, unfortunately, in the process you've also removed any event handler that could have been set on the element. --~--~-~--~~~---~--~~ You received this message

[Prototype-core] Re: $ function

2007-06-18 Thread [EMAIL PROTECTED]
Tks, I quite do not understand outerHTML, oh this would remove all the event handlers, in opera only change name attribute won't remove the event handlers? I think so. IE, misbahaving make me confused on you, why does IE implement the DOM basic method like this, any reasonable reason? Thanks ;)

[Prototype-core] Re: $ function

2007-06-18 Thread Tobie Langel
outerHTML is proprietary... so we can't really say it misbehaves ;) On Jun 18, 6:23 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tks, I quite do not understand outerHTML, oh this would remove all the event handlers, in opera only change name attribute won't remove the event handlers? I

[Prototype-core] Re: $ function

2007-06-18 Thread [EMAIL PROTECTED]
Not only IE and Opera, of course firefox, look at this code script src=prototype.js/script input type=text value=this should be returned name=test id=www / input type=text value=this should not be returned ff2.0 bug not appeared in ff3.0 a5 name=test id=www / script alert($(www).value)

[Prototype-core] Re: $ function

2007-06-18 Thread Mislav Marohnić
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Not only IE and Opera, of course firefox, look at this code Dude, I told you ... you have 2 elements with the same ID ... and you want us to fix it in the framework?? Can't do, sorry. You'll just have to learn to code better.

[Prototype-core] Re: $ function

2007-06-18 Thread Mislav Marohnić
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: and the firefox because I call the getElementById has disturb his understanding on the DOM structure and the second call return me the second matched Look how much I care about this problem:

[Prototype-core] Re: $ function

2007-06-18 Thread Andrew Dupont
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 $

[Prototype-core] Re: $ function

2007-06-18 Thread Ryan Gahl
my vote is #1 It is up to the devs to a) use the name and id attributes properly, and b) wrap anything you want any way you want in some custom wrappers file that you load in after prototype (or whatever library it is you are creating the wrapper for). For instance, I have never had this

[Prototype-core] Re: $ function

2007-06-18 Thread Adam McCrea
but if I had this need I'd know I can just rely on the mutable nature of javascript and redefine the $() within my app to behave however I want. Very true, and I have done just that. My goal was not only to help myself, but also others in the future who might not realize what is happening

[Prototype-core] Re: $ function

2007-06-18 Thread Радослав Станков
Vote for #1 I think we as developers should think about the performance and code, and we should be aware of this traps . But to make fix which will be helpful for unaware people and lower the quality, I don't think It is a good idea. --~--~-~--~~~---~--~~ You

[Prototype-core] Re: $ function

2007-06-18 Thread [EMAIL PROTECTED]
I think the most important thing is what is the goal of the $ function 1. if the goal is to create a shotpath function to the getElementById, so no changes will be done. 2.If the goal is let the people get the same result on cross browsers, and the $ function must add some checks and return the

[Prototype-core] Re: $ function

2007-06-18 Thread Tom Gregory
I think it's time to let it drop. You've had several of the core developers--the guys with commit access to the repository--say no. (Given that I'm not a core dev, I don't get much of a vote here, but FWIW I agree: leave $() alone. IE's practice is both misguided and easy to work around.)

[Prototype-core] Re: $ function

2007-06-17 Thread DK
I agree with jdalton - performance hit. I agree also that you shouldn't use the same values for name's and id's. $() is made for one purpose - to find elements with given id. It should be VERY fast in every case as it's a base function of Prototype. IMO, if found' element's id isn't the same

[Prototype-core] Re: $ function

2007-06-17 Thread [EMAIL PROTECTED]
element = $$('*[id=' + id + ']').first(); should be the same with my element=$$(*).detect(function(node){return node.id==id}) is there some performance difference between these two code? Thanks On Jun 17, 9:14 pm, Adam McCrea [EMAIL PROTECTED] wrote: While I agree that it is bad practice to

[Prototype-core] Re: $ function

2007-06-17 Thread Mislav Marohnić
I support the reopening of this ticket. It is truly an edge case which, IMO, should be handled. The proposed solution is quite nice, also. The only solution that could be faster than this is to temporary delete the name of the found element and repeat the $() call, after which the name would be

[Prototype-core] Re: $ function

2007-06-17 Thread Mislav Marohnić
On 6/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: is there some performance difference between these two code? Thanks Using the CSS selector instead of Enumerable enables the use of XPath. But since IE doesn't support XPath and the hack above is for IE and Opera, I'd dare to say that

[Prototype-core] Re: $ function

2007-06-17 Thread [EMAIL PROTECTED]
What about this code: if(!element.id || element.id!=id) { var tmp=[]; var t=document.getElementById(id); while(t!=null t.id!=id) { tmp.push([t,t.name]); t.name+=_tmp_;

[Prototype-core] Re: $ function

2007-06-17 Thread [EMAIL PROTECTED]
I rewrite it like this, I know this is very ugly someone can improve it? if(!element.id || element.id!=id) { var tmp=[];var y=100; var t=document.getElementById(id); while(t!=null t.id!=id) {

[Prototype-core] Re: $ function

2007-06-17 Thread Andrew Dupont
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

[Prototype-core] Re: $ function

2007-06-17 Thread Mislav Marohnić
On 6/17/07, Andrew Dupont [EMAIL PROTECTED] wrote: return $(document.body).down('*[id=foo]'); Nice. But there is an alternative that Tobie suggested: not fixing the issue. if (!element.id || element.id != id) throw Some helpful error message The error would help people learn about this

[Prototype-core] Re: $ function

2007-06-17 Thread Adam McCrea
Oh, if only we all had the luxury to change our sources. ;-) On 6/17/07, Mislav Marohnić [EMAIL PROTECTED] wrote: On 6/17/07, Andrew Dupont [EMAIL PROTECTED] wrote: return $(document.body).down('*[id=foo]'); Nice. But there is an alternative that Tobie suggested: not fixing the issue.

[Prototype-core] Re: $ function

2007-06-17 Thread [EMAIL PROTECTED]
I really like the throw error solution, that is great, I want to modify this function because I face even a getElementById bug in the firefox2.0,look at the code: script src=prototype.js/script input type=text value=this should be returned name=test id=www / input type=text value=this should not