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
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
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
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
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 ==
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
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
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
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
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
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,
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
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,
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
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 ;)
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
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)
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.
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:
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 $
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
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
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
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
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.)
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
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
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
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
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_;
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)
{
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 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
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.
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
35 matches
Mail list logo