Detecting resizing of DOM elements

[Chris Wilson]

Hi all,

For the Closure Library layout manager I'm working on
[https://github.com/qris/com.qwirx.ui/blob/master/BorderLayout.js], I'd
like to be able to detect when DOM elements change size, and reposition
all the elements in the managed layout.

So far I've found that W3Schools says that RESIZE browser events are
supported on DIV elements (among others) but all other sources say that
only window receives them. Empirical testing also seems to show that DIV
elements do not receive RESIZE events.

Is there something efficient I can do? I've seen suggestions to monitor
DOM properties (such as clientWidth and clientHeight, I guess) with
Object.prototype.watch, onPropertyChange
[http://james.padolsey.com/javascript/monitoring-dom-properties/],
adding a setter and getter
[https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/watch#Description],
or just using setInterval.

I assume that polling with setInterval is the least efficient approach,
watch() only works on Gecko and onPropertyChange() only works on IE. I'm a
bit reluctant to "define" a property that already exists on a DOM element.
Does anyone have any better suggestions?

Cheers, Chris.
--
_____ __ _
\ __/ / ,__(_)_ | Chris Wilson <chri...@qwirx.com> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |

[Rhys Brett-Bowen]

Unfortunately this is something that isn't really possible. I know there is a hack for browsers with transitions, you can put a very small transition (0.01s) and listen for the end event - but it doesn't seem to work if you're setting the height/width as a percentage.

I believe polling is the only way that will catch everything. You could try just listening for window resize events but if your layout is in a container that can be resized then that won't help.

My suggestion would be to leave it up to the user. Give them a method they can fire to let the layout know it was resized. That if the user puts it in a resizable area they can hook up the resizing of it's container with notifying the layout and you can always just give them a default of a setTimeout that calls the method notifying of a resize when there is an actual change

[Nate]

You could use a http://closure-library.googlecode.com/svn/docs/class_goog_dom_ViewportSizeMonitor.html .. Note getInstanceForWindow to keep the instance count down.

[Daniel Steigerwald]

w3school is wrong often, it's not related to w3, it's just some learning company.

No, you can not detect DIV changes reliable or without polling.

You probably should watch the source of changing. Dragging or something esle.

--
 
---
You received this message because you are subscribed to the Google Groups "Closure Library Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Juan Mendes]

Seems we all agree we can't detect DOM size changes without polling, or the really slow https://developer.mozilla.org/en-US/docs/DOM/DOM_event_reference/DOMSubtreeModified.

I vote for requiring users to call a method that will trigger a layout if they want to modify the DOM directly,  Ext-js allows you to do that by calling doLayout on the first managed component that contains the unmanaged HTML

[Daniel Steigerwald]

Why we should need that? I don't see usefulness of that.

[Garry Boyer]

On a very high level -- over the years this pattern pops up more and more. At one point, any reasonably decent layout required writing Javascript. However, historically, these frameworks are *really* hard to get right, that the very brighest JS folks we have at Google couldn't even get a lot of cases to work well. And they're without exception slow.

I would encourage any project nowadays to do this as little as possible only in cases you can't achieve this naturally. Use flexbox, display:table, and fixed position, or just change the UI a little bit.

For example, the classic problem -- if you need a fixed top/bottom with a scrollable middle, use fixed position headers and footers, and put the scrollable content on the main page, and reserve empty space at the top and the bottom that's the same height as the headers/footers. The scroll bar will be on the main page but some designers would argue that's a plus.

[John Munro]

Aren't mutation observers supposed to replace DOMSubtreeModified and fix the performance problems?

To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
 
---
You received this message because you are subscribed to the Google Groups "Closure Library Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-library-discuss+unsub...@googlegroups.com.