Re: element.onresize

The problem with this is one of performance.

For example resizing the window could easily cause every single
element on the page to change size. If every element fired an event,
that could easily mean firing thousands of events.

Yes, in many situations the implementation could optimize and not fire
events when no one is listening. However mutation events has proved
that even just checking for event listeners bares significant cost and
complexity. Not to mention the fact that a feature isn't very useful
if it slows down the page so much that you generally don't want to use
it.

This is slightly different for the IE implementation since they don't
use real DOM Events. In particular I don't think they have a capturing
phase. This makes event dispatch significantly faster.

/ Jonas

On Tue, Feb 2, 2010 at 1:09 PM, Gregg Tavares <gman@google.com> wrote:
> I'm not sure if this is the correct place for this but:
>
> Has there been any discussion of adding an element.onresize event?
>
> The issue that has come up is the canvas tag, in 2d or 3d, when the canvas
> changes its displayed size, a webapp might want to respond by changing
> the size of the internal representation of the canvas.
>
> Unfortunately an appt has no way to know when the
> canvas's display size has changed.
>
> The developer can use window.onresize but that only triggers when the window
> itself has changed size. If the canvas element has changed size for some
> other
> reason (another element's css or size were changed for example) no
> window.onresize
> is sent and so their is no easy way to know the display size of the canvas
> changed.
>
> This could be added to just the canvas tag but it seems like it would be
> more
> appropriate to be added to all (visual?) elements.
>
> I can see for example, setting img.src depending on the display size of the
> img element or changing the content of a div depending on its display size.
>
>
>

Received on Tuesday, 2 February 2010 21:57:37 UTC