[shadow-dom] [Re: [WebComponents] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]]
Hi Arthur and WebAppsWG, Status of Shadow DOM: Update since the last TPAC: - The new WD [1] was published. I plan to address the followings in the next six months: - Update the event path calculation algorithm [2] - Resolve 'In Document' issues [3] - Bring back 'shadow as function' to the spec [4] - Attribute inheritance for shadow trees [5] [1] http://www.w3.org/TR/2014/WD-shadow-dom-20140617/ [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887 [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365 [4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26033 [5] spec bug is not filed. Chrome's bug is here: https://code.google.com/p/chromium/issues/detail?id=420772 On Wed Oct 22 2014 at 9:02:02 PM Arthur Barstow art.bars...@gmail.com wrote: On 10/11/14 10:43 AM, Arthur Barstow wrote: If you are an Editor and you did not register for the meeting please note: a) If you can join the meeting via the teleconf bridge, please: 1) add your spec to the Potential Topics list and identify high priority discussion points; 2) plan to dial-in Monday morning (or let me know which open day + time slot you prefer to join the meeting). b) If you cannot remotely participate in the meeting, please provide a short status of your spec, including any major blocking issues as well as general plans and expectations for the next six months (including publications plans). Please start a separate thread and use your spec's short name as the Subject: prefix (f.ex. [html-imports] Oct 2014 status report and plans). Here is the list of specs whose Editor(s) did not register for the meeting (if I made any mistakes, I apologize in advance, but please do let me know): * Custom Elements: Dimitri. * HTML Imports: Hajime and Dimitri. * Shadow DOM: Hayato and Dimitri. Dimitri, Hajime, Hayato, Please see the above and respond accordingly, for your respective specs. -Thanks, ArtB [Agenda] https://www.w3.org/wiki/Webapps/November2014Meetin
Re: Push API change for permissions UX
On 22 October 2014 20:55, Jonas Sicking jo...@sicking.cc wrote: However I don't think that it makes sense for apps to commit to displaying UI when there's an incoming push. I'm not sure what problem that would solve? It means the user is aware of incoming pushes, which alleviates two concerns: 1. Geoip tracking: an app that sends silent push messages which trigger network fetches might be able to infer the user's location history based on the IP addresses of their WiFi routers, cellular masts, etc. Web pages loaded in tabs can of course already do this unless you use an anonymizing proxy, as can native apps on all OSes, and sadly it's very hard to explain this risk to users; but at least for open tabs the user has some awareness that these pages are active, and more importantly can close them. If an app (almost) always shows user-visible UI when handling push messages, at least the user will have some awareness that stuff is going on in the background (and unless the UI shown by the app is useful, the user is likely to revoke its push permission). 2. Resource usage: apps handling silent push messages might expend large amounts of battery or data (or frequently kick out other apps through high peak RAM usage), without necessarily being useful to the user. If instead an app (almost) always shows user-visible UI when handling a push message, this will inherently limit the frequency of push messages (as we intend on making it very easy to revoke push permission from notifications and any future user-visible UI, so that developers are incentivized not to spam users). It seems like in many cases you need to run client side code in order to determine if UI should be displayed or not. For example the user might be in a don't disturb me mode or have configured a VoIP app to blocklist a certain caller from calling. Yes, agreed. The idea is that apps which are able to make the commitment would only trigger one permissions prompt; apps which cannot commit to userVisibleOnly would still be allowed (except temporarily in Chrome if we ship userVisibleOnly push before shipping full push), but would simply trigger an additional doing-stuff-in-the-background permission prompt. In many cases, triggering the additional permission prompt may well be a worthwhile trade-off for developers in order to provide a net better user experience. On 23 October 2014 04:23, Martin Thomson martin.thom...@gmail.com wrote: On 22 October 2014 11:02, John Mellor joh...@google.com wrote: a restricted form of push where each push event fired on the SW must trigger user-visible UI. How would that work? Is the idea that there would be a default notification that the SW could alter the contents of (perhaps), but not prevent or indefinitely delay? Exactly. The current thought is that if a site opts in to userVisibleOnly pushes, then if it doesn't show user-visible UI (initially a notification) by the end of the event.waitUntil on almost (sporadic errors would be forgiven) every incoming push message (not counting times where the web app is in the foreground, or user-visible UI was already showing, or has been shown recently), then the UA would show a default notification. Developers would of course be strongly incentivised to show their own UI instead, since its content would always be more relevant than the default notification, hence users would be less likely to revoke the site's push permission. (We had previously discussed heavy throttling of pushes that don't show user-visible UI, but discarded that as it would make push unreliable/inconsistent.) I'm not convinced of the virtue of something like that. It attaches a specific kind of penalty to the use of push that might discourage its use, but I'm not sure that it creates the right sort of disincentive. Can you elaborate? This would attach no penalty to developers who don't opt in (at the one time cost of an additional permission prompt); and as I explained above, developers who do opt in would indeed be incentivized to always show user-visible UI. Are you concerned that this is not the right thing to be incentivising? Thanks, John
Re: [streams-api] Seeking status of the Streams API spec
On 10/22/14 6:27 PM, Paul Cotton wrote: given the magnitude of the changes in [changeset], a new WD should be published. Can we please wait until after the TPAC week to publish the proposed Streams heartbeat? Given the substantive changes being made here I think it would be best to have a WebApps WG discussion as proposed by Art [1] BEFORE publishing such a heartbeat. I think the draft WD captures the recent developments and discussions (certainly much better than the previous WD) so I prefer to go ahead with the publication and if there are any issues, bugs, etc., they should be raised via [1] (or [2] if applicable). -AB [1] https://www.w3.org/Bugs/Public/buglist.cgi?component=Streams%20APIlist_id=46026product=WebAppsWGresolution=--- [2] https://github.com/whatwg/streams/issues
Re: [streams-api] Seeking status of the Streams API spec
- annevk@, feras.moussa@, domenic@, acolwell@, art.barstow@ 23.10.2014, 15:06, Arthur Barstow art.bars...@gmail.com: On 10/22/14 6:27 PM, Paul Cotton wrote: given the magnitude of the changes in [changeset], a new WD should be published. Can we please wait until after the TPAC week to publish the proposed Streams heartbeat? Given the substantive changes being made here I think it would be best to have a WebApps WG discussion as proposed by Art [1] BEFORE publishing such a heartbeat. I think the draft WD captures the recent developments and discussions (certainly much better than the previous WD) so I prefer to go ahead with the publication and if there are any issues, bugs, etc., they should be raised Seconded. Note there is no reason not to raise the topic in discussion at TPAC, with the two drafts available for comparison. Working Drafts do not reflect consensus... cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
Re: [streams-api] Seeking status of the Streams API spec
On Oct 23, 2014, at 15:10 , cha...@yandex-team.ru wrote: - annevk@, feras.moussa@, domenic@, acolwell@, art.barstow@ 23.10.2014, 15:06, Arthur Barstow art.bars...@gmail.com: On 10/22/14 6:27 PM, Paul Cotton wrote: given the magnitude of the changes in [changeset], a new WD should be published. Can we please wait until after the TPAC week to publish the proposed Streams heartbeat? Given the substantive changes being made here I think it would be best to have a WebApps WG discussion as proposed by Art [1] BEFORE publishing such a heartbeat. I think the draft WD captures the recent developments and discussions (certainly much better than the previous WD) so I prefer to go ahead with the publication and if there are any issues, bugs, etc., they should be raised Seconded. Note there is no reason not to raise the topic in discussion at TPAC, with the two drafts available for comparison. Working Drafts do not reflect consensus… well, they do and they don't editor’s drafts do not reflect consensus of any kind working drafts (roughly) reflect where the WG thinks it is, not all of which is done or has consensus (in terms of content), but it does have consensus that the draft reflects the WG's current ‘best thinking’ cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com David Singer Manager, Software Standards, Apple Inc.
RE: Push API - PushRegistration and lifetime
On Thursday, October 23, 2014 9:16 AM, Costin Manolache wrote: On Wed, Oct 22, 2014 at 10:19 PM, Shijun Sun shij...@microsoft.com wrote: It'd be very helpful if PushRegistration can have a read-only attribute for ExpirationTime or something like that. Webapps can be more proactive if the ExpirationTime is set. I agree. Okay, I'll open a bug in GitHub to track this.
RE: [streams] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]
From: Arthur Barstow [mailto:art.bars...@gmail.com] I think recent threads about Streams provided some useful information about the status and plans for Streams. I also think it could be useful if some set of you were available to answer questions raised at the meeting. Can any of you commit some time to be available? If so, please let me know some time slots you are available. My preference is Monday morning, if possible. I'd be happy to call in at that time or another. Just let me know so I can put it in my calendar.
RE: [streams-api] Seeking status of the Streams API spec
Separate from heartbeat publication, we don't believe it is appropriate to directly reference this spec in MSE until some questions are answered about how streams will be represented. Jerry -Original Message- From: David Singer [mailto:sin...@apple.com] Sent: Thursday, October 23, 2014 6:26 AM To: cha...@yandex-team.ru Cc: Paul Cotton; Takeshi Yoshino; Jerry Smith (WINDOWS); public-webapps; public-html-me...@w3.org Subject: Re: [streams-api] Seeking status of the Streams API spec On Oct 23, 2014, at 15:10 , cha...@yandex-team.ru wrote: - annevk@, feras.moussa@, domenic@, acolwell@, art.barstow@ 23.10.2014, 15:06, Arthur Barstow art.bars...@gmail.com: On 10/22/14 6:27 PM, Paul Cotton wrote: given the magnitude of the changes in [changeset], a new WD should be published. Can we please wait until after the TPAC week to publish the proposed Streams heartbeat? Given the substantive changes being made here I think it would be best to have a WebApps WG discussion as proposed by Art [1] BEFORE publishing such a heartbeat. I think the draft WD captures the recent developments and discussions (certainly much better than the previous WD) so I prefer to go ahead with the publication and if there are any issues, bugs, etc., they should be raised Seconded. Note there is no reason not to raise the topic in discussion at TPAC, with the two drafts available for comparison. Working Drafts do not reflect consensus... well, they do and they don't editor's drafts do not reflect consensus of any kind working drafts (roughly) reflect where the WG thinks it is, not all of which is done or has consensus (in terms of content), but it does have consensus that the draft reflects the WG's current 'best thinking' cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com David Singer Manager, Software Standards, Apple Inc.
Re: Push API and Service Workers
On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry erikco...@google.com wrote: * Push doesn't actually need SW's ability to intercept network communications on behalf of a web page. * You can imagine a push-handling SW that does all sorts of complicated processing of notifications, downloading things to a local database, but does not cache/intercept a web page. * This ties into the discussion of whether it should be possible to register a SW without giving it a network-intercept namespace As was discussed over in https://github.com/slightlyoff/ServiceWorker/issues/445#issuecomment-60304515 earlier today, you need a scope for all uses of SW, because you need to *request permission* on a *page*, not within a SW (so the user has appropriate context on whether to grant the permission or not), and the scope maps the page to the SW that the registration is for. (The permission grant is actually per-origin, not per-scope/SW, but the registration itself is per-scope/SW, and it has to be done from within a page context because there *might* be a permission grant needed.) ~TJ
Re: Push API and Service Workers
On Thu, Oct 23, 2014 at 2:27 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry erikco...@google.com wrote: * Push doesn't actually need SW's ability to intercept network communications on behalf of a web page. * You can imagine a push-handling SW that does all sorts of complicated processing of notifications, downloading things to a local database, but does not cache/intercept a web page. * This ties into the discussion of whether it should be possible to register a SW without giving it a network-intercept namespace As was discussed over in https://github.com/slightlyoff/ServiceWorker/issues/445#issuecomment-60304515 earlier today, you need a scope for all uses of SW, because you need to *request permission* on a *page*, not within a SW (so the user has appropriate context on whether to grant the permission or not), and the scope maps the page to the SW that the registration is for. (The permission grant is actually per-origin, not per-scope/SW, but the registration itself is per-scope/SW, and it has to be done from within a page context because there *might* be a permission grant needed.) Yes, you need to ask for permission within a page. But that page doesn't have to have any particular relation to the scope of the SW that it's asking for. It just needs to be same-origin with that SW. As the API is structured, any page on a website can grab any SW registration, and call registerPush or registerGeoFence on that SW registration. So I don't see how the scope of the SW matters. / Jonas
Re: Push API change for permissions UX
On 23 October 2014 04:10, John Mellor joh...@google.com wrote: Can you elaborate? This would attach no penalty to developers who don't opt in (at the one time cost of an additional permission prompt); and as I explained above, developers who do opt in would indeed be incentivized to always show user-visible UI. Are you concerned that this is not the right thing to be incentivising? Yes, it increases the cost in terms of battery consumption and user annoyance for push messages. Both of which we strive to minimize. You might claim that the app needs to take responsibility for this, but I'm less certain. It means that important features that provide these measures (do not disturb, more contextual event filtering) are not available to applications by default. I'd like to find better ways of dealing with this problem. This approach seems like more of a cop-out to me. I'm seriously jet-lagged, so only two ideas spring to mind, I'm sure you can find some more if you set your mind to it: Usage budgets might be applied to various resources, after which a SW is activated less often. Or good accounting and reporting (see various activity monitors on different operating systems that account for all sorts of resource usage, or you could generate simple notifications like: this app is burning your battery/network, turn it off?)
Re: Push API - PushRegistration and lifetime
On 22 October 2014 22:19, Shijun Sun shij...@microsoft.com wrote: Thanks Martin. It'd be very helpful if PushRegistration can have a read-only attribute for ExpirationTime or something like that. Webapps can be more proactive if the ExpirationTime is set. I was thinking that this was a protocol concern primarily and that the UA would be the best place to be proactive. As Costin points out, if we get individual apps being proactive, they won't know about whether the radio is on, and they won't coordinate properly. I think that I'd prefer to have the UA consume any expiration information and not expose it in the API.
[Bug 27151] New: [imports]: Poor grammar in the 3.1 Import Dependent section
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27151 Bug ID: 27151 Summary: [imports]: Poor grammar in the 3.1 Import Dependent section Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: apav...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 20683 To track requested imports, each document has an import link list, each of whose item is consist of link, the link element and location, a URL. Also, the item is optionally marked as branch. The list is empty at beginning and the item is added as import request algorithm specifies. This should probably rephrased along the lines of: To track requested imports, each document has an import link list. Each of its items consists of link, a link element, and location, a URL. Also, the item is optionally marked as branch. The list is initially empty, and items are added to it as specified by the import request algorithm. -- You are receiving this mail because: You are on the CC list for the bug.
