[Bug 27151] New: [imports]: Poor grammar in the 3.1 Import Dependent section

[bugzilla]

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.

Re: Push API - PushRegistration and lifetime

[Martin Thomson]

On 22 October 2014 22:19, Shijun Sun  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.

Re: Push API change for permissions UX

[Martin Thomson]

On 23 October 2014 04:10, John Mellor  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 and Service Workers

[Jonas Sicking]

On Thu, Oct 23, 2014 at 2:27 PM, Tab Atkins Jr.  wrote:
> On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry  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
> 
> 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 and Service Workers

[Tab Atkins Jr.]

On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry  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

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

[Erik Corry]

Some drive-by observations:

* Push needs SW because you want to be able to run code when a push
message arrives, but you don't want to do that in the whole browser,
which is too heavy.
* 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

On Mon, Oct 20, 2014 at 5:42 PM, Jake Archibald  wrote:
> On 20 October 2014 03:18, Shijun Sun  wrote:
>>
>> What I'd like to get across is when the "push client" can handle generic
>> actions already, such as posting a toast notifications, waking up the
>> browser (or a subset of it) and let service workers to display each
>> notification might not be the best practice from performance perspective,
>
>
> Things I guess you'd do as a result of a push message:
>
> * Update caches
> * Show a notification
> * Focus a tab & tell it to do something
>
> Updating caches should be common, and it's something most native apps get
> very wrong. Take Twitter for example, I can tap a notification that shows a
> partial tweet, but I have poor/no connectivity so the full tweet doesn't
> load. The notification is now gone, so I'm left with less information than I
> had before I tapped the notification. Twitter should download and cache the
> full tweet before showing the notification.
>
> On top of that, there are conditions that could mean I don't want to show a
> notification, or hide an existing one:
>
> * User already has relevant content focused & visible
> * User reads the content elsewhere (a push message would trigger the hiding
> of the current notification)
>
> Also, if the user dismisses the notification, I may wish to send that info
> back to the server, and push a message that hides the notification on other
> devices. When you multiply that all together, we've got a large API, and
> we've probably done the appcache thing and forgotten about particular
> use-cases.
>
> In terms of RTC, let's imagine we receive a "Jeff's calling" push message.
> At this point I'd want to:
>
> * If there isn't a tab open to the calling app, open one
> * Else use the existing one
> * Focus it (forcing it over any lock screen - we don't have a way to do this
> yet)
> * postMessage the page telling it who's calling
> * If a call is already in progress, show a small overlay indicating the new
> call, with handling options
> * Else show a full screen "Jeff's calling" message with handling options,
> play ringtone until handled
>
> If the call is answered on a particular device, you'll want to push to other
> devices to stop "ringing".
>
> That's a rough design for what I think should happen, other people may have
> better ideas. I don't think now's the time to give a particular design a
> high-level API. I'd rather follow the extensible web model and expose the
> primitives, then build higher level bits based on common patterns that are
> observed.



-- 
Erik Corry

Google UK Limited Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ Registered in England Number: 3977902

Re: [streams-api] Seeking status of the Streams API spec

[Aaron Colwell]

The MSE spec doesn't reference the updated version of the spec. I
intentionally pinned it to the Nov 05, 2013 version of that spec so that we
didn't have broken references while the Streams spec was being reworked.

I have been chatting with Domenic about how to integrate the new Streams
APIs with MSE. I'm still trying to digest the whole spec and I'm trying to
come up with a proposal that will fit naturally in with the direction that
spec is going.

At this point it may just be better to remove appendStream() and its
related algorithms from the MSE spec since I don't believe any other
browser is going to implement the old Streams API. I can then file a bug to
track work on adding support for the new Streams API. In my opinion, that
is the best way to track the reality of the current situation.

Aaron

On Thu, Oct 23, 2014 at 10:46 AM, Jerry Smith (WINDOWS) <
jdsm...@microsoft.com> wrote:

> 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" :
> >> 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: [streams-api] Seeking status of the Streams API spec

[Jerry Smith (WINDOWS)]

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" :
>> 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: [streams] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]

[Domenic Denicola]

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: Push API - PushRegistration and lifetime

[Shijun Sun]

On Thursday, October 23, 2014 9:16 AM, Costin Manolache wrote:
> On Wed, Oct 22, 2014 at 10:19 PM, Shijun Sun  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-api] Seeking status of the Streams API spec

[David Singer]

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" :
>> 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: [streams-api] Seeking status of the Streams API spec

[chaals]

- annevk@, feras.moussa@, domenic@, acolwell@, art.barstow@

23.10.2014, 15:06, "Arthur Barstow" :
> 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

[Arthur Barstow]

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%20API&list_id=46026&product=WebAppsWG&resolution=---

[2] https://github.com/whatwg/streams/issues

Re: Push API change for permissions UX

[John Mellor]

On 22 October 2014 20:55, Jonas Sicking  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  wrote:

> On 22 October 2014 11:02, John Mellor  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

[shadow-dom] [Re: [WebComponents] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]]

[Hayato Ito]

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 ' 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 
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
>