Intent to Deprecate: overflowchanged event

[Philip Jägenstedt]

Primary eng (and PM) emails

phi...@opera.com

Summary

Deprecate the overflowchanged event.

Motivation

This is a WebKit/Blink-only feature. I've not been able to find any discussion about standardizing it. There are some interesting comments in https://bugs.webkit.org/show_bug.cgi?id=67583

Compatibility Risk

Unknown, the event handler can do anything. Firefox has a supposedly similar overflow event, which leaves IE as the only evidence that the Web can work without the event. Still, the low usage is very encouraging.

Alternative implementation suggestion for web developers

Depends on what the event handler actually does. In the general case it looks like there are other ways of determining if scrollbars are visible:

http://stackoverflow.com/questions/4814398/how-can-i-check-if-a-scrollbar-is-visible

Without the event one would have to poll for changes whenever the window is resized or when a user-resizable widget is resized.

Usage information from UseCounter

http://www.chromestatus.com/metrics/feature/timeline/popularity/208 (~0.006%)

Entry on chromestatus.com and/or MDN

None.

Requesting approval to remove too?

No, let it be deprecated for a release cycle first.

[Alex Russell]

I'd prefer we push standardisation for this instead of removing our impl. This event seems a valuable way for developers to get information we give them no other way.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

​Then I guess it should at least be made asynchronous (that WebKit bug suggests it was kept synchronous)?​

☆PhistucK

[Adam Barth]

Looks like the event is already asynchronous.  Actually, it looks to be synchronized with requestAnimationFrame.  In the new world where Layout is also synchronized with requestAnimationFrame, that means clients of this event that make visual changes to the page will put up exactly one bad frame each time.

Adam

[Philip Jägenstedt]

Deprecation doesn't require a LGTM, but since Alex thinks this should
be standardized instead I'd appreciate API owner feedback. I don't
have any history with this event, I just wanted to move the process
along since I added the use counter (by request from PhistucK).

Philip

[Andrei Bucur]

This is one of the events really hard to specify because it's layout output triggered. For example, in the case of two scripts:

<script>

element.addEventListener("overflowchanged", listener);

addContentToElementToOverflow();

element.offsetTop; // trigger an intermediary layout changing the overflow state of element (overflow).
removeContentFromElementToNotOverflow();

</script> // trigger a layout to change the overflow state of the element (no-overflow) @ the end of the script.

versus

<script>
element.addEventListener("overflowchanged", listener);
addContentToElementToOverflow(); // No intermediary layout in this case.
removeContentFromElementToNotOverflow();
</script> // the overflow state of the element was not changed by the layout @ the end of the script

Will the event be triggered in both cases, just in the first case or in neither of them? If we want to have a sane behavior and not totally destroy performance it shouldn't trigger in any of the two situations because the last layout didn't cause any overflow state change from the initial value. To specify it we somehow need to differentiate between mid-script layouts and final layouts that get to be painted.

Andrei.

[Adam Barth]

This feature sounds problematic in that it reveals internal details of the engine (e.g., when we perform layout).  For example, if the engine gets smarter in the future and learns how to compute element.offsetTop without computing whether element overflows, we might break content that assumes that the first snippet will trigger an overflow changed event.

For the same reason, I'm not sure how we'd get interoperable behavior between different rendering engines.  I doubt that all rendering engines compute overflow information internally at the same times...

Maybe the best approach here is to understand what people find useful about this event and figure out if there's a way to address those use cases without revealing implementation details of the engine.  That will preserve our ability to improve the engine in the future and make it more likely we'll end up with interoperable implementations in multiple browsers.

Adam

[Philip Jägenstedt]

Since I just linked to this thread from elsewhere, I though I should
clarify what happened to it:

Around April 22 I tried a GitHub code search for the event, but found
almost exclusively results from the Blink and WebKit source code
itself. Not having any other way to "understand what people find
useful about this event" I just left it there.

Since this is vendor-specific and standardization doesn't seem likely
to happen, I think we should still deprecate it in order to warn
developers from depending on it. The usage is certainly low enough...

Philip

[Ojan Vafai]

LGTM to deprecate. I do think we need some API for detecting when scrollbars appear, but this one doesn't seem like the right one. Unfortunately, I haven't heard any good suggestions for what a reasonable alternative is.

[Eric Seidel]

Blink does not support Mail.app:
https://bugs.webkit.org/show_bug.cgi?id=67583#c6

My understanding is that this was one of few things which can cause us
to run JS in response to layout(). If we can ditch that complexity,
sgtm.

Moz has overflow, but as abarth says, I'm sure it's not triggered at
the same time as ours:
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/overflow

LGTM to deprecate, hopefully we'll be able to remove it. I'm also
curious as to exactly which information developers are interested in
from this event.

[Ojan Vafai]

On Tue, May 20, 2014 at 11:25 AM, Eric Seidel <ese...@chromium.org> wrote:

Blink does not support Mail.app:
https://bugs.webkit.org/show_bug.cgi?id=67583#c6

My understanding is that this was one of few things which can cause us
to run JS in response to layout(). If we can ditch that complexity,
sgtm.

FWIW, this is no longer the case. Elliott changed it a few months back to fire at requestAnimationFrame time. AFAIK, the only thing left that can cause us to run JS in response to layout is plugins.

Removing this is mostly about removing a non-standard event that's incompatible with other browsers. Some work would need to go into defining an API that could be implemented in a cross-browser way. For example, if we made it so that the evaluation of whether overflow had changed was rechecked before firing at rAF time, then that would solve the case Andrei mentioned and I think we could implement this interoperably as much as we're able to implement rAF interoperably.

If someone felt motivated to make this happen, I'd also be OK with pursuing fixing and pushing to standardize this event instead of removing it.

[cub...@gmail.com]

Responding to Adam Barth: 

I am making an editor using a contenteditable div.  I want to do some special things involving how the text wraps at the end of a line. 

I have been checking after each keypress whether the line of text has gone past the edge of the box.  I recently realized I can use the overflowchanged event.  

I am doing a moderate amount of work on each keypress to check whether I've gone past the limit.  For me, it is great to have an event that says exactly that. 

Responding to Adam Barth and Andrei Bucur:

Here I am more stating an opinion than giving information, so give this less attention.  :^) 

1) There may be intermediate overflows that aren't there in the final result. 

2) Different rendering engines may give overflow events at different times. 

Yeah, those are both true, and hard to fix.  Kick it up to the user.  Put a big sign on the API saying the overflows may happen at different times as the browser evolves and as one moves between browsers.  The user can take whatever steps are necessary to his purpose.  If he ties his code to a particular sequence of overflows and underflows, it's his own darn fault. 

I realize that may be hard for a standards body to accept. 

                 Regards, Rick

[Alan Stearns]

Like Alex I think there should be a standard event for this. I don't have an opinion on whether the current impl should stay or go, though.

[Adam Barth]

On Sun Jul 27 2014 at 4:28:35 AM <cub...@gmail.com> wrote:

Responding to Adam Barth: 

I am making an editor using a contenteditable div.  I want to do some special things involving how the text wraps at the end of a line. 

I have been checking after each keypress whether the line of text has gone past the edge of the box.  I recently realized I can use the overflowchanged event.  

I am doing a moderate amount of work on each keypress to check whether I've gone past the limit.  For me, it is great to have an event that says exactly that. 

That sounds like a good use case, but we should find a better way to address that use case.  For example, perhaps we should give script the ability to control how lines wrap.

Responding to Adam Barth and Andrei Bucur:

Here I am more stating an opinion than giving information, so give this less attention.  :^) 

1) There may be intermediate overflows that aren't there in the final result. 

2) Different rendering engines may give overflow events at different times. 

Yeah, those are both true, and hard to fix.  Kick it up to the user.  Put a big sign on the API saying the overflows may happen at different times as the browser evolves and as one moves between browsers.  The user can take whatever steps are necessary to his purpose.  If he ties his code to a particular sequence of overflows and underflows, it's his own darn fault. 

Although it might be the author's fault, that situation ends up imposing costs on other people.  When web sites depend on implementation details of one browser, it's more difficult to create new browsers, which means users have less choice and end up with a worse experience.

To give a concrete example, Mozilla is working on a new browser engine called Servo that does some pretty neat things with parallelizing layout.  It's very likely that those improvements will affect the timing of the overflowchanged event just as our removal of the layout timer did.

If authors write content that depends on specific overflowchanged timing that doesn't work in Servo, users will be less able to adopt Servo.  Even though the author is at fault for relying on engine specific behaviors, users lose out because they're less able to benefit from innovative browsing engines like Servo.

I realize that may be hard for a standards body to accept.

That's one of the reasons the standards process is important and also why the standards process includes multiple interoperable implementations.  Having multiple implementations that have exactly the same behaviors helps ensure that we'll be able to improve our implementation of the feature over time (or even create entirely new rendering engines like Servo) without being stuck with whatever implementation details we happened to have today.

Adam

 

[hey...@google.com]

Hello!

I believe developers have exploited overflowchanged event to detect change in width or height of a div.

Without using overflowchange event, I can think of only two ways to detect general element resize:

1. use setInterval, manually check if the size changed every x ms.

2. use helper divs and their onscroll event, like this: [http://jsfiddle.net/6zw11zvn/7/]

However, 1. has performance issues, 2. requires extra divs and quite a bit of code.

What is your favorite way to detect general element resize? (not window resize, but element resize)

[ma...@krpano.com]

Just as note - here's a handy tool (look for 'ResizeSensor') that uses the 'overflowchanged' event (but also the 'overflow', 'underflow' (Firefox) and 'resize' (IE) events as fallback for other browsers) to detect the resize of div elements:

http://marcj.github.io/css-element-queries/

It would be not that nice if such wouldn't work anymore in all browsers (and if there would be no alternative solution)...

Also note - the IE itself has a 'resize' event for div elements, which is the most handy solution I think so far (and it would be great to have it in all browsers of course).

Basically all I want to say is, before 'removing' stuff, it would be nice to 'add' new stuff to provide at least the same or even better possibilities first.

Thanks and best regards,
Klaus

[Philip Jägenstedt]

Does the overflowchanged event really allow you detect any element
resize, even if nothing is overflowing before or after the resize?

I suppose that a mechanism for detecting a change in layout size of an
element can come in handy in non-trivial layouts where it's hard to
keep track of all the things that could cause layout to change, other
than window resize. It seems like something that must have been
suggested many times but for some reason hasn't happened yet.

FWIW, overflowchanged usage is even lower than than in April, now around 0.002%:
http://www.chromestatus.com/metrics/feature/timeline/popularity/208

Philip

[ma...@krpano.com]

Yes, I think that works by adding two hidden <div> elements, here the source:
https://github.com/marcj/css-element-queries/blob/master/src/ResizeSensor.js

In my case I'm using this in an offline-only node-webkit-based app for simple resize-able UI elements - the UI element <div> only gets the CSS property 'resize=both' and that 'ResizeSensor' - and the user is able to resize the element without any additional custom JS code - simple and effective.

[ma...@krpano.com]

Update: sorry, it seems the 'overflowchanged' event examples from here - http://marcj.github.io/css-element-queries/ - aren't working in the current Chrome versions anymore. The last working Chrome version seems to be 32. So when not working, removing it shouldn't matter too...

[ma...@jarves.io]

Yepp, in Chrome 34 it appears that 'overflowchanged' has already been marked as deprecated.

> document.body.addEventListener('overflowchanged', function(){});
[!] The 'overflowchanged' event is deprecated and may be removed. Please do not use it.

It also has been introduced a new 'onresize' property on HTMLElements, where the error of css-element-queries came from:

https://github.com/marcj/css-element-queries/issues/14

So this raises actually the question: Why talking about whether it should be deprecated if it's already?

Through the usage of css-element-queries some websites/application are based on overflowchanged event and it would be really uncool if you're going to remove it. :-)

[PhistucK]

The questions is whether to remove it, not to deprecate it, because it is a nonstandard and mostly unused feature.

If standards emerge and include it (and the API owners think it is a good idea), the deprecation would of course be lifted.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

On Sun, Sep 7, 2014 at 11:32 PM, <ma...@jarves.io> wrote:
> Yepp, in Chrome 34 it appears that 'overflowchanged' has already been marked
> as deprecated.
>
>> document.body.addEventListener('overflowchanged', function(){});
> [!] The 'overflowchanged' event is deprecated and may be removed. Please do
> not use it.
>
>
> It also has been introduced a new 'onresize' property on HTMLElements, where
> the error of css-element-queries came from:
> https://github.com/marcj/css-element-queries/issues/14
>
> So this raises actually the question: Why talking about whether it should be
> deprecated if it's already?

This thread was started in April, and the deprecation went into M37.
Nothing about the overflowchanged event has actually changed though,
at least not as far as I know.

Incidentally, exposing onresize on HTMLElement was also my doing, as
part of implementing GlobalEventHandlers:
https://code.google.com/p/chromium/issues/detail?id=305112

That change was in M32, which reached the stable channel in January
2014. I'm not sure why M34 is implicated in the css-element-queries
issue:
https://github.com/marcj/css-element-queries/issues/14

In any case, it's not related to the overflowchanged event.

> Through the usage of css-element-queries some websites/application are based
> on overflowchanged event and it would be really uncool if you're going to
> remove it. :-)

It looks like you removed the overflowchanged code path after writing
this email:
https://github.com/marcj/css-element-queries/commit/d96e17397c3fa3e6cea96b239ef02628169267f0

Is the new implementation fine, or is there some API needed to make it
work really well? All I know is that element queries are an unsolved
problem: http://www.xanthir.com/b4PR0

Philip

[PhistucK]

Interesting. How does the resize event work on an element? I add enough text to a <div> so it would expand the element and the resize event is not being fired. I also change its style.width and its style.height and the event is still not being fired.

Have you simply implemented the event only at the attribute existence level ("onresize" in element) and not at the actual operating level (fire a resize event when the dimensions of an element changes)?...

☆PhistucK

[Simon Pieters]

On Mon, 08 Sep 2014 13:05:41 +0200, PhistucK <phis...@gmail.com> wrote:

> Interesting. How does the resize event work on an element? I add enough
> text to a <div> so it would expand the element and the resize event is
> not
> being fired. I also change its style.width and its style.height and the
> event is still not being fired.
> Have you simply implemented the event only at the attribute existence
> level
> ("onresize" in element) and not at the actual operating level (fire a
> resize event when the dimensions of an element changes)?...

Having an event handler does not imply that an event is ever fired. The
HTML spec requires most event handlers on Window, Document and
HTMLElement, even if a particular event is only fired on some specific
element.

I think right now there is no spec that specifies firing 'resize' event on
elements (other than <video>,
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content.html#dimUpdate
), but that might be added as part of Element Queries thing if that takes
off.

--
Simon Pieters
Opera Software

[PhistucK]

Huh? I am not sure specifying an event that is never fired was the intention. :|

But perhaps, because I see that Internet Explorer 11 and Firefox 31 do not fire the resize "event" as well (but it is also not included as an IDL attribute on HTMLAnchorElement).

Why would "resize" as a global event handler be added if it does nothing, given the fact that no browser supports it as a global event handler (at least on <a>)?

I thought the purpose of the current specification is to document the current state of the world and organize it instead of adding new (apparently compatibility driven?) features that do (or should) not work and never existed anywhere in the first place...

☆PhistucK

[Simon Pieters]

On Mon, 08 Sep 2014 14:54:26 +0200, PhistucK <phis...@gmail.com> wrote:

> Huh? I am not sure specifying an event that is never fired was the
> intention. :|
> But perhaps, because I see that Internet Explorer 11 and Firefox 31 do
> not
> fire the resize "event" as well (but it is also not included as an IDL
> attribute on HTMLAnchorElement).
>
> Why would "resize" as a global event handler be added if it does nothing,
> given the fact that no browser supports it as a global event handler (at
> least on <a>)?
> I thought the purpose of the current specification is to document the
> current state of the world and organize it instead of adding new
> (apparently compatibility driven?) features that do (or should) not work
> and never existed anywhere in the first place...

http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Feb/0348.html

I guess onresize in particular was a recent change to go along with the
resize event on <video>, but the globalness has been implemented for years
I believe. e.g. "onloadedmetadata" in document.createElement('a')

[PhistucK]

So it is basically only in effect when a bubbling event is fired in an appropriate element? <a><video></a>?

Oh, well...

☆PhistucK

[Philip Jägenstedt]

Ah, that explains why the timing didn't add up, I moved onresize to
GlobalEventHandlers later:
https://codereview.chromium.org/136593002

That reached stable with M34 on April 8, and the css-element-queries
issue was opened on April 9.

Philip

[Simon Pieters]

On Mon, 08 Sep 2014 15:43:56 +0200, PhistucK <phis...@gmail.com> wrote:

> So it is basically only in effect when a bubbling event is fired in an
> appropriate element? <a><video></a>?
> Oh, well...

That or when you fire an event yourself in script, yeah.

[ma...@jarves.io]

On Monday, 8 September 2014 08:09:14 UTC+2, PhistucK wrote:

The questions is whether to remove it, not to deprecate it, because it is a nonstandard and mostly unused feature.

If standards emerge and include it (and the API owners think it is a good idea), the deprecation would of course be lifted.

I see. I thought you're talking about deprecating it because the title and description is full of 'deprecate', not 'remove'. 

On Monday, 8 September 2014 11:08:15 UTC+2, Philip Jägenstedt wrote:

In any case, it's not related to the overflowchanged event.

 

Exactly, the overflowchanged event still works.

On Monday, 8 September 2014 11:08:15 UTC+2, Philip Jägenstedt wrote:

> Through the usage of css-element-queries some websites/application are based
> on overflowchanged event and it would be really uncool if you're going to
> remove it. :-)

It looks like you removed the overflowchanged code path after writing
this email:
https://github.com/marcj/css-element-queries/commit/d96e17397c3fa3e6cea96b239ef02628169267f0

Is the new implementation fine, or is there some API needed to make it
work really well? All I know is that element queries are an unsolved
problem: http://www.xanthir.com/b4PR0

Yes, once I've seen the deprecated message and this thread here I thought it's time to implement a new more reliable approach. But went into bed right after it :-)

So well, I actually don't care anymore whether overflowchanged will be removed or not. The new resize detection is more stable in Firefox for example and works now in IE7 and IE11 as well.

The only issue is that it doesn't work when the element is too small (< 20px) (I guess when it's smaller then the size of the actual scrollbars), but that isn't related to this thread here and is in all browsers the case.

There's so much unsolved problems in the web world, but that shouldn't prevent introducing new useful stuff like element queries. Better available with small issues than not available at all. 

[Hae Jeong]

By the way, I read from some threads regarding element resize detection that IE11 does not support the native onresize event.

Here is one thread: 

http://social.msdn.microsoft.com/Forums/ie/en-US/bbbc62b2-3b63-480c-9462-6f618fde83d7/ie11-alternative-for-elementonresize-event-or-how-can-i-detect-when-an-arbitrary-dom-element?forum=iewebdevelopment

[cjre...@gmail.com]

This would have been a nice-to-have standard feature -- there are a couple odd cases where CSS overflow options aren't sufficient; inserting DOM elements on overflow, for example. I prefer to avoid handling the resize event whenever possible since it fires so rapidly.

[Elliott Sprehn]

On Wed, Aug 5, 2015 at 2:24 PM, <cjre...@gmail.com> wrote:

This would have been a nice-to-have standard feature -- there are a couple odd cases where CSS overflow options aren't sufficient; inserting DOM elements on overflow, for example. I prefer to avoid handling the resize event whenever possible since it fires so rapidly.

The resize event fires once per frame in Blink, it shouldn't be very rapid.

- E

[cjre...@gmail.com]

I am just raising the problem of using the resize event as a catch-all as a Web developer. I haven't come across this specific problem very often. So it's not a major concern, but rather a nice-to-have.

Once the JS handler exists in the code base other functions have a tendency to latch on even if there are better options available. There is no reason to reach for a screw driver when you have a hammer in your hand.

-Chris