After 5 years of JS widget/component development at Wijmo, I can safely say: we need a visible state change event for DOM elements.
What's a visible state change for DOM elements?
A visible state change event is an event that each DOM element would raise when it becomes visible. The event would be driven by the following style properties:
- display
- visibility
- opacity
I purposefully excluded z-index and position (top,left, etc) properties since they do not really change visible state. To be conservative, the visible state change event could fire whenever any part of the element becomes visible on screen (including offsets or hidden via layers).
Why do you need visible state changes?
DOM elements often lack layout when they are invisible. So any JavaScript evaluating an invisible elements dimensions will have issues. This is similar to what we dealt with in IE and hasLayout. The purpose of a visible state change event would be to notify when an invisible element has become visible and can be evaluated for dimensions. A very common bug I see reported is for the following scenario:
One of our JS components is inside of a hidden panel
Our JS component is initialized while invisible and uses incorrect (or null) dimensions to render.
When the panel is displayed, our component looks broken
The solution is always to somehow capture an event that occurs when the panel is becoming visible and redraw our component. But this is something our customers have to do. We are NOT able to make our components bullet proof when rendering because we do not have an API to know when they become visible. If there was a visible state change event for DOM elements, component developers could make sure their components always rerender (or defer rendering) when the element becomes visible (and has layout). In order to more clearly demonstrate the problem, I made this sample:http://jsbin.com/kasexovane/1/edit?html,js,output This is a real scenario that our customers face. They put our component into a bootstrap tab and file bugs that our component is broken. We aren't the only ones either. Just google how to tell if an html element is visible to see how common this problem is (22.5 million results)!
Who can use visible state changes?
The main benefactors of this event would be third-party JS developers. In other words, anyone who writes reusable components. If you create a reusable component, you want it to just work. You probably handle window resize to redraw your component so that it doesn't break. You also don't want the developers using your components to have to worry about rerendering for trivial things like layout or visibility change. Third-party JS is not limited to components like Wijmo. Many companies/orgs have internal components that are distributed to their developers. This issue will become more prevalent with the adoption and popularity of Web Components.
API
I am torn on API. There is already a visibilitychange event on document. On one hand it would be good to have a consistent API for DOM elements, but it serves a different purpose than this would so it might cause confusion. There are similar APIs in other platforms that could be borrowed from as well. For example, Windows Forms has a VisibleChange event on all Controls. Something else to consider is adding a property to DOM elements that indicates visible state. It is debatable whether this is necessary if there is an event added to notify visible state change, but it might be worthwhile.
Summary
Third-party JS components need a visible state change event on DOM elements so that they can ensure their components render properly when becoming visible. Without this event, third-party JS developers rely on their customers to fix this problem and are unable to create bullet-proof components.
Chris Bannon