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

[Hayato Ito]

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.

On Tue, Jun 30, 2015 at 11:21 PM Xiaoqian Wu  wrote:

> Hi Hayato,
>
> public-webapps has been removed from the default CC list of ‘Component
> Model’. Please let us know when you finish migrating and we will recover
> this component ASAP.
>
> Thanks.
>
> —
> xiaoqian
>
> > On 29 Jun, 2015, at 10:42 pm, Arthur Barstow 
> wrote:
> >
> > Yves, Xiaoqian, Mike - would one of you please do as Hayato requests
> below (and then notify him so he can move the Custom Elements bugs to
> Github)?
> >
> > -Thanks, ArtB
> >
> > On 6/25/15 2:49 AM, Hayato Ito wrote:
> >> I am thinking about migrating Custom Element bugs[1] to Web Components
> GitHub Issues [2], as I did it for Shadow DOM a few weeks ago, for the
> consistency.
> >>
> >> Could someone turn off the automatic email to public-webapps for Custom
> Elements Bugs in the bugzilla so that we won't receive the mass flood of
> bugspam by marking the all bugs MOVED? I'm assuming the automatic email is
> on for public-webapps@.
> >>
> >> If you have any concerns about migrating, let me know that.
> >>
> >> [1]
> https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968&hide_resolved=1
> >> [2] https://github.com/w3c/webcomponents/issues
> >>
> >> On Thu, May 28, 2015 at 10:35 AM Hayato Ito  hay...@google.com>> wrote:
> >>
> >>I totally agree. I'm really sorry for spamming. I forgot that
> >>closing a bug would trigger sending a mail to public-webapps@. My
> bad.
> >>
> >>I thought that a closing bug would notify only people who opted-in
> >>to add themselves to a list of cc in each bug. That might be a
> >>good opportunity for them to keep tracking of the bug status by
> >>subscribing a migrated bug on GitHub Issues.
> >>
> >>On Thu, May 28, 2015 at 6:49 AM Tab Atkins Jr.
> >>mailto:jackalm...@gmail.com>> wrote:
> >>
> >>Note for the future (to you and editors of other specs in
> >>WebApps):
> >>
> >>Before doing this kind of mass bug editting, please turn off the
> >>automatic email to public-webapps.  If you can't do that
> yourself,
> >>Mike Smith can (at least, he's done it in the past).  That
> >>prevents
> >>the mass flood of bugspam from clogging up people's inboxes. ^_^
> >>
> >>~TJ
> >>
> >>On Tue, May 26, 2015 at 8:30 PM, Hayato Ito  >>> wrote:
> >>> PSA: I've finished the migration. All open bugs are now
> >>marked as "MOVED"
> >>> with a link to the corresponding GitHub issue.
> >>>
> >>> On Mon, May 25, 2015 at 5:58 PM Hayato Ito
> >>mailto:hay...@google.com>> wrote:
> >>>>
> >>>> Regarding with the Shadow DOM spec, more and more workflows
> >>are happening
> >>>> [1] on GitHub w3c/webcomponents repository recently.
> >>>> Therefore, I am thinking about migrating the bugs of the
> >>Shadow DOM spec,
> >>>> from the bugzilla [2], to the GitHub issues [3], as some of
> >>other specs are
> >>>> already doing so.
> >>>>
> >>>> As an experiment, I've just migrated the existing open bugs
> >>on the
> >>>> bugzilla to the GitHub issues, by a tiny script I've
> >>written using GitHub
> >>>> APIs.
> >>>>
> >>>> Unless there is an objection to the migration, I am going
> >>to close the
> >>>> existing open Shadow DOM spec bugs on the bugzilla, with a
> >>link to the
> >>>> corresponding bug on the GitHub issues.
> >>>>
> >>>> Please let me know if you have a concern.
> >>>>
> >>>> [1] https://github.com/w3c/webcomponents/commits/gh-pages
> >>>> [2]
> >>https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978
> >>>> [3] https://github.com/w3c/webcomponents/issues
> >>>>
> >>>
> >>
> >
>
>

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

[timeless]

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.[[value]] as thisArgument to the [[Call]] 
> internal method of match(request, options).)

pattern:
misplaced `.` (the other way...)


> If r's method is neither `GET` nor `HEAD` and options.ignoreMethod is false, 
> resolve promise with an empty array.
> If options.ignoreMethod is false and request.method is neither "GET" nor 
> "HEAD", then:

you usually use ``s instead of ""s around GET/HEAD, which I found
weird, but here you didn't do that, which I find even weirder...

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

[Hayato Ito]

Yeah, ::before and ::after should be added as the children of the shadow
host in the composed tree, as a *pseudo* first child and a *pseudo* last
child.

On Wed, Jul 1, 2015 at 1:15 PM Elliott Sprehn  wrote:

> On Wed, Jul 1, 2015 at 12:08 AM, Hayato Ito  wrote:
>
>> > ::before and ::after are basically *siblings* of the shadow host,
>>
>> That's not a correct sentence. ::before and ::after shouldn't be a
>> siblings of the shadow host.
>> I just wanted to say that #2 is the desired behavior.
>>
>>
> Indeed they're children, immediately before and immediately after the
> composed children of an element.
>
> fwiw this is also how it must work to prevent breaking the web or
> implementing special cases.  (and ) has a ShadowRoot and
> input::before and input::after are both common ways to add decorations to
> input elements. I broke this once in WebKit and we found all that content.
>
> - E
>

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

[Elliott Sprehn]

On Wed, Jul 1, 2015 at 12:08 AM, Hayato Ito  wrote:

> > ::before and ::after are basically *siblings* of the shadow host,
>
> That's not a correct sentence. ::before and ::after shouldn't be a
> siblings of the shadow host.
> I just wanted to say that #2 is the desired behavior.
>
>
Indeed they're children, immediately before and immediately after the
composed children of an element.

fwiw this is also how it must work to prevent breaking the web or
implementing special cases.  (and ) has a ShadowRoot and
input::before and input::after are both common ways to add decorations to
input elements. I broke this once in WebKit and we found all that content.

- E

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

[Hayato Ito]

> ::before and ::after are basically *siblings* of the shadow host,

That's not a correct sentence. ::before and ::after shouldn't be a siblings
of the shadow host.
I just wanted to say that #2 is the desired behavior.


On Wed, Jul 1, 2015 at 1:01 PM Hayato Ito  wrote:

> The spec [1] also says:
>
> > ::before
> > Represents a styleable child pseudo-element immediately before the
> originating element’s actual content.
> > ::after
> > Represents a styleable child pseudo-element immediately before the
> originating element’s actual content.
>
> It sounds to me that ::before and ::after are basically *siblings* of the
> shadow host, instead of children. I think that should be the intended
> behavior.
>
> [1] http://www.w3.org/TR/css-pseudo-4/#generated-content
>
>
>
>
> On Wed, Jul 1, 2015 at 12:33 PM Erik Isaksen  wrote:
>
>> #2 for sure
>>
>> On Tue, Jun 30, 2015, 4:52 PM Tab Atkins Jr. 
>> wrote:
>>
>>> I was recently pointed to this StackOverflow thread
>>> <
>>> http://stackoverflow.com/questions/31094454/does-the-shadow-dom-replace-before-and-after/
>>> >
>>> which asks what happens to ::before and ::after on shadow hosts, as
>>> it's not clear from the specs.  I had to admit that I hadn't thought
>>> of this corner-case, and it wasn't clear what the answer was!
>>>
>>> In particular, there seem to be two reasonable options:
>>>
>>> 1. ::before and ::after are *basically* children of the host element,
>>> so they get suppressed when the shadow contents are displayed
>>>
>>> 2. ::before and ::after aren't *really* children of the host element,
>>> so they still show up before/after the shadow contents.
>>>
>>> According to the SO thread (I haven't tested this myself), Firefox and
>>> Chrome both settled on #2.  I'm fine to spec this in the Scoping
>>> module, I just wanted to be sure this was the answer we wanted.
>>>
>>> ~TJ
>>>
>>>

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

[Hayato Ito]

The spec [1] also says:

> ::before
> Represents a styleable child pseudo-element immediately before the
originating element’s actual content.
> ::after
> Represents a styleable child pseudo-element immediately before the
originating element’s actual content.

It sounds to me that ::before and ::after are basically *siblings* of the
shadow host, instead of children. I think that should be the intended
behavior.

[1] http://www.w3.org/TR/css-pseudo-4/#generated-content




On Wed, Jul 1, 2015 at 12:33 PM Erik Isaksen  wrote:

> #2 for sure
>
> On Tue, Jun 30, 2015, 4:52 PM Tab Atkins Jr.  wrote:
>
>> I was recently pointed to this StackOverflow thread
>> <
>> http://stackoverflow.com/questions/31094454/does-the-shadow-dom-replace-before-and-after/
>> >
>> which asks what happens to ::before and ::after on shadow hosts, as
>> it's not clear from the specs.  I had to admit that I hadn't thought
>> of this corner-case, and it wasn't clear what the answer was!
>>
>> In particular, there seem to be two reasonable options:
>>
>> 1. ::before and ::after are *basically* children of the host element,
>> so they get suppressed when the shadow contents are displayed
>>
>> 2. ::before and ::after aren't *really* children of the host element,
>> so they still show up before/after the shadow contents.
>>
>> According to the SO thread (I haven't tested this myself), Firefox and
>> Chrome both settled on #2.  I'm fine to spec this in the Scoping
>> module, I just wanted to be sure this was the answer we wanted.
>>
>> ~TJ
>>
>>

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

[Erik Isaksen]

#2 for sure

On Tue, Jun 30, 2015, 4:52 PM Tab Atkins Jr.  wrote:

> I was recently pointed to this StackOverflow thread
> <
> http://stackoverflow.com/questions/31094454/does-the-shadow-dom-replace-before-and-after/
> >
> which asks what happens to ::before and ::after on shadow hosts, as
> it's not clear from the specs.  I had to admit that I hadn't thought
> of this corner-case, and it wasn't clear what the answer was!
>
> In particular, there seem to be two reasonable options:
>
> 1. ::before and ::after are *basically* children of the host element,
> so they get suppressed when the shadow contents are displayed
>
> 2. ::before and ::after aren't *really* children of the host element,
> so they still show up before/after the shadow contents.
>
> According to the SO thread (I haven't tested this myself), Firefox and
> Chrome both settled on #2.  I'm fine to spec this in the Scoping
> module, I just wanted to be sure this was the answer we wanted.
>
> ~TJ
>
>

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

[Olli Pettay]

On 07/01/2015 02:48 AM, Tab Atkins Jr. wrote:

I was recently pointed to this StackOverflow thread

which asks what happens to ::before and ::after on shadow hosts, as
it's not clear from the specs.  I had to admit that I hadn't thought
of this corner-case, and it wasn't clear what the answer was!

In particular, there seem to be two reasonable options:

1. ::before and ::after are *basically* children of the host element,
so they get suppressed when the shadow contents are displayed

2. ::before and ::after aren't *really* children of the host element,
so they still show up before/after the shadow contents.

According to the SO thread (I haven't tested this myself), Firefox and
Chrome both settled on #2.  I'm fine to spec this in the Scoping
module, I just wanted to be sure this was the answer we wanted.

~TJ




Just after reading the first paragraph and without knowing what the 
implementations do
in this case I thought #2 would be the most obvious behavior to have.


-Olli

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

[Tab Atkins Jr.]

I was recently pointed to this StackOverflow thread

which asks what happens to ::before and ::after on shadow hosts, as
it's not clear from the specs.  I had to admit that I hadn't thought
of this corner-case, and it wasn't clear what the answer was!

In particular, there seem to be two reasonable options:

1. ::before and ::after are *basically* children of the host element,
so they get suppressed when the shadow contents are displayed

2. ::before and ::after aren't *really* children of the host element,
so they still show up before/after the shadow contents.

According to the SO thread (I haven't tested this myself), Firefox and
Chrome both settled on #2.  I'm fine to spec this in the Scoping
module, I just wanted to be sure this was the answer we wanted.

~TJ

Re: Async Image -> ImageData conversion

[Ashley Gullen]

If it's difficult to make ImageBitmap both an efficient drawing source and
a conversion intermediary, then we could add conversion functions to each
object that can be converted, e.g.:

HTMLImageElement.toBlob()
HTMLImageElement.toImageData()
Blob.toImageData()
ImageData.toBlob()

This seems inconsistent. For example to convert a Blob to an Image, you
should create a URL and set an Image's src to it; to convert a Blob to an
ImageBitmap, you should use createImageBitmap(blob); and then under this
proposal there's a third approach to convert a Blob to an ImageData, using
Blob.toImageData(). It also has a larger surface area, requiring changes to
several interfaces.

So perhaps it would be better to make ImageData the "hub" of conversion,
more like the first proposal I made. If ImageBitmap is a GPU-hosted
premultiplied resource, then ImageData is an expressly not-on-GPU
not-premultiplied alternative. That would mean adding something like this
to ImageData:

typedef (HTMLImageElement or Blob or ImageBitmap) ImageDataSource;

partial interface ImageData {
static Promise create(ImageDataSource source)
Promise toBlob()
}

ImageData can also be converted to HTMLImageElement via toBlob, ImageBitmap
via createImageBitmap, or a canvas via putImageData (which is still
synchronous, but no longer needs to be done purely for conversion reasons,
so probably means you really want it to appear in the canvas and therefore
should remain synchronous).

This covers all the conversion use cases I can think of without
complicating ImageBitmap's "without undue latency" requirement. There's no
more transferring going on either, which I think is now unnecessary since
you can get from HTMLImageElement to ImageData with one call. I think it's
more future-proof too since future types can be added to ImageDataSource
allowing new types to be converted without a new method being added.

Does this approach sound better?

Ashley


On 26 June 2015 at 16:37, Boris Zbarsky  wrote:

> On 6/26/15 4:07 AM, Ashley Gullen wrote:
>
>> I don't think we should extend HTMLImageElement because it is not
>> available in workers. Adding the conversion methods to ImageBitmap
>> allows workers to perform conversions using Blob (compressed image data)
>> in the place of HTMLImageElement.
>>
>
> Maybe I wasn't clear.  I was suggesting that we have the methods on both
> HTMLImageElement and ImageBitmap (and possibly on any other things we feel
> should have the methods directly).
>
>  I like the suggestion that "ImageBitmap be the hub of image conversion",
>>
>
> I agree that it sounds appealing, but it means ImageBitmap now has to
> serve two masters: it has to be something that you can paint from quickly
> (premultiplied, probably lives on the GPU) _and_ it needs to be something
> you can transferToImageData efficiently (better to not live on the GPU for
> this).
>
> Maybe that's OK; it's just a bit of a warning flag from my point of view
> when a single object is meant to do multiple quite different things; it
> makes it harder to have it be good at all of them...
>
> -Boris
>

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

[Xiaoqian Wu]

Hi Hayato, 

public-webapps has been removed from the default CC list of ‘Component Model’. 
Please let us know when you finish migrating and we will recover this component 
ASAP.

Thanks.

—
xiaoqian

> On 29 Jun, 2015, at 10:42 pm, Arthur Barstow  wrote:
> 
> Yves, Xiaoqian, Mike - would one of you please do as Hayato requests below 
> (and then notify him so he can move the Custom Elements bugs to Github)?
> 
> -Thanks, ArtB
> 
> On 6/25/15 2:49 AM, Hayato Ito wrote:
>> I am thinking about migrating Custom Element bugs[1] to Web Components 
>> GitHub Issues [2], as I did it for Shadow DOM a few weeks ago, for the 
>> consistency.
>> 
>> Could someone turn off the automatic email to public-webapps for Custom 
>> Elements Bugs in the bugzilla so that we won't receive the mass flood of 
>> bugspam by marking the all bugs MOVED? I'm assuming the automatic email is 
>> on for public-webapps@.
>> 
>> If you have any concerns about migrating, let me know that.
>> 
>> [1] 
>> https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14968&hide_resolved=1
>> [2] https://github.com/w3c/webcomponents/issues
>> 
>> On Thu, May 28, 2015 at 10:35 AM Hayato Ito > > wrote:
>> 
>>I totally agree. I'm really sorry for spamming. I forgot that
>>closing a bug would trigger sending a mail to public-webapps@. My bad.
>> 
>>I thought that a closing bug would notify only people who opted-in
>>to add themselves to a list of cc in each bug. That might be a
>>good opportunity for them to keep tracking of the bug status by
>>subscribing a migrated bug on GitHub Issues.
>> 
>>On Thu, May 28, 2015 at 6:49 AM Tab Atkins Jr.
>>mailto:jackalm...@gmail.com>> wrote:
>> 
>>Note for the future (to you and editors of other specs in
>>WebApps):
>> 
>>Before doing this kind of mass bug editting, please turn off the
>>automatic email to public-webapps.  If you can't do that yourself,
>>Mike Smith can (at least, he's done it in the past).  That
>>prevents
>>the mass flood of bugspam from clogging up people's inboxes. ^_^
>> 
>>~TJ
>> 
>>On Tue, May 26, 2015 at 8:30 PM, Hayato Ito >> wrote:
>>> PSA: I've finished the migration. All open bugs are now
>>marked as "MOVED"
>>> with a link to the corresponding GitHub issue.
>>>
>>> On Mon, May 25, 2015 at 5:58 PM Hayato Ito
>>mailto:hay...@google.com>> wrote:
>>>>
>>>> Regarding with the Shadow DOM spec, more and more workflows
>>are happening
>>>> [1] on GitHub w3c/webcomponents repository recently.
>>>> Therefore, I am thinking about migrating the bugs of the
>>Shadow DOM spec,
>>>> from the bugzilla [2], to the GitHub issues [3], as some of
>>other specs are
>>>> already doing so.
>>>>
>>>> As an experiment, I've just migrated the existing open bugs
>>on the
>>>> bugzilla to the GitHub issues, by a tiny script I've
>>written using GitHub
>>>> APIs.
>>>>
>>>> Unless there is an objection to the migration, I am going
>>to close the
>>>> existing open Shadow DOM spec bugs on the bugzilla, with a
>>link to the
>>>> corresponding bug on the GitHub issues.
>>>>
>>>> Please let me know if you have a concern.
>>>>
>>>> [1] https://github.com/w3c/webcomponents/commits/gh-pages
>>>> [2]
>>https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=14978
>>>> [3] https://github.com/w3c/webcomponents/issues
>>>>
>>>
>> 
> 

Components F2F

[Anne van Kesteren]

Can someone update
https://www.w3.org/wiki/Webapps/WebComponentsJuly2015Meeting with a
bit more information? I hear it might be in Mountain View?

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.


-- 
https://annevankesteren.nl/