[Prototype-core] Re: getElementsBySelector has different behaviour in 1.5.0 and 1.5.1

2007-06-13 Thread Jostein

On 13 Jun, 13:57, Mislav Marohnić [EMAIL PROTECTED] wrote:

 Can you try frames[myIframe].document.body?

Thanks, I tried, but it gave the same result.

One thing that is strange, is that when I try to get elements with
selectors like table or .class1 it works perfectly! It is just the
ids (#id) that don't work.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: getElementsBySelector has different behaviour in 1.5.0 and 1.5.1

2007-06-13 Thread Mislav Marohnić
On 6/13/07, Jostein [EMAIL PROTECTED] wrote:


 One thing that is strange, is that when I try to get elements with
 selectors like table or .class1 it works perfectly! It is just the
 ids (#id) that don't work.


OK, so here is what you do now. Check out the latest trunk and try with it.

If it still fails, figure out is the problem related to the fact you're
doing cross-frame scripting. Can you make the selector fail by querying the
document inside the document itself? After playing around with this, open up
a new ticket for this bug. Post your minimal failing case (your 2 HTML
documents with everything irrelevant stripped out) and write exact queries
that fail and those that pass.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: getElementsBySelector has different behaviour in 1.5.0 and 1.5.1

2007-06-13 Thread Mislav Marohnić
On 6/13/07, Marius Feraru [EMAIL PROTECTED] wrote:


 [ Seeing you mentioned myIframe (+ the reference to a document
 property), I'm assuming you're really talking about IFRAMEs, i.e. the HTML
 element ].

 Why would anyone expect to be able to reach other folks' documents? ;-)

 It's ugly enough that the child IFRAME has access to the parent, now you
 want it both ways? :))


Marius, cross-frame scripting is perfectly harmless. Browsers enforce the
same-domain policy with frames, too, so you can't mess around with documents
in other frames that don't belong to your site. But when they do, being able
to mess around with them is sometimes what web apps build on.

Ever used GMail? It's a frameset.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: getElementsBySelector has different behaviour in 1.5.0 and 1.5.1

2007-06-13 Thread Mislav Marohnić
On 6/13/07, Marius Feraru [EMAIL PROTECTED] wrote:


 Neither Gecko 1.8 nor 1.9 are able to get the content of #myIframe.


$('myIframe').contentDocument.body

That is W3C standard.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: getElementsBySelector has different behaviour in 1.5.0 and 1.5.1

2007-06-13 Thread Marius Feraru

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mislav Marohnić wrote:
 $('myIframe').contentDocument.body
 That is W3C standard.

QED: I'm obsolete. :o)

Thanks (again) a million, Mislav. :)

- --
Marius Feraru
-BEGIN PGP SIGNATURE-

iD8DBQFGcA49tZHp/AYZiNkRAm+vAJ9fK/M/toCXmX7p4zuvZgMAVCvHrQCfaSIK
Sav2bCvMIeiiZI32PO7fFvU=
=AvGC
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Hijack Browser Loading

2007-06-13 Thread Michael Peters

[EMAIL PROTECTED] wrote:
 No matter what I try the images still load.  Does anyone know
 how to hijack the browser and tell it not to load certain images?

I might be wrong, but how a browser parses the HTML, decides what to download
and when is all pretty browser specific. You probably can't change the way it
downloads images. But you can change which images are requested.

You could try having your Javascript modify the URLs of images that you want to
hold off on loading. They could be changed to request a 1x1 pixel image which
should come back pretty fast. And if you change them to all request the same
small image then it will only make that request the first time. Then load the
real images via JS when you need to.

-- 
Michael Peters
Developer
Plus Three, LP


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Hijack Browser Loading

2007-06-13 Thread [EMAIL PROTECTED]

 You could try having your Javascript modify the URLs of images that you want 
 to
 hold off on loading.

Unfortunately i've tried this out and it still loads the original
images even though the swapped out image is displayed.  I realize this
is probably a browser specific thing, and may not be possible, but I
wanted to pick everyones brains and see if anyone could come up with a
creative solution.

Thanks!


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Hijack Browser Loading

2007-06-13 Thread Ken Snyder

[EMAIL PROTECTED] wrote:
 Hey guys,

 I'm building a web app and am hoping to minimize the images loaded per
 page.  I like the way YouTube only loads the thumbnails of the images
 you can see and then waits till you scroll before loading any others.
 They do this by placing img / tags for the initial images and then
 use javascript to fill out the rest.  The only problem with this is
 someone without javascript won't see any of those additional images.
 So my question, and thought, was to do something like this:
   
This looks like a question for the Rails-Spinoffs group.

A simple unobtrusive approach would be to have a drawer of thumbnails 
with a link to view more images.  For JavaScript enabled browsers, 
simply override the functionality of that link to load a list of image 
locations from memory or by AJAX.

An image will be downloaded by the browser anytime 1) it parses an img 
with a src attribute, 2) an img node  with a src attribute is added to 
the DOM via JavaScript, or 3) any existing img has its src changed via 
JavaScript.  This should be standard across all browsers.

As a developer, you should be able to control when images are loaded by 
keeping these three in mind.  Note that browser image caching rules 
apply according to the HTTP headers sent with the image.

--Ken Snyder

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Event.element() oddity

2007-06-13 Thread jdalton

Hi Guys,

I was using Event.element(event) in an image onload observer and I
noticed that in IE,
it would return the Image element while in FireFox it would return a
[object HTMLDocument].

I used the guts of the Event.element and changed it to $
(event.currentTarget || event.srcElement)
and that fixed it.

This is probably an edge case.

More info about event targets can be found here.
http://developer.mozilla.org/en/docs/DOM:event:Comparison_of_Event_Targets


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Hijack Browser Loading

2007-06-13 Thread Ken Snyder
[EMAIL PROTECTED] wrote:
 A simple unobtrusive approach would be to have a drawer of thumbnails
 with a link to view more images.  For JavaScript enabled browsers,
 simply override the functionality of that link to load a list of image
 locations from memory or by AJAX.
 

 The only problem with that is people without JavaScript don't see
 those additional images.  Let me explain a little more:  I have three
 tabs, and only one can be viewed at a time.  Therefore, I'd really
 only like the images to only be loaded in the first viewed tab,
 there's no since loading images in a tab people can't see.  Then when
 people click over to another tab those images are loaded.

 Make sense?
   
No.  I don't see how you can click over to another tab or load more 
images unless you use JavaScript and or provide a link that loads a new 
page with new images.  You can only control the loading of images by 
changing the URL or JavaScripting.

Maybe provide an example page?

--Ken

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Hijack Browser Loading

2007-06-13 Thread [EMAIL PROTECTED]

Here's a prototype I was working on:

http://code.markhuot.com/image_trick/


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Event.element() oddity

2007-06-13 Thread Mislav Marohnić
Thanks for the report. This sounds serious enough to open up a ticket, can
you do that?

While we're at it, does anyone really know the difference between target
and currentTarget? Doesn't one of them correspond to what the this
keyword references when the event handler is executed?


On 6/13/07, jdalton [EMAIL PROTECTED] wrote:


 Hi Guys,

 I was using Event.element(event) in an image onload observer and I
 noticed that in IE,
 it would return the Image element while in FireFox it would return a
 [object HTMLDocument].

 I used the guts of the Event.element and changed it to $
 (event.currentTarget || event.srcElement)
 and that fixed it.

 This is probably an edge case.

 More info about event targets can be found here.
 http://developer.mozilla.org/en/docs/DOM:event:Comparison_of_Event_Targets


 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Event.element() oddity

2007-06-13 Thread Tobie Langel

event.currentTarget is the element the event was attached to (i.e.
it's equivalent to this).
event.target == event.srcElement is the element that triggered the
event.

So for example:

ul id=myUl
  li id=myLiclick me/li
/ul

$('myUl').observe('click', callback);

If I now click on the click me text: event.target should be (if
following the specs) li#myLi and event.currentTarget should be
ul#myUl.



On Jun 13, 7:38 pm, Mislav Marohnić [EMAIL PROTECTED]
wrote:
 Thanks for the report. This sounds serious enough to open up a ticket, can
 you do that?

 While we're at it, does anyone really know the difference between target
 and currentTarget? Doesn't one of them correspond to what the this
 keyword references when the event handler is executed?

 On 6/13/07, jdalton [EMAIL PROTECTED] wrote:

  Hi Guys,

  I was using Event.element(event) in an image onload observer and I
  noticed that in IE,
  it would return the Image element while in FireFox it would return a
  [object HTMLDocument].

  I used the guts of the Event.element and changed it to $
  (event.currentTarget || event.srcElement)
  and that fixed it.

  This is probably an edge case.

  More info about event targets can be found here.
 http://developer.mozilla.org/en/docs/DOM:event:Comparison_of_Event_Ta...


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Event.element() oddity

2007-06-13 Thread Mislav Marohnić
On 6/14/07, Tobie Langel [EMAIL PROTECTED] wrote:


 event.currentTarget is the element the event was attached to (i.e.
 it's equivalent to this).
 event.target == event.srcElement is the element that triggered the
 event.


Thanks, thats what I thought. I guess MDC docs confused me by not making
this clear enough :-/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---