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

2015-06-30 Thread Erik Isaksen
#2 for sure

On Tue, Jun 30, 2015, 4:52 PM Tab Atkins Jr. jackalm...@gmail.com 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

2015-06-30 Thread Olli Pettay

On 07/01/2015 02:48 AM, 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




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



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

2015-06-30 Thread 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 hay...@chromium.org 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 nevra...@gmail.com wrote:

 #2 for sure

 On Tue, Jun 30, 2015, 4:52 PM Tab Atkins Jr. jackalm...@gmail.com
 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: PSA: publishing new WD of Service Workers on June 25

2015-06-30 Thread 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 steps|substeps 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...



Components F2F

2015-06-30 Thread 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/



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

2015-06-30 Thread Elliott Sprehn
On Wed, Jul 1, 2015 at 12:08 AM, Hayato Ito hay...@chromium.org 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. input (and textarea) 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: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

2015-06-30 Thread 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 xiaoq...@w3.org 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 art.bars...@gmail.com
 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=14968hide_resolved=1
  [2] https://github.com/w3c/webcomponents/issues
 
  On Thu, May 28, 2015 at 10:35 AM Hayato Ito hay...@google.com mailto:
 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.
 jackalm...@gmail.com 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 hay...@google.com
 mailto:hay...@google.com 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
 hay...@google.com 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: [shadow-dom] ::before/after on shadow hosts

2015-06-30 Thread 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 nevra...@gmail.com wrote:

 #2 for sure

 On Tue, Jun 30, 2015, 4:52 PM Tab Atkins Jr. jackalm...@gmail.com 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

2015-06-30 Thread 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 espr...@chromium.org wrote:

 On Wed, Jul 1, 2015 at 12:08 AM, Hayato Ito hay...@chromium.org 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. input (and textarea) 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: [admin] Moving Custom Elements bugs to Github [Was: Re: Custom Elements bugs will be also migrated]

2015-06-30 Thread 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 art.bars...@gmail.com 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=14968hide_resolved=1
 [2] https://github.com/w3c/webcomponents/issues
 
 On Thu, May 28, 2015 at 10:35 AM Hayato Ito hay...@google.com 
 mailto: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.
jackalm...@gmail.com 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 hay...@google.com
mailto:hay...@google.com 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
hay...@google.com 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: Async Image - ImageData conversion

2015-06-30 Thread 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 PromiseImageData create(ImageDataSource source)
PromiseBlob 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 bzbar...@mit.edu 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



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

2015-06-30 Thread Tab Atkins Jr.
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