James Robinson , 2011-04-28 13:08 -0700:
> On Thu, Apr 28, 2011 at 12:40 PM, Ian Hickson wrote:
> > Back in December there was a discussion about a tab visibility API.
> >
> > I haven't added this feature to the HTML specification at this time, for
> > a couple of reasons: first, it seems like so
On Thu, Apr 28, 2011 at 12:40 PM, Ian Hickson wrote:
>
> Back in December there was a discussion about a tab visibility API.
>
> I haven't added this feature to the HTML specification at this time, for
> a couple of reasons: first, it seems like something we'd really want to
> have implementation
Back in December there was a discussion about a tab visibility API.
I haven't added this feature to the HTML specification at this time, for
a couple of reasons: first, it seems like something we'd really want to
have implementation experience before deciding on a specific API, and
second, it
On Tue, Jan 4, 2011 at 6:50 PM, Glenn Maynard wrote:
> * “visible” : the full-size page content may be at least partially
> visible on at least one screen.
> * “hidden” : the full-size page content is not visible to the user at all.
I'd even say
* "hidden": the full-size page content is guaran
On Tue, Jan 4, 2011 at 3:50 PM, Glenn Maynard wrote:
>
>
> The earlier condition that I think you mentioned seemed reasonable:
> never say the page is "hidden" when it's not, eg. no false positives.
> It's more harmful to tell a visible page that it's invisible, than to
> tell an invisible page th
On Tue, Jan 4, 2011 at 6:20 PM, Alex Komoroske wrote:
> document.visibility
> A read-only property that returns a string, one of the values described in
> the next section. Developers can use the existence of this property to know
> that they can rely on the rest of this API, too.
> Values r
Hi all,
Thanks again for your comments and feedback. It's been a couple of weeks
since the last activity on this thread, and I wanted to take the opportunity
to do a very high-level summary of the discussion so far and put forward an
updated version of the proposal (which I've included at the end
On 12/20/10 5:16 PM, Alex Komoroske wrote:
But I think overall the discussion about precisely what a tab means is
not central to the core proposal. Is that reasonable?
Yep.
-Boris
Hi Bjartur,
Thanks for your comments. My responses are inline.
On Mon, Dec 20, 2010 at 8:56 PM, Bjartur Thorlacius wrote:
> On 12/20/10, Alex Komoroske wrote:
> > Thanks for your comments. I've replied inline.
> >
> > On Sun, Dec 19, 2010 at 8:11 PM, Bjartur Thorlacius
> > wrote:
> >
> >> On
Ah, yes, thank you Boris, I think I understand now.
Note that the actual proposal doesn't depend on the existence of a UI
construct called "tabs" that operate like they do on desktop browsers today.
I think the better way to think about it is, if the content of the page is
partially visible on *a
On 12/20/10, Alex Komoroske wrote:
> Thanks for your comments. I've replied inline.
>
> On Sun, Dec 19, 2010 at 8:11 PM, Bjartur Thorlacius
> wrote:
>
>> On Wed, 15 Dec 2010 19:27:51 -, Alex Komoroske
>> wrote:
>>
>>> Regarding the fact that background tabs aren't necessarily invisible:
>>>
On 12/20/10 10:21 AM, Alex Komoroske wrote:
I'm not sure that I understand the point of confusion. When I say
'tab', I mean the current UI construct implemented in Firefox, Safari,
Chrome, Opera, Internet Explorer, and others.
I think the point of confusion is that you think this UI construct
Hi Bjartur,
Thanks for your comments. I've replied inline.
On Sun, Dec 19, 2010 at 8:11 PM, Bjartur Thorlacius wrote:
> On Wed, 15 Dec 2010 19:27:51 -, Alex Komoroske
> wrote:
>
>> Regarding the fact that background tabs aren't necessarily invisible:
>> -
>>
>> On December 8, Boris Zb
(Subscribed recently; sorry for breaking threading.)
On Wed, Dec 8, 2010 at 2:57 PM, Boris Zbarsky wrote:
> 2) There is some potential for abuse (e.g. putting up dialogs to make
>yourself the active tab if you determine that you aren't, though
>perhaps this is a quality of implementation
On Wed, 15 Dec 2010 19:27:51 -, Alex Komoroske
wrote:
Regarding the fact that background tabs aren't necessarily invisible:
-
On December 8, Boris Zbarsky wrote:
There is no such guarantee for background tabs. For example, browsers
may
show tab previews in various contexts (Panor
Hi,
>> Maybe we can disallow the "visibilitychange" event to produce any dialogs
>> or anything else that could give focus?
>
> window.onvisibilitychange = function(e) {
> setTimeout(function() {
> alert("Worked around!");
> }, 0);
> };
>
> Or would browsers be able to track that the cod
Sorry for the delayed reply. I sent a number of responses over the past
week, but it just came to my attention that due to some kind of mailing-list
snafu, they never actually were sent out. I've attempted to bring all of my
replies into this one message. Sorry for the impression that I had
aban
On Fri, Dec 10, 2010 at 1:14 PM, Dennis Joachimsthaler wrote:
>
> Maybe we can disallow the "visibilitychange" event to produce any dialogs
> or anything else that could give focus?
window.onvisibilitychange = function(e) {
setTimeout(function() {
alert("Worked around!");
}, 0);
};
Or wo
Am 08.12.2010, 23:09 Uhr, schrieb Aryeh Gregor :
On Wed, Dec 8, 2010 at 2:47 PM, Alex Komoroske
wrote:
=visibilitychanged=
A simple event, fired at the document object immediately after
document.visibility transitions between visibility states.
Should be "visibilitychange" rather than "visi
On 12/9/10 3:19 AM, Markus Ernst wrote:
Am 09.12.2010 00:12 schrieb Boris Zbarsky:
On 12/8/10 5:29 PM, Markus Ernst wrote:
Thus, I'd consider an api for detecting the visibility state of every
HTML element useful (totally visible, partially visible, hidden - or a
percentage value).
This is pr
Markus Ernst schrieb am Thu, 09 Dec 2010 09:52:43
+0100:
> Regarding ads, I assume that providing some kind of visibility API
> could also lead to "better" ads. Ad authors could make their ads stop
> executing when invisible.
Browser makers can do that already with less abuse possibilities.
--
i'm not sure i'm a fan.
>From work on the nokia n8x0/n900, we wanted to be able to stop things
when the screen blanked.
During this case the "active tab" was still the "active tab", but
since the screen was blanked, the user couldn't see it.
That said, if a video is offscreen, partially offscree
Am 09.12.2010 07:12 schrieb Boris Zbarsky:
2) There is some potential for abuse (e.g. putting up dialogs to make
yourself the active tab if you determine that you aren't, though
perhaps this is a quality of implementation issue). I can
particularly see things like ads doing this so you don't just
Am 09.12.2010 00:12 schrieb Boris Zbarsky:
On 12/8/10 5:29 PM, Markus Ernst wrote:
Thus, I'd consider an api for detecting the visibility state of every
HTML element useful (totally visible, partially visible, hidden - or a
percentage value).
This is pretty hard to implement, in general. For e
On Dec 8, 2010, at 11:47 AM, Alex Komoroske wrote:
> Hi all,
>
> On the Chromium team we’ve identified a couple of use cases that we’d like to
> address with a simple API, and we’d love your feedback.
>
> In particular, there is currently no good way for a web page to detect that
> it is a ba
On 12/8/10 5:55 PM, Alex Komoroske wrote:
1) "background tab" is pretty narrow. Minimized windows, windows that
aren't on the current desktop, etc, have all the same problems.
In general this can be very challenging to do correctly, as you allude
to, and others later in the thread m
On 12/8/10 5:29 PM, Markus Ernst wrote:
Thus, I'd consider an api for detecting the visibility state of every
HTML element useful (totally visible, partially visible, hidden - or a
percentage value).
This is pretty hard to implement, in general. For example, if I put
another window over the b
Am 08.12.2010 21:40 schrieb Bjartur Thorlacius:
On Wed, 08 Dec 2010 19:47:34 -, Alex Komoroske
In particular, there is currently no good way for a web page to detect
that
it is a background tab and is thus completely invisible to the user,
Minor semantic nitpick: please use the term /does
On Wed, Dec 8, 2010 at 2:47 PM, Alex Komoroske wrote:
> =visibilitychanged=
> A simple event, fired at the document object immediately after
> document.visibility transitions between visibility states.
Should be "visibilitychange" rather than "visibilitychanged", to match
"change", "cuechange", "
On Wed, 08 Dec 2010 19:47:34 -, Alex Komoroske
wrote:
Hi all,
On the Chromium team we’ve identified a couple of use cases that we’d
like
to address with a simple API, and we’d love your feedback.
In particular, there is currently no good way for a web page to detect
that
it is a b
On 12/8/10 2:47 PM, Alex Komoroske wrote:
* A page wants to detect when it is moving into or out of the
back-forward cache.
This is covered by pagehide/pageshow events, as you note; note that the
bfcache visibility state has some big differences from the other
"invisible" states, as currently
Hi all,
On the Chromium team we’ve identified a couple of use cases that we’d like
to address with a simple API, and we’d love your feedback.
In particular, there is currently no good way for a web page to detect that
it is a background tab and is thus completely invisible to the user,
although s
32 matches
Mail list logo
