Re: Components F2F

2015-07-01 Thread Ryosuke Niwa

> On Jun 30, 2015, at 2:55 AM, Anne van Kesteren  wrote:
> 
> Can someone update
> https://www.w3.org/wiki/Webapps/WebComponentsJuly2015Meeting with a
> bit more information? I hear it might be in Mountain View?

Is Google hosting this meeting as well?  Alternatively, would other browser 
vendors (e.g. Mozilla) willing to host it this time?

Unfortunately, it's going to be really hard to reserve a big enough room at 
Apple :(  I'm hoping that'll change once we move to the new spaceship but we'll 
see...

> Will we have sufficient time to cover both Custom Elements and Shadow
> DOM? And could the drafts maybe be updated to cover what has been
> agreed to so far? E.g. it seems we have agreement on slots and I think
> that was the last major thing from Shadow DOM that needed a solution.
> Would be great if we could review a complete document.

I'm supposed to write up a document that summaries what we've agreed thus far.  
I've been busy with other stuff lately but will try to post it before the 
meeting.

- R. Niwa




Re: [shadow-dom] ::before/after on shadow hosts

2015-07-01 Thread Tab Atkins Jr.
All right, sounds pretty unanimous that #2 (current behavior) is what
we should go with. I'll clarify the Scoping spec.  Thanks!

~TJ



RE: PSA: publishing new WD of Service Workers on June 25

2015-07-01 Thread Jungkee Song
Thanks for comments. I'll address them in the ED.

I didn't get through them all yet, but

> * in parallel isn't defined, but it sounds like you mean "in parallel to the 
> main sequence" not "in parallel to themselves", I'd strongly encourage a 
> definition.

"in parallel" is defined here: 
https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel. Will 
add the links.


Jungkee

> -Original Message-
> From: timeless [mailto:timel...@gmail.com]
> Sent: Wednesday, July 01, 2015 1:23 PM
> To: public-webapps
> Subject: Re: PSA: publishing new WD of Service Workers on June 25
> 
> http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-
> service-workers-20150625/
> 
> > Invoke Run Service Worker algorithm with serviceWorker as the
> arguement [sic].
> > Fetch invokes Handle Fetch with request. As a result of performing
> Handle Fetch, the Service Woker [sic] returns a response to Fetch.
> >If the client request is under the scope of a service worker
> registration, appplication [sic] cache is completely bypassed regardless
> of whether the client request uses the service worker registration.
> 
> > Events that correspond to network requests are dispatched to the worker
> and the responses generated by the worker may over-ride* default network
> stack behavior.
> 
> override
> 
> en-us:
> >Let the origin attribute of e be initialized to the Unicode
> serialisation* of the origin specified by the incumbent settings object.
> > Service workers define the following behaviours* for install event and
> activate event:
> 
> 
> > When a service worker client is controlled by an active worker, it is
> considered the service worker client is using the active worker's
> containing service worker registration.
> 
> 
> this is awkward, you might add `that` after `it is`
> 
> 
> > This is conceptually the same operation that UA does maximum once per
> every 24 hours.
> 
> this is awkward, you might add `the` before `UA`, `a` after `does` and
> `of` before `once`.
> 
> > Run the following substeps in parallel:
> > 1. CheckRegistration: If the result of running Match Service Worker
> Registration algorithm, or its equivalent, with clientURL as its argument
> is not null, then:
> > 1.1. Set registration to the result value.
> > 2. Else:
> 
> Else seems odd for `run...in parallel`
> 
> > 2.1. Wait until scope to registration map has a new entry.
> > 2.2. Jump to the step labeled CheckRegistration.
> 
> cat spec|grep 'in parallel' | perl -pne 's/\s*,.*,\s*/ ...
> /;s/.*( run)/$1/;s/(the ).*( handler)/$1...$2/;s/^\s*/> /'|sort|uniq -
> c|sort
> -n|perl -pne 's/(?:\s*)(\d*)\s*(.*)\n/$2 [$1]\n/'
> > Return the ... handler ... performs the following substeps in
> > parallel: [1] Return the ... handler that performs the following
> > substeps in parallel: [1] Run the following in parallel: [1] Set p to
> > the ... handler that ... performs the following substeps in parallel:
> > [1] run the following substeps in parallel: [1] Return the ... handler
> > that ... performs the following substeps in parallel: [4] run the
> > following substeps in parallel. [4] Run these steps in parallel: [7]
> > Run the following substeps in parallel: [10]
> 
> * you use  interchangeably afaict; you sometimes don't use
> *steps...
> * you use <.|:> interchangeably
> * various other inconsistent stylistic elements can be seen from the above
> list...
> * in parallel isn't defined, but it sounds like you mean "in parallel to
> the main sequence" not "in parallel to themselves", I'd strongly encourage
> a definition.
> 
> > The following are the event handlers (and its corresponding event
> > handler event types) that must be supported,
> 
> pattern:
> event handlers [plural!] (and its ...)
> its => their
> 
> > The service worker registration's installing worker changes. (See step 8
> of the Install algorithm).
> > A WindowClient object has an associated focus state, which is either
> true or false. (Initially false).
> 
> pattern:
> misplaced `.`
> 
> > When event.respondWith(r) method is invoked, the argument, r, must
> resolve with a Response, else a network error is returned to Fetch.
> 
> `must .. else` is an odd construct. normally `or` is appropriate...
> 
> > The Cache objects do not expire unless authors delete the entries.
> 
> `objects ... the entries` is odd
> 
> the entries => them | objects => object entries ??
> 
> > This implies that authors should version their caches by name and make
> sure to **use the caches only from the version of the service worker that
> can safely operate on**.
> 
> ... => to only use caches that can be safely operated by the current
> version of the service worker.
> 
> > Cache objects are always enumerable via self.caches in insertion order
> > (per ECMAScript 6 Map objects.) Resolve p with the result of running
> > the algorithm specified in match(request, options) method of Cache
> > interface with request and options as the arguments (providing
> > entry.[[

Re: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

2015-07-01 Thread Xiaoqian Wu

> On 1 Jul, 2015, at 1:30 pm, Hayato Ito  wrote:
> 
> Thank you. I appreciate that. Then, let me migrate all open bugs of 
> 'Component Model'. I think that include also HTML Imports bugs in addition to 
> Custom Elements bugs.
> When I finish, I'll announce that.

SGTM. Please go ahead.

—
xiaoqian