[Bug 9514] [Selection] Specify Selection.modify()

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=9514

Ryosuke Niwa  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |MOVED

--- Comment #10 from Ryosuke Niwa  ---
This is now tracked by https://github.com/w3c/selection-api/issues/37.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 24106] FKA: No defined way to get keyboard focus into and out of a shadow DOM component

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24106
Bug 24106 depends on bug 23870, which changed state.

Bug 23870 Summary: FKA: No defined way to get keyboard focus into and out of a 
shadow DOM component
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23870

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [Custom Elements] Extension of arbitrary elements at runtime.

[Brian Kardell]

On Sun, Apr 10, 2016 at 11:11 PM, /#!/JoePea  wrote:

> The is="" attribute lets one specify that some element is actually an
> extended version of that element.
>
> But, in order for this to work, the Custom Element definition has to
> deliberately extend that same basic element type or else it won't
> work.
>
> It'd be nice if a Custom Element definition could be arbitrarily
> applied to any type of element, with the is="" tag for example, and
> that the element would then be upgraded to the extending type at
> runtime. The custom element could be told what class it is extending
> at runtime in order to perhaps act differently using conditional
> statements.
>
> So, writing defining the element could be like this:
>
> ```js
> let isDynamic = true
> document.registerElement('some-element', {
>   createdCallback: function() {
> if (this.typeExtended == 'DIV")
>   // ...
> if (this.typeExtended == 'BUTTON')
>   // ...
>   },
> }, isDynamic)
> ```
>
> then using the element could be like this:
>
> ```html
> 
> 
> 
> ```
>
> What are your thoughts on such a way to extend any type of element at
> runtime? Could it be a way for augmenting, for example, an existing
> app without necessarily having to modify it's markup, just simply
> adding is="" attributes as needed? Would this make things too
> complicated?
>
> The real reason I thought of this idea is because:
> https://github.com/infamous/infamous/issues/5
>
> There might be a better way, but thought I'd mention it just in case
> it sparks any ideas.
>
> Cheers!
> - Joe
>
> /#!/JoePea
>
>

Is there a reason that you cannot wrap with fallback?  For example, in your
github issue you are given and existing app with markup like:


  
Hello
  


and the issue wanted to change it to


  
Hello
  


Is there a reason it could it not just be


  
  
Hello




There isn't really a significant difference between div and motor-scene to
non-supporting browsers.


-- 
Brian Kardell :: @briankardell

Re: [Custom Elements] Extension of arbitrary elements at runtime.

[/#!/JoePea]

Hello Brian

The purpose of the motor-scene and motor-node elements is that they will be
easy to apply 3D transforms to (and WebGL soon), with easing for example. I
suppose a better approach for augmenting and existing DOM could be to
simply apply the transforms via selectors instead of trying to apply the
behavior via extending with is="". This wouldn't allow custom attributes
though, like extending would.

I think the best solution, for now, is as you recommended: to add the
layers if possible.

Thanks for the input!
- Joe

On Monday, April 11, 2016, Brian Kardell  wrote:

>
>
> On Sun, Apr 10, 2016 at 11:11 PM, /#!/JoePea  > wrote:
>
>> The is="" attribute lets one specify that some element is actually an
>> extended version of that element.
>>
>> But, in order for this to work, the Custom Element definition has to
>> deliberately extend that same basic element type or else it won't
>> work.
>>
>> It'd be nice if a Custom Element definition could be arbitrarily
>> applied to any type of element, with the is="" tag for example, and
>> that the element would then be upgraded to the extending type at
>> runtime. The custom element could be told what class it is extending
>> at runtime in order to perhaps act differently using conditional
>> statements.
>>
>> So, writing defining the element could be like this:
>>
>> ```js
>> let isDynamic = true
>> document.registerElement('some-element', {
>>   createdCallback: function() {
>> if (this.typeExtended == 'DIV")
>>   // ...
>> if (this.typeExtended == 'BUTTON')
>>   // ...
>>   },
>> }, isDynamic)
>> ```
>>
>> then using the element could be like this:
>>
>> ```html
>> 
>> 
>> 
>> ```
>>
>> What are your thoughts on such a way to extend any type of element at
>> runtime? Could it be a way for augmenting, for example, an existing
>> app without necessarily having to modify it's markup, just simply
>> adding is="" attributes as needed? Would this make things too
>> complicated?
>>
>> The real reason I thought of this idea is because:
>> https://github.com/infamous/infamous/issues/5
>>
>> There might be a better way, but thought I'd mention it just in case
>> it sparks any ideas.
>>
>> Cheers!
>> - Joe
>>
>> /#!/JoePea
>>
>>
>
> Is there a reason that you cannot wrap with fallback?  For example, in
> your github issue you are given and existing app with markup like:
>
> 
>   
> Hello
>   
>
>
> and the issue wanted to change it to
>
> 
>   
> Hello
>   
>
>
> Is there a reason it could it not just be
>
> 
>   
>   
> Hello
> 
> 
>
>
> There isn't really a significant difference between div and motor-scene to
> non-supporting browsers.
>
>
> --
> Brian Kardell :: @briankardell
>


-- 
/#!/JoePea

[Custom Elements] They are globals.

[/#!/JoePea]

Hello,

Is it possible to take an approach more similar to React where Custom
Elements aren't registered in a global pool? What if two libraries we'd
like to use define elements of the same name, and we wish to import these
via `import` and not modify the source code of our dependencies?

I don't really see the solution yet (if any), since the browser needs to
know about the elements in order to make them work.

Any thoughts? Is a more encapsulated approach possible?

Regards,
- Joe


-- 
/#!/JoePea

Re: [Custom Elements] More ES6-like API

[Ryosuke Niwa]

That's exactly what we're doing. The latest spec uses ES6 class constructor to 
define custom elements. See an example below this section in DOM spec: 
https://dom.spec.whatwg.org/#concept-element-custom-element-state

- R. Niwa

> On Apr 10, 2016, at 7:58 PM, /#!/JoePea  wrote:
> 
> It'd be nice if users could define actual constructors, as described here:
> 
> https://github.com/w3c/webcomponents/issues/423#issuecomment-208131046
> 
> Cheers!
> - Joe
> 
> /#!/JoePea
> 

Re: [Custom Elements] They are globals.

[Ryosuke Niwa]

> On Apr 11, 2016, at 9:02 AM, /#!/JoePea  wrote:
> 
> Is it possible to take an approach more similar to React where Custom 
> Elements aren't registered in a global pool? What if two libraries we'd like 
> to use define elements of the same name, and we wish to import these via 
> `import` and not modify the source code of our dependencies?
> 
> I don't really see the solution yet (if any), since the browser needs to know 
> about the elements in order to make them work.
> 
> Any thoughts? Is a more encapsulated approach possible?

We discussed a similar issue related to having multiple documents per global 
object: https://github.com/w3c/webcomponents/issues/369 


The problem here is that HTMLElement constructor, which is involved as a super 
call in a custom element constructor, cannot determine which set of custom 
elements to use because it doesn't get any contextual information about where 
the element is constructed.

- R. Niwa

RE: [Custom Elements] They are globals.

[Domenic Denicola]

I think you are being misled by a superficial similarity with React's JSX.

JSX's `` desugars to `React.createElement(Foo)`, which creates a `` 
element with some of its behavior derived from the `Foo` class, found in 
JavaScript lexical scope. The `Foo` token has no impact on the DOM tree.

Custom elements' `` is completely unlike that. In that case, `x-foo` is 
a tag name, and a full participant in the DOM tree structure. It affects CSS 
selector matching, APIs like querySelector and getElementsByTagName, and more. 
It's not just a div.

As Ryosuke notes, it's very hard to imagine how "scoped tag names" would work. 
Both for implementation reasons, like the HTMLElement constructor, but also for 
cases like CSS or the DOM APIs, which operate fundamentally on a global mapping.

Re: [Custom Elements] More ES6-like API

[/#!/JoePea]

Thanks Ryosuke! That's looking a lot better.
/#!/JoePea


On Mon, Apr 11, 2016 at 10:28 AM, Ryosuke Niwa  wrote:
> That's exactly what we're doing. The latest spec uses ES6 class constructor 
> to define custom elements. See an example below this section in DOM spec: 
> https://dom.spec.whatwg.org/#concept-element-custom-element-state
>
> - R. Niwa
>
>> On Apr 10, 2016, at 7:58 PM, /#!/JoePea  wrote:
>>
>> It'd be nice if users could define actual constructors, as described here:
>>
>> https://github.com/w3c/webcomponents/issues/423#issuecomment-208131046
>>
>> Cheers!
>> - Joe
>>
>> /#!/JoePea
>>

Re: [Custom Elements] They are globals.

[/#!/JoePea]

I get what you mean about the behaviors defined from classes that
exist in the scope, in React. The really great thing about React is
the ability to compose a class by using multiple classes to return the
render spec. One of React's strong-points at a high level is it offers
encapsulation where the components used in the HTML (which don't map
directly to the actual DOM result that the browser is finally given)
are specific to the component, encapsulated there.

The current methods of encapsulation that I see with normal HTML are
documents and shadow roots, where shadow roots seem to be closer to
React than documents because the top-level HTML that we inspect in the
DOM may not be what is actually rendered (like with React), although
the implementation is completely different, but at a high level shadow
dom has that small similarity with React.

So, to make code-reuse as possible as it is with React (due to React's
aforementioned encapsulation and use of the JavaScript scopefor it's
"HTML elements"), maybe the Custom Element API can take advantage of
ShadowDOM instead of documents?

What if custom elements can be registered on a shadow-root basis, so
that the author of a Custom Element (one that isn't registered by
default) can register a bunch of elements that it's shadow root will
use, passing constructors that the author code may have imported from
anywhere. Then that same author simply exports the custom element
(does not register it) for a following author to use. The following
author would import that custom element, then register it with the
shadow roots of his/her new custom elements, and thus the cycle
continues, with registered elements defined on shadow roots on a
per-custom-element basis, without those elements ever being registered
to some global registry.

```
// library code
import SomeClass from './somewhere'

export default
class AuthorElement extends HTMLElement {
constructor() {
this.shadowRoot.defineElement(
'authors-should-call-this-anything-they-want',
SomeClass
)
// ...
}
}
```

Then, finally, the top-level app author can register the top-most
custom elements using an API similar to current, in the top-level
namespace (global scope) for the window or document.

```
// app code
import AuthorElement from './AuthorElement'
document.defineElement(
'any-name-the-app-author-wants',
SomeClass
)
```

So, basically, inaddition to global/window-or-document-based elements
there'd also be shadow root definitions for encapsulation, since
shadow roots are to custom elements as what (slightly stretched) JSX
specs are to React components.

An important part of the Custom Element API would be that Custom
Element authors should never register their Custom Elements globally,
only export them for the user of their custom element to register
them. The final top-level app author would register only the elements
that will be used in the top-level HTML of the app, all other elements
already registered in their shadow roots by the authors of each
element.

Something like this would create a development environment much more
similar to React, having encapsulation and making code more re-usable.
The only downside of this approach would be the need to manually
register elements per-shadow-root, not just importing them (in react,
importing is enough, as the JSX uses the JavaScript scope as the
element registry).

On a side note, interestingly, template string tag functions would let
us take advantage of JavaScript scope directly without build tools:

```
import SomeClass from './SomeClass'
import OtherClass from './OtherClass'

html`
  
  <${SomeClass}>
  <${OtherClass}>
  
  
  
`
```
/#!/JoePea


On Mon, Apr 11, 2016 at 11:25 AM, Domenic Denicola  wrote:
> I think you are being misled by a superficial similarity with React's JSX.
>
> JSX's `` desugars to `React.createElement(Foo)`, which creates a `` 
> element with some of its behavior derived from the `Foo` class, found in 
> JavaScript lexical scope. The `Foo` token has no impact on the DOM tree.
>
> Custom elements' `` is completely unlike that. In that case, `x-foo` 
> is a tag name, and a full participant in the DOM tree structure. It affects 
> CSS selector matching, APIs like querySelector and getElementsByTagName, and 
> more. It's not just a div.
>
> As Ryosuke notes, it's very hard to imagine how "scoped tag names" would 
> work. Both for implementation reasons, like the HTMLElement constructor, but 
> also for cases like CSS or the DOM APIs, which operate fundamentally on a 
> global mapping.
>

Re: [Custom Elements] They are globals.

[Ryosuke Niwa]

> On Apr 11, 2016, at 2:29 PM, /#!/JoePea  wrote:
> 
> What if custom elements can be registered on a shadow-root basis, so
> that the author of a Custom Element (one that isn't registered by
> default) can register a bunch of elements that it's shadow root will
> use, passing constructors that the author code may have imported from
> anywhere. Then that same author simply exports the custom element
> (does not register it) for a following author to use. The following
> author would import that custom element, then register it with the
> shadow roots of his/her new custom elements, and thus the cycle
> continues, with registered elements defined on shadow roots on a
> per-custom-element basis, without those elements ever being registered
> to some global registry.
> 
> ```
> // library code
> import SomeClass from './somewhere'
> 
> export default
> class AuthorElement extends HTMLElement {
>constructor() {
>this.shadowRoot.defineElement(
>'authors-should-call-this-anything-they-want',
>SomeClass
>)
>// ...
>}
> }
> ```

Now, let's say you do "new SomeClass" now, and SomeClass is defined as follows:

```js
class SomeClass extends HTMLElement {
constructor()
{
super(); // (1)
}
}
```

When HTMLElement's constructor is involved in (1), it needs to construct an 
element by the name of "authors-should-call-this-anything-they-want".  However, 
it has no idea to which shadow root or document it belongs.  The fundamental 
here is that any construction of new element now needs to specify the shadow 
root or document for which it is created so simple "new SomeClass" would not 
work.  You'd have to instead write it as "new SomeClass(this.shadowRoot)" and 
then (1) needs to be modified as: `super(..arguments)` to pass the argument 
along to the HTMLElement constructor.

- R. Niwa

Re: [service worker] f2f meeting notes, next meeting details

[Ali Alabbas]

Hello, here are the day 1 meeting notes from the service worker F2F. The 
attendees are CC'd if there are any corrections that need to be made or if 
anyone has any questions or concerns that they would like to raise.

=

Service Worker F2F
April 11, 2016


Attendees:
-
   * Microsoft - Ali Alabbas, Jatinder Mann, Adrian Bateman, Travis Leithead
   * Google - Joshua Bell, Matt Falkenhagen, Jake Archibald, Alex Russell, 
Marijn Kruisselbrink
   * Mozilla - Ehsan Akhgari, Ben Kelly
   * Samsung - Jungkee Song
   * Apple - Ted O'Connor


Agenda:
-
   * Vendor comments on general direction
   * v1 issues
 

Vendor comments on general direction (e.g. Tim’s comment)
-
   * Service workers are overly complicated for simple use cases
   * Ted O’Connor: don't worry about Tim's comment
   * Matt Falkenhagen: Average time for starting up SW when a fetch is 
registered is 150 ms
 

v1 Issues:
-
   * #861: be more explicit that jobs always run asynchronously
  * Already implemented this way in Gecko, but would be nice to have it be 
part of the spec
  * Spec originally allowed register to run sync, but need to be consistent
  * Don't want to spawn new jobs and have jobs running in parallel (we want 
to have one job queue)
  * Resolution: update spec language to ensure that all jobs are scheduled 
asynchronously
   * #850: FetchEvent.respondWith does something weird with the body of a 
response
  * Streams need to be figured out (pipeTo algorithm)
  * In the meantime, some steps have been put in place until everything is 
spec'd in Fetch
  * Consuming body input to the API so that scripts can't read after that
  * Comment from Yushino from Google who was working on Streams: pipeTo 
transfers the object via teeing
  * We probably don't want to tee because we want to consume data
  * Outcome: wait and see then change the spec with what is required to 
accommodate changes from Fetch API
   * #848: "Wait for all the tasks queued by Update State" language is 
problematic
   * #851: Install algorithm step 14 should clear waiting worker before 
updating state to redundant
   * #860: spec should queue tasks to expose attribute changes on ServiceWorker 
and ServiceWorkerRegistration
  * Queuing task per execution environment
  * Expectation is that the attributes are in a certain that state
  * There may always be a race between getters
  * Fully deterministic way for getters in this fashion is via event 
listeners
  * Bug in Gecko: registration.installing and activating currently returns 
null
  * Outcome: queue a task to update these values per context, when the 
state changes.
 * 
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#update-state-algorithm
 - this should queue a task to update the serviceWorker.state objects, and the 
registration.waiting (etc) objects.
 * In the updatefound listener, reg.installing should always be the new 
worker, even if there's no install event.
 * In the statechange listener, the registration should be updated.
   * #816: ExtendableMessageEvent.source cannot be SameObject
  * Outcome: update spec reflecting IDL changes
  * Related issue filed in IDL - no update now, will ping
   * #810: MessagePort[] no longer valid in WebIDL
  * Resolution: spec needs to be updated
   * #870: Inconsistencies due to when clients are created
  * When opening a new tab, Chrome (in initial fetch event) there will be a 
client there and in Mozilla there isn't
  * Potential client ID can be used to provide information about what the 
client is if it's not created yet
  * Want to have a rich Fetch event that can include if it was a soft/hard 
reload
  * Once it's in the history and doesn't show up in client lists, the 
document shouldn't exist anymore
  * No client is created for content-disposition downloads
 * This is a reason for just using potential client ID rather than 
re-using the client ID
  * What do you want to do with a client before it's created?
 * Developer may want to cater the content to fill in the client based 
on the window size
  * Do we create a client before the request goes through even if the 
client does not end up being used?
  * Don't update service worker if there is a reload of a page since there 
is no moment when the client is disengaged from being controlled by the service 
worker
  * For window.open, about:blank inherits the creator (i.e., it is 
controlled)
  * We are already committed to having a potential client if we have a 
potential client ID, so we should be able to introspect that client in the 
clients list
  * about:blank is the url of the reserved (potential) client
  * Resolution: have client ID and potential client ID, clients.matchAll 
will not return all cl