Re: [PageVisibility] What should the visibility api return in display:none iframes?

On Mon, Oct 10, 2011 at 11:58 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Oct 10, 2011 at 10:26 AM, Shishir Agrawal <shishir@chromium.org> wrote:
>> We started discussing the spec as a way for pages to figure out how they
>> were embedded in the browser: foreground tab, background tab etc. I dont
>> think we should implement the display:none case because,
>
> As always, the way we should look at the feature set for the spec is
> from use cases, not from technical point of view, but from the point
> of view of what application behavior we're trying to support.
>
> One concrete example that I've always thought of is the bugzilla build
> reporting webpage [1]. This page uses a fair amount of resources as it
> updates itself every few minutes. It downloads a few JSON objects,
> parses those, and based on the result makes yet other requests.
> Finally it uses the result of those requests to build a DOM and
> display to the user.
>
> I often want to keep a tab open with this page for easy access.
> However if I'm not actively looking at the page, the page could save
> quite a bit of resources by downloading data less often, and when
> downloading, not go through the hassle of building the DOM needed for
> display. Hence that page should check .hidden and act accordingly.
>
> If someone creates a dash-board page which shows the status of several
> different developer tools in separate iframes, and lets the user hide
> and redisplay various tools, it would make a lot of sense to me to in
> this case try to save processing resources. If we flag any documents
> inside the display:none iframe as .hidden, we would automatically get
> the desired resource savings.
>
> [1] https://tbpl.mozilla.org/
>
>> - Keeping the spec simple - ensures that the spec is implemented
>> consistently. The more complicated we make the spec, we may see vendors
>> diverge from it.
>
> I agree spec simplicity is important. But it doesn't seem like this is
> adding a lot of implementation burden (in the Firefox case, it was the
> developer implementing the feature who found this spec-"flaw" and
> suggested the fix). Definitely not enough burden that I'd be worried
> about implementation divergence.
>
>> - The discussion to include some cases - such as display:none and not others
>> like visibility:hidden, or pages hidden by window seem a bit arbitrary to
>> me. Like I mentioned this was also not the intended use of the initial spec
>> (ofcourse that can change).
>
> Display:none is definitely a stronger styling change other properties.
> For example it's the only CSS property discussed so far which affects
> all media types per the CSS2.1 specification (display and various
> content-creating properties are in fact the only ones that do).
>
> So far the only technical argument presented against taking
> display:none into account is implementation burden. However IMO
> website utility is more important.

Another question is:

For the implementations that currently don't set .hidden to true for
display:none iframes, what are you planning on doing for display:none
iframes with regards to requestAnimationFrame?

requestAnimationFrame is supposed to fire notifications less often
(potentially not at all) for hidden documents. Are you planning on
still firing it at full frame rate as long as the top-level document
is the active window? Even if the frame itself is display:none?

It would seem to create a more consistent model for web developers if
we keep the requestAnimationFrame and page visibility APIs in sync.

/ Jonas

Received on Monday, 10 October 2011 22:34:22 UTC