When an element is resize (for whatever reason) it should fire a resize event. This event is very important for creating reusable UI components that need to do js layout logic. IE has had this event since version 4. Test case coming up
Created attachment 19900 [details] Resize the window to trigger the resize event
FF3 fails the attached test case. Which means unless someone is going through the painful process of trying to right a "next gen" web application in IE7, I don't think they'll be using this event. :)
Yes and Erik, to his credit, filed this bug there too... back in 2003... https://bugzilla.mozilla.org/show_bug.cgi?id=227495 My mom taught me that two wrongs don't make a right :-). Seriously, this capability (the ability to observe size changes at an element level - i.e. as various CSS rules come into and go out of effect), is crucial to doing web-based UI components without resorting to 'JS monitors'. At minimum, this bug shouldn't be left as 'unconfirmed' when it clearly has been confirmed. Cheers, - Bill
We don't follow bugzilla's arbitrary conventions very closely here in WebKit land. :) In order to fix this, we need to know *what* onresize is supposed to do? When should it fire? Synchronously with the resize? After all resizes have happened? Does it bubble? I assume that addEventListener("resize") is supposed to work too. Someone effectively needs to write a little mini spec, and associated test cases, if we're going to be able to fix this. Until we know what exact behavior we're supposed to add, it's hard to write the code. :)
Eric - Thanks for the quick reply! A comment from the Mozilla bug report states that the 'resize' event is documented in the DOM Level 3 events spec. And so it is: http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-resize Looks like its not cancelable, it bubbles and can be targeted at a Document or Element. Since its a DOM event, I would assume that the 'addEventListener("resize", ..., ...)' syntax should work. In so far as how it actually gets fired, that's not specified. As a JS programmer who's not a C/Webkit guy ;-), I guess it would depend on how the Webkit engine is structured. I know that sitting on my side of the fence, my expectation would be that all 'resize' events get queued until the reflow is complete. But then my handlers would be invoked before painting/blitting such that I can resize other elements thereby recursing back into the engine . That is a totally WAG (wide a**ed guess and others with *much* more experience than I may want to chime in here... hint hint :-) ). Of course, the potential exists here for folks in my world (JS) to write handlers that then try to resize the target element that just got resized, thereby setting up an infinite loop... but then again, that's their problem. If you feel like you need more detail, I'd be willing to write some tests here to 'document' IE's current behavior and let that drive a mini-spec of some sort. Maybe Arv has some more to add here. Cheers, - Bill
Interesting, I did not realize there was any spec-work around a resize event. The spec sure doesn't have much to say about it. :) But it does look like something that we could consider supporting. Every RenderObject::layout() implementation would have to notify the document that a resize of the corresponding node had occurred. A list would be kept by the Document, and then from that list, events would be dispatched after the layout() had occurred. One question would be what the behavior of the list should be if a resize is triggered during a resize js handler (set some size property and then trigger a layout). I assume it should be a FIFO queue and that the remaining resize events from the previous resize should be fired before the new ones are. But maybe the queue should just be cleared on any new layout? Either way, it looks like even though there is some minor specwork, there is no testing, or exploration of the various edge conditions. ;) Something any implementor would have to explore.
I'm pretty sure that resize events do not bubble in IE. I'm willing to write a mini design doc for this that covers how IE works. I think it is important to make sure that we can minimize the work needed to do this. For example, it might make more sense to fire the event when we know that the element will change size but before we complete the reflow so that we do not do unnecessary reflows if the size changes due to the event handler.
What's the progress of this bug? If I'm interpreting the DOM3 Events spec correctly, it should also fire on every element, when resized by the user due to the CSS resize property. It doesn't. Testcase: http://dabblet.com/result/gist/1498895
I think it was only present in the IE and all other browser now moved to - Resize Observer API - https://github.com/WICG/resize-observer & https://www.w3.org/TR/resize-observer/ Attached test case and test case from Comment 08 does not work in Safari 15.6, Chrome Canary 105 and Firefox Nightly 104. I think this can be closed, if I am not mistaken. Please ignore my comment, if I am wrong. Thanks!
Yeah, this is won't fix. Use ResizeObserver instead.