Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
On Tue, Mar 31, 2015 at 12:47 AM, Seth Fowler s...@mozilla.com wrote: I think we should modify the Page Visibility spec to let UA’s take actual visibility of iframes into account when deciding if an iframe is hidden. Wouldn't it be better to discuss that on public-web-perf? -- https://annevankesteren.nl/
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
Looking at https://developer.mozilla.org/en/docs/Web/HTML/Element/iframe Wouldn't maybe the addition of new attribute to the iframe be the best way? ** autopause If present the client can pause any processing related to the iframe if the iframe is not currently visible. When unpaused a Page Visibility event will be sent to the iframe as if the whole page had changed status from invisible to visible. For visibility events see https://developer.mozilla.org/en-US/docs/Web/Guide/User_experience/Using_the_Page_Visibility_API ** This basically makes it opt in, it changes nothing about the behavior of current iframes. Just an example would be a iframe that can be hidden/unhidden by the user clicking a button, and if the iframe has the autopause attribute then it's state is effectively paused. Once the iframe is unpaued a Page Visibility event is sent and whatever code is running in the frame can then react to this and and resume, as it never got a event indicating the page was made non-visible a programmer should be able to programmatically infer that the iframe was unpaused (it only got the one event instead of two). What type of iframes would benefit from this? Some chats, news feeds, log views, anything that constantly updates or works in the background, but does not need to be updated if not viewable (saves CPU, bandwidth, and server resources) And maybe down the road one could see if a similar autopause can be added to the parent page itself (or not). Maybe a autopause would make sense if added as a attribute to the body (but actually apply to the whole document including any scripts declared in the head). Adding a autopause attribute to a iframe is probably the easiest way to add/deal with this. If nobody ends up using it, it can easily be dropped again too, so there is no immediate downside to this that I can currently think of at least. On 2015-03-31 02:17, Seth Fowler wrote: I do want to clarify one other thing: we’re definitely not yet at the point of implementing this in Gecko, especially not in a release version. We think this functionality is important, and modifying the Page Visibility spec is one way to make it accessible to the web. It’s probably even the nicest way to make it accessible to the web, if it’s feasible. But it’s not certain that it’s web compatible or that everyone agrees this is the best way to go; we’re at the starting point of the process here. I’d be interested to hear any comments that others may have! Thanks, - Seth On Mar 30, 2015, at 3:47 PM, Seth Fowler s...@mozilla.com wrote: I think we should modify the Page Visibility spec to let UA’s take actual visibility of iframes into account when deciding if an iframe is hidden. This design doesn’t do much for iframes which may be doing significant work, though. The most obvious example is HTML5 ads. These ads may be performing significant work - computation, network IO, rendering, etc. Some or all of that work is often unnecessary when the ad is outside the viewport. Having an API that would allow those ads to throttle back their work when they’re not visible could have significant positive effects on performance and battery life. We could get these benefits through a very simple modification of the Page Visibility spec. We should make the visibility of iframes independent of the top-level browsing context, and instead let UA’s take the actual visibility of the iframes into account. If an iframe has been scrolled out of the viewport, has become occluded, or has otherwise been rendered non-visible, we should regard the iframe as hidden and dispatch a visibilitychange event to let the iframe throttle itself. ... - Seth -- Roger Hågensen, Freelancer, http://skuldwyrm.no/
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
autopause looks promising, but I want to ask for more: also add an autounload attribute to allow UAs to unload specific iframes when they are invisible. I ask for this because I'm a contributor of pdf2htmlEX ( https://github.com/coolwanglu/pdf2htmlEX ). Currently pdf2htmlEX can convert each PDF page to one SVG image and embed it in the main HTML via embeds （almost equivalent to iframe here). However, if the PDF file contains many pages, the memory consumption of embeds becomes unacceptable, although most of them are out of the viewport. Because UAs are not allowed to automatically unload invisible nested browsing context, we have to do this in JS (by removing/adding embeds from/to the tree). This is complicated and doesn't work if JS is disabled. If autounload were supported, things would be much simpler. Also I think in some use cases of autopause, autounload is even more suitable becaue it not only save CPU and network, but also save memory, which are equally important to mobile devices. 在 2015年03月31日 14:18, Roger Hågensen 写道: Looking at https://developer.mozilla.org/en/docs/Web/HTML/Element/iframe Wouldn't maybe the addition of new attribute to the iframe be the best way? ** autopause If present the client can pause any processing related to the iframe if the iframe is not currently visible. When unpaused a Page Visibility event will be sent to the iframe as if the whole page had changed status from invisible to visible. For visibility events see https://developer.mozilla.org/en-US/docs/Web/Guide/User_experience/Using_the_Page_Visibility_API ** This basically makes it opt in, it changes nothing about the behavior of current iframes. Just an example would be a iframe that can be hidden/unhidden by the user clicking a button, and if the iframe has the autopause attribute then it's state is effectively paused. Once the iframe is unpaued a Page Visibility event is sent and whatever code is running in the frame can then react to this and and resume, as it never got a event indicating the page was made non-visible a programmer should be able to programmatically infer that the iframe was unpaused (it only got the one event instead of two). What type of iframes would benefit from this? Some chats, news feeds, log views, anything that constantly updates or works in the background, but does not need to be updated if not viewable (saves CPU, bandwidth, and server resources) And maybe down the road one could see if a similar autopause can be added to the parent page itself (or not). Maybe a autopause would make sense if added as a attribute to the body (but actually apply to the whole document including any scripts declared in the head). Adding a autopause attribute to a iframe is probably the easiest way to add/deal with this. If nobody ends up using it, it can easily be dropped again too, so there is no immediate downside to this that I can currently think of at least. On 2015-03-31 02:17, Seth Fowler wrote: I do want to clarify one other thing: we’re definitely not yet at the point of implementing this in Gecko, especially not in a release version. We think this functionality is important, and modifying the Page Visibility spec is one way to make it accessible to the web. It’s probably even the nicest way to make it accessible to the web, if it’s feasible. But it’s not certain that it’s web compatible or that everyone agrees this is the best way to go; we’re at the starting point of the process here. I’d be interested to hear any comments that others may have! Thanks, - Seth On Mar 30, 2015, at 3:47 PM, Seth Fowler s...@mozilla.com wrote: I think we should modify the Page Visibility spec to let UA’s take actual visibility of iframes into account when deciding if an iframe is hidden. This design doesn’t do much for iframes which may be doing significant work, though. The most obvious example is HTML5 ads. These ads may be performing significant work - computation, network IO, rendering, etc. Some or all of that work is often unnecessary when the ad is outside the viewport. Having an API that would allow those ads to throttle back their work when they’re not visible could have significant positive effects on performance and battery life. We could get these benefits through a very simple modification of the Page Visibility spec. We should make the visibility of iframes independent of the top-level browsing context, and instead let UA’s take the actual visibility of the iframes into account. If an iframe has been scrolled out of the viewport, has become occluded, or has otherwise been rendered non-visible, we should regard the iframe as hidden and dispatch a visibilitychange event to let the iframe throttle itself. ... - Seth
[whatwg] Supporting feature tests of untestable features
There are features being added to the DOM/web platform, or at least under consideration, that do not have reasonable feature tests obvious/practical in their design. I consider this a problem, because all features which authors (especially those of libraries, like me) rely on should be able to be tested if present, and fallback if not present. Paul Irish did a round-up awhile back of so called undetectables here: https://github.com/Modernizr/Modernizr/wiki/Undetectables I don't want to get off topic in the weeds and/or invite bikeshedding about individual hard to test features. So I just want to keep this discussion to a narrow request: Can we add something like a feature test API (whatever it's called) where certain hard cases can be exposed as tests in some way? The main motivation for starting this thread is the new `link rel=preload` feature as described here: https://github.com/w3c/preload Specifically, in this issue thread: https://github.com/w3c/preload/issues/7 I bring up the need for that feature to be testable, and observe that as currently designed, no such test is feasable. I believe that must be addressed, and it was suggested that perhaps a more general solution could be devised if we bring this to a wider discussion audience.
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
On 2015-03-31 10:16, duanyao wrote: autopause looks promising, but I want to ask for more: also add an autounload attribute to allow UAs to unload specific iframes when they are invisible. This is also a good idea. I also realized that maybe video and audio can benefit from a autopause attribute, so that when the user tabs away or minimizes the browser window the video or audio automatically pause. Currently this is done using javascript and Page Visibility, but with a autopause this would make a plain video or audio tag to do the same, but without javascript. It is also possible that autounload may be of use there as well, for live streams for example and when tabbing back the player have been reset to it starting state. Although in this case autopause and autounload would be mutually exclusive, if both are present (by mistake?) I think autopause should have priority as it's less destructive (to the user) than autounload. -- Roger Hågensen, Freelancer, http://skuldwyrm.no/
Re: [whatwg] Responsive image maps
The active area in the svg is whatever the active graphical shape is, I don't quite understand what you mean that it's unclear. The active shape can also be styled with css based on :hover or :active rules, for example to add an outline or to do some sort of visual highlighting. For controlling the tab order there's the tabindex attribute (added in svg2), which has the same behavior as in html. Tabbing through an svg probably works best if the svg is inline in the html document. Support for tabindex in svg is implemented in Blink and WebKit already. On Wed, 25 Mar 2015 21:24:04 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: One of the 2 objections, I'd say. But the second is probably a matter of implementation. SVG makes it unclear what's the actual active area when navigating through tab key. 2015-03-25 19:32 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com: On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine master.skywalker...@gmail.com wrote: Instead, we start by figuring out what problems need solving. Which is what has been done for this subject, I guess. PROBLEM: image maps, intended as shaped link areas related to specific regions of an image are a fairly requested feature. Unfortunately, as current solutions are not responsive and they can't fit to how images are defined in a modern scenario, with scalable size and art direction, authors have looked for workarounds, script-enhanced or non-native (Flash maps) solutions. POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where 1. CSS has a poor range of shapes 2. See above for SVG 3. area coordinates are absolutely defined. PROPOSAL: As SVG map is not viable at all in complex picture scenarios, and not easily viable in simple contexts, authors could benefit from map versatility. So a viable solution *could* be to improve a feature in order to make it responsive. The Map element improvement consortium is not an organisation I want to mindlessly support (basically because it doesn't exists). And unfortunately I tend to be verbose when I start writing. So in my last message I tried to make it shorter and I chose terms incorrectly. Note that we *should* just be able to use picture in SVG, which helps that solution. This is generally useful (we want responsive images inside of SVG, too), and afaict, removes the only objection to SVG. ~TJ -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Responsive image maps
The active area in the svg is whatever the active graphical shape is, I don't quite understand what you mean that it's unclear The main difference between native SVG implementation and native area implementation (map/area scenario lets you small room for maneuvering, so it's native anyway) is that image maps, using tab navigation, don't expose active area. On Chrome there's a large rectangle highlighting the area (or areas in case of link spanning over multiple items), on every other platform there's no native highlighting at all. It's true, you can do it with CSS, but in image maps it's already implemented. As said, it's only a matter of implementation though. Going further, it will be redefined. The fact is always the same: as it's all a matter of implementation, I strongly believe that a mean of natively resize maps should be implemented anyway. You are right, SVG is more flexible with CSS and JS support, but flexibility comes with a cost: those rules have to be defined. Tabbing through an svg probably works best if the svg is inline in the html document For the purpose of this thread, embedded SVG simply wouldn't make any sense. We are talking about links connected with the subject of the document, it goes over the purpose of the image itself (see my note about relative paths above, too). However, there's another point, which IDK if can matter. Maps can be included at any point of the document. With some CSS they can be used as out-of-context item lists, and they can also be reused for different maps inside an image, while SVG have to be repeated. 2015-03-31 16:02 GMT+02:00 Erik Dahlström e...@opera.com: The active area in the svg is whatever the active graphical shape is, I don't quite understand what you mean that it's unclear. The active shape can also be styled with css based on :hover or :active rules, for example to add an outline or to do some sort of visual highlighting. For controlling the tab order there's the tabindex attribute (added in svg2), which has the same behavior as in html. Tabbing through an svg probably works best if the svg is inline in the html document. Support for tabindex in svg is implemented in Blink and WebKit already. On Wed, 25 Mar 2015 21:24:04 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: One of the 2 objections, I'd say. But the second is probably a matter of implementation. SVG makes it unclear what's the actual active area when navigating through tab key. 2015-03-25 19:32 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com: On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine master.skywalker...@gmail.com wrote: Instead, we start by figuring out what problems need solving. Which is what has been done for this subject, I guess. PROBLEM: image maps, intended as shaped link areas related to specific regions of an image are a fairly requested feature. Unfortunately, as current solutions are not responsive and they can't fit to how images are defined in a modern scenario, with scalable size and art direction, authors have looked for workarounds, script-enhanced or non-native (Flash maps) solutions. POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where 1. CSS has a poor range of shapes 2. See above for SVG 3. area coordinates are absolutely defined. PROPOSAL: As SVG map is not viable at all in complex picture scenarios, and not easily viable in simple contexts, authors could benefit from map versatility. So a viable solution *could* be to improve a feature in order to make it responsive. The Map element improvement consortium is not an organisation I want to mindlessly support (basically because it doesn't exists). And unfortunately I tend to be verbose when I start writing. So in my last message I tried to make it shorter and I chose terms incorrectly. Note that we *should* just be able to use picture in SVG, which helps that solution. This is generally useful (we want responsive images inside of SVG, too), and afaict, removes the only objection to SVG. ~TJ -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
On 2015-03-31 16:09, Boris Zbarsky wrote: On 3/31/15 2:18 AM, Roger Hågensen wrote: What type of iframes would benefit from this? Ads, from a user point of view. Now getting them to opt in to being throttled... -Boris Would not a ad delivery network prefer not to have to push ads out that the user is not seeing at all? If not then they are only wasting bandwidth/CPU/memory on the server, and causing impressions that are wasted on nothing (important for the advertisers since they pay for them). It's not throttling, it's proper use of resources. And while a ad network can not be guaranteed there are eyeballs on the ad, they can at least be assured that the ad is visible. Imagine a clock or counter or similar, personally I'd love to use something similar for a status monitor for a server project, since it shows the live status there is no point in updating it while not visible, and the moment after being made visible again it will be current within a second. No wasted CPU no wasted bandwidth nor server resources. And I already mentioned video and audio (if autopause is taken beyond just iframes). I often open multiple tabs, and then I go through them one by one later. If I end up opening 3-4 videos at the same time I have to stop the other 3 so I do not get a cacophony of 4 videos at once. There is also the issue of quadruple bandwidth load on the server. I often also open anywhere from 2 to 20 tabs with pages in them, what point is there in doing ad rotation or similar in all those if I'm not looking at any of them except tab #19 ? But who knows, you may be right, getting people to op in is a issue, take gzip for example, almost a halving of the bandwidth on average yet there are so many sites out there not making use of it; but that is their choice and loss I guess. -- Roger Hågensen, Freelancer, http://skuldwyrm.no/
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On 3/30/2015 10:02 PM, Bobby Mozumder wrote: One thing I’m interested in is to see more technical discussions around this idea. Like, very specific issues that show a design or concept flaw. It’s only been about 10 days since I proposed this and I haven’t received much in that area. (I did change one thing to split MREF from HREF based on feedback about people wanting backwards compatibility.) Technical discussion is the last step of the process. The reason why people haven't provided technical feedback is because you have failed to motivate your proposal. Instead, I’m mostly getting a lot of “I’m scared!” or “Everyone should get a PhD in Javascript like I did!” which obviously isn’t going to happen. So, if there are technical faults with the proposal here, definitely list them. (or preferably in the Github, where I can keep track of issues directly) Attacking your detractors with ad hominems is a great way to get yourself ignored. People aren't saying those things--they're questioning the utility of your proposal in the first place. You take it for granted that HTML needs a complex, SQL-based MVC framework. You take it for granted that JS is the devil and should be avoided. You appear to take it for granted that using JS frameworks is a problem that needs to be solved. These views are not commonly held on this mailing list, and you're completely ignoring the feedback which is, in effect, questioning these assumptions. We need to be able to advance the web without going through Javascript. It’s a mistake to assume that JS is a fundamental part of the web. The web is optimized for hypertext document processing, and most people use it to read content online. This proposal fixes a remaining issue with that. Serious question: why? What benefit does it bring? That JS is bad is not a self-evident proposition. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
On 2015-03-31 20:55, Nils Dagsson Moskopp wrote: Roger Hågensen rh_wha...@skuldwyrm.no writes: I often open multiple tabs, and then I go through them one by one later. If I end up opening 3-4 videos at the same time I have to stop the other 3 so I do not get a cacophony of 4 videos at once. This is something that can be fixed by the UA: For Mozilla browsers, you can go to about:config and set media.autoplay.enabled to “false”. Also, the NoScript browser extension can make media click-to-play by default. I hardly think a lot of users want to follow directions like that. As a programmer/content designer it would make more sense to do so using either attributes or javascript instead of bothering the user. -- Roger Hågensen, Freelancer, http://skuldwyrm.no/
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
Roger Hågensen rh_wha...@skuldwyrm.no writes: I often open multiple tabs, and then I go through them one by one later. If I end up opening 3-4 videos at the same time I have to stop the other 3 so I do not get a cacophony of 4 videos at once. This is something that can be fixed by the UA: For Mozilla browsers, you can go to about:config and set media.autoplay.enabled to “false”. Also, the NoScript browser extension can make media click-to-play by default. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
On Mar 31, 2015, at 9:42 AM, Roger Hågensen rh_wha...@skuldwyrm.no wrote: Would not a ad delivery network prefer not to have to push ads out that the user is not seeing at all? If not then they are only wasting bandwidth/CPU/memory on the server, and causing impressions that are wasted on nothing (important for the advertisers since they pay for them). It's not throttling, it's proper use of resources. And while a ad network can not be guaranteed there are eyeballs on the ad, they can at least be assured that the ad is visible. There’s a strong motivation to reduce usage of the ad network’s resources. I’m less confident that ad networks will rush to opt in to this feature just to reduce usage of CPU and battery on end users’ machines, and that’s really what the feature is about. That said, “autopause” is an interesting idea! If changing the Page Visibility spec turns out to not be web compatible, a feature like “autopause” seems like a good alternative. And I already mentioned video and audio (if autopause is taken beyond just iframes). I think this would be great, and would definitely solve a common issue on pages that embed lots of media. - Seth
Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen
Roger Hågensen composed on 2015-03-31 21:09 (UTC+0200): ... For Mozilla browsers, you can go to about:config and set media.autoplay.enabled to âfalseâ. Also, the NoScript browser extension can make media click-to-play by default. I hardly think a lot of users want to follow directions like that. As a programmer/content designer it would make more sense to do so using either attributes or javascript instead of bothering the user. Turning off autoplay is a one time thing, not a big deal like the constant disrespect of sites disregarding instead of embracing user needs. Virtually every site bothers the user from the very moment any new domain is first accessed. Before support for IE6 was abandoned, some sites provided some respect for users by not sizing text in px units. Needing to zoom every new domain accessed to restore text to optimal size is bother. Needing to widen the viewport to accommodate the consequence of zooming so-called responsive pages is bother. Needing to click off unmovable flash needs update and works best with Javascript announcement popup windows is bother. Having to click a toolbar's readable bookmarklet to undo gray text is bother. All that activity just to make a site usable is considerable bother. Bother is a result of an assumption that because a page has been loaded that the visitor is ready right then to watch and listen to its contained media. Bother is a result of an assumption that because a page no longer has visibility, hearing its content is no longer desired. Bother is a result of control that is not in the hands of the user and his browser. I have a hard time seeing rationality in any option other than click-to-play. *My* PC is a tool. *I* should be the one to decide if and when to play, and if or when to stop or pause. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
