[Bug 24557] New: [Shadow]: The definition of focus navigation is misleading.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24557 Bug ID: 24557 Summary: [Shadow]: The definition of focus navigation is misleading. Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: hay...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 The navigation order within a shadow tree must be computed as a list of focusable elements in tree order, and is called shadow tree navigation order. I am afraid that this sentence is likely to be misleading: The navigation order is determined only by element's tree order and the value of *tabindex* is ignored. This is not true. We should make it clear. -- You are receiving this mail because: You are on the CC list for the bug.
[webcomponents] Copying and Pasting a Web Component
Hi, What is expected to happen if a custom element or an element with shadow DOM is copied and pasted from one contenteditable area to another? Are we expected to serialize the composed tree and paste that? We can't keep the shadow DOM structure as there is no serialized form for it, and no script could run when it's pasted. I understand that there is no normative documentation on how copy and paste work to begin with but I'd like to see at least a non-normative note as to what UAs are expected to do since this would surely have a huge compatibility and usability implications down the road. Any thoughts? - R. Niwa
Re: [webcomponents] Copying and Pasting a Web Component
I remember that there was a session to discuss this topic last year's blinkon conference. - https://docs.google.com/a/chromium.org/document/d/1SDBS1BUJHdXQCvcDoXT2-8o6ATYMjEe9PI9U2VmoSlc/edit?pli=1#heading=h.ywom0phsxcmo Session: 'Deep Dive on editing/selection' However, I couldn't find non-normative notes attached there. I guess no one has clear answer for this topic yet unless there is a progress. On Thu, Feb 6, 2014 at 6:57 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, What is expected to happen if a custom element or an element with shadow DOM is copied and pasted from one contenteditable area to another? Are we expected to serialize the composed tree and paste that? We can't keep the shadow DOM structure as there is no serialized form for it, and no script could run when it's pasted. I understand that there is no normative documentation on how copy and paste work to begin with but I'd like to see at least a non-normative note as to what UAs are expected to do since this would surely have a huge compatibility and usability implications down the road. Any thoughts? - R. Niwa -- Hayato
Re: Status of the Shadow DOM Specification
On 2/5/14 12:00 AM, ext Ryosuke Niwa wrote: Hi, Apparently there has been discussions about hats and cats selector combinators in www-style: http://lists.w3.org/Archives/Public/www-style/2014Feb/0032.html In that Tab (Atkins) from Google made a comment saying that Chrome will be shipping Shadow DOM in the very near future: http://lists.w3.org/Archives/Public/www-style/2014Feb/0036.html My understanding is that shadow DOM specification is still being chartered by this very WebApps working group, and unless I’m missing something, the specification was not considered stable enough for any browser vendor to ship without prefixes or behind a flag at least in the last TPAC. In fact, the current working draft has many outstanding issues including issue 6 that says “Hats, ^, and Cats, ^^, selector combinators should be defined in this section.” Also, the latest working draft doesn’t reflect recent discussions on the various mailing lists. For example, section 7.1 Ranges and Selections still mentions that selections are to be entirely within a single root: http://w3c.github.io/webcomponents/spec/shadow/#ranges-and-selection but Jonas (Sicking) from Mozilla has made a pretty strong argument for allowing selection to be extended across shadow boundaries following http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0106.html Am I completely misunderstanding the status of the specification or missing something? Dimitri - would you please respond to this issue? As I mentioned about a month ago [AB], I think it would be helpful to understand the plans, expectations, etc. for all of the Web Components specs. As such, would you please followup on this Dimitri (as you agreed in [DG])? -Thanks, AB [AB] http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0024.html [DG] http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0027.html
[Bug 24564] New: [Imports]: Blocking circular reference in the import tree/list
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24564 Bug ID: 24564 Summary: [Imports]: Blocking circular reference in the import tree/list Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: gkrizsan...@mozilla.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org I'm not sure why exactly were the tree changed to list in the spec., in my mind it's more like a map between uri's and imports, but at very least it should be a set. But one thing this change suggests that we do not necessary disallow circular references among imports. Which I sympathise with, in many cases it's OK to do that. Adding a new edge to the import graph dynamically that results a directed circle after everything was loaded successfully should just work. However. As the spec. stands, if we have a script blocking circular reference we might end up blocking scripts indefinitely. In that case we think (I talked to Boris and Blake about this) we have to break the circle, and this part should be specced out carefully so we don't end up with different behaviours per browser agents. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24565] New: [imports]: Dependency resolution should be stated in clearer way
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24565 Bug ID: 24565 Summary: [imports]: Dependency resolution should be stated in clearer way Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: morr...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 20683 Currently it isn't clear how chained dependency and circular dependency is handled in the system. We need better explanation for that. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [webcomponents] Copying and Pasting a Web Component
Okay, one significant implication of serializing the composed tree is that cutting pasting a component would result in breaking all components within cutting and pasting them in place (i.e. cmd/ctl-x + v at the same location). This would mean that web components are pretty much unusable inside content editable regions unless the author add code to fix up and revive serialized components. But I can't think of a way to work around this issue given we can't tell, at the time of copy/cut, whether the content will be pasted in a document with a give custom element. The most devastating requirement here is that the pasted content can't run any script for security reasons. - R. Niwa On Feb 6, 2014, at 5:03 AM, Hayato Ito hay...@google.com wrote: I remember that there was a session to discuss this topic last year's blinkon conference. - https://docs.google.com/a/chromium.org/document/d/1SDBS1BUJHdXQCvcDoXT2-8o6ATYMjEe9PI9U2VmoSlc/edit?pli=1#heading=h.ywom0phsxcmo Session: 'Deep Dive on editing/selection' However, I couldn't find non-normative notes attached there. I guess no one has clear answer for this topic yet unless there is a progress. On Thu, Feb 6, 2014 at 6:57 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, What is expected to happen if a custom element or an element with shadow DOM is copied and pasted from one contenteditable area to another? Are we expected to serialize the composed tree and paste that? We can't keep the shadow DOM structure as there is no serialized form for it, and no script could run when it's pasted. I understand that there is no normative documentation on how copy and paste work to begin with but I'd like to see at least a non-normative note as to what UAs are expected to do since this would surely have a huge compatibility and usability implications down the road. Any thoughts? - R. Niwa -- Hayato
Re: [webcomponents] Copying and Pasting a Web Component
This seems related to discussion around selection [1]. My claim there was that the selection shouldn't cross shadow boundary, at least from the boundary crossing shouldn't be visible script. If this invariant is kept, we can model copy-pasting in DOM land, without thinking about Shadow DOM nor composed tree because the selection sees only one level of (shadow) subtree. This means copying/pasting does drop Shadow tree. This might look bad from pure Shadow-DOM perspective. But it isn't that bad in practice where Shadow DOM is expected to be used with Custom Elements. Though callbacks, custom element definition rebuilds shadow trees of copied elements. This is similar to what built-in elements like input are doing. This also means that: - Each Custom Element needs to keep serializing states in non-Shadow DOM if it wants to be copy-paste ready. If you build x-menu and and want to make it copy-pasteable, you will have to hold item or something in your (non-shadow) DOM. input is good example. It holds state in @type and @value attributes. - Copying does work only between the document which give appropriate custom element definitions. This might sound bad but actually is reasonable consequence. Custom elements are useless without its definitions anyway. Defining cross-document copying of custom element is too complex to have, at least for initial version of these standards. Even though there are limitations, this allows in-place copying of well-made, shadow-backed custom elements, and it aligns how built-in elements behave (in man browsers I believe). That being said, composed-tree based copying might make sense for inter-document copying and copying into non-browser environments like mailers and note-taking apps. In this case, people won't expect copied elements live and it will be OK to use composed-tree without scripting, that is essentially a frozen snapshot of the elements. I'm not sure if the spec should cover these though. It seems more like optimization that each UA possibly offers. [1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0097.html On Thu, Feb 6, 2014 at 11:34 AM, Ryosuke Niwa rn...@apple.com wrote: Okay, one significant implication of serializing the composed tree is that cutting pasting a component would result in breaking all components within cutting and pasting them in place (i.e. cmd/ctl-x + v at the same location). This would mean that web components are pretty much unusable inside content editable regions unless the author add code to fix up and revive serialized components. But I can't think of a way to work around this issue given we can't tell, at the time of copy/cut, whether the content will be pasted in a document with a give custom element. The most devastating requirement here is that the pasted content can't run any script for security reasons. - R. Niwa On Feb 6, 2014, at 5:03 AM, Hayato Ito hay...@google.com wrote: I remember that there was a session to discuss this topic last year's blinkon conference. - https://docs.google.com/a/chromium.org/document/d/1SDBS1BUJHdXQCvcDoXT2-8o6ATYMjEe9PI9U2VmoSlc/edit?pli=1#heading=h.ywom0phsxcmo Session: 'Deep Dive on editing/selection' However, I couldn't find non-normative notes attached there. I guess no one has clear answer for this topic yet unless there is a progress. On Thu, Feb 6, 2014 at 6:57 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, What is expected to happen if a custom element or an element with shadow DOM is copied and pasted from one contenteditable area to another? Are we expected to serialize the composed tree and paste that? We can't keep the shadow DOM structure as there is no serialized form for it, and no script could run when it's pasted. I understand that there is no normative documentation on how copy and paste work to begin with but I'd like to see at least a non-normative note as to what UAs are expected to do since this would surely have a huge compatibility and usability implications down the road. Any thoughts? - R. Niwa -- Hayato -- morrita
[Bug 24570] New: [Custom]: Callback for cloneNode/importNode
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24570
Bug ID: 24570
Summary: [Custom]: Callback for cloneNode/importNode
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Component Model
Assignee: dglaz...@chromium.org
Reporter: a...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14968
Built in elements like inputs have hooks for cloning data that is not
represented as children or attributes.
Strawman:
Add a cloneNodeCallback, which gets called after the element has been called,
with a the original element as the context object and the new node as the only
argument.
Then HTMLInputElement could be implemented as:
document.registerElemetn('input', {
prototype: {
__proto__: HTMLElement.prototype,
cloneNodeCallback: function(newNode) {
newNode.value = this.value;
}
}
});
--
You are receiving this mail because:
You are on the CC list for the bug.
Re: [webcomponents] Copying and Pasting a Web Component
All good points. One issue that we should track... On Thu, Feb 6, 2014 at 5:20 PM, Hajime Morrita morr...@google.com wrote: This seems related to discussion around selection [1]. My claim there was that the selection shouldn't cross shadow boundary, at least from the boundary crossing shouldn't be visible script. If this invariant is kept, we can model copy-pasting in DOM land, without thinking about Shadow DOM nor composed tree because the selection sees only one level of (shadow) subtree. This means copying/pasting does drop Shadow tree. This might look bad from pure Shadow-DOM perspective. But it isn't that bad in practice where Shadow DOM is expected to be used with Custom Elements. Though callbacks, custom element definition rebuilds shadow trees of copied elements. This is similar to what built-in elements like input are doing. This also means that: - Each Custom Element needs to keep serializing states in non-Shadow DOM if it wants to be copy-paste ready. If you build x-menu and and want to make it copy-pasteable, you will have to hold item or something in your (non-shadow) DOM. input is good example. It holds state in @type and @value attributes. input is actually bad because the value attribute maps to the defaultValue property. The value property is not reflected as an attribute. We should add a hook to custom elements to handle cloning of internal data. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24570 - Copying does work only between the document which give appropriate custom element definitions. This might sound bad but actually is reasonable consequence. Custom elements are useless without its definitions anyway. Defining cross-document copying of custom element is too complex to have, at least for initial version of these standards. Even though there are limitations, this allows in-place copying of well-made, shadow-backed custom elements, and it aligns how built-in elements behave (in man browsers I believe). That being said, composed-tree based copying might make sense for inter-document copying and copying into non-browser environments like mailers and note-taking apps. In this case, people won't expect copied elements live and it will be OK to use composed-tree without scripting, that is essentially a frozen snapshot of the elements. I'm not sure if the spec should cover these though. It seems more like optimization that each UA possibly offers. [1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0097.html On Thu, Feb 6, 2014 at 11:34 AM, Ryosuke Niwa rn...@apple.com wrote: Okay, one significant implication of serializing the composed tree is that cutting pasting a component would result in breaking all components within cutting and pasting them in place (i.e. cmd/ctl-x + v at the same location). This would mean that web components are pretty much unusable inside content editable regions unless the author add code to fix up and revive serialized components. But I can't think of a way to work around this issue given we can't tell, at the time of copy/cut, whether the content will be pasted in a document with a give custom element. The most devastating requirement here is that the pasted content can't run any script for security reasons. - R. Niwa On Feb 6, 2014, at 5:03 AM, Hayato Ito hay...@google.com wrote: I remember that there was a session to discuss this topic last year's blinkon conference. - https://docs.google.com/a/chromium.org/document/d/1SDBS1BUJHdXQCvcDoXT2-8o6ATYMjEe9PI9U2VmoSlc/edit?pli=1#heading=h.ywom0phsxcmo Session: 'Deep Dive on editing/selection' However, I couldn't find non-normative notes attached there. I guess no one has clear answer for this topic yet unless there is a progress. On Thu, Feb 6, 2014 at 6:57 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, What is expected to happen if a custom element or an element with shadow DOM is copied and pasted from one contenteditable area to another? Are we expected to serialize the composed tree and paste that? We can't keep the shadow DOM structure as there is no serialized form for it, and no script could run when it's pasted. I understand that there is no normative documentation on how copy and paste work to begin with but I'd like to see at least a non-normative note as to what UAs are expected to do since this would surely have a huge compatibility and usability implications down the road. Any thoughts? - R. Niwa -- Hayato -- morrita -- erik
Re: [webcomponents] Copying and Pasting a Web Component
On Thu, Feb 6, 2014 at 2:54 PM, Erik Arvidsson a...@google.com wrote: All good points. One issue that we should track... On Thu, Feb 6, 2014 at 5:20 PM, Hajime Morrita morr...@google.com wrote: This seems related to discussion around selection [1]. My claim there was that the selection shouldn't cross shadow boundary, at least from the boundary crossing shouldn't be visible script. If this invariant is kept, we can model copy-pasting in DOM land, without thinking about Shadow DOM nor composed tree because the selection sees only one level of (shadow) subtree. This means copying/pasting does drop Shadow tree. This might look bad from pure Shadow-DOM perspective. But it isn't that bad in practice where Shadow DOM is expected to be used with Custom Elements. Though callbacks, custom element definition rebuilds shadow trees of copied elements. This is similar to what built-in elements like input are doing. This also means that: - Each Custom Element needs to keep serializing states in non-Shadow DOM if it wants to be copy-paste ready. If you build x-menu and and want to make it copy-pasteable, you will have to hold item or something in your (non-shadow) DOM. input is good example. It holds state in @type and @value attributes. input is actually bad because the value attribute maps to the defaultValue property. The value property is not reflected as an attribute. We should add a hook to custom elements to handle cloning of internal data. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24570 I think is isn't about cloning but about serialization. Copying HTML into clipboard means it needs to be serialized into byte stream and be read back as another tree. Well, such hooks could be used to ensure the sate being serialized into DOM. It'd be great if the hook supports serialization scenario as well. - Copying does work only between the document which give appropriate custom element definitions. This might sound bad but actually is reasonable consequence. Custom elements are useless without its definitions anyway. Defining cross-document copying of custom element is too complex to have, at least for initial version of these standards. Even though there are limitations, this allows in-place copying of well-made, shadow-backed custom elements, and it aligns how built-in elements behave (in man browsers I believe). That being said, composed-tree based copying might make sense for inter-document copying and copying into non-browser environments like mailers and note-taking apps. In this case, people won't expect copied elements live and it will be OK to use composed-tree without scripting, that is essentially a frozen snapshot of the elements. I'm not sure if the spec should cover these though. It seems more like optimization that each UA possibly offers. [1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0097.html On Thu, Feb 6, 2014 at 11:34 AM, Ryosuke Niwa rn...@apple.com wrote: Okay, one significant implication of serializing the composed tree is that cutting pasting a component would result in breaking all components within cutting and pasting them in place (i.e. cmd/ctl-x + v at the same location). This would mean that web components are pretty much unusable inside content editable regions unless the author add code to fix up and revive serialized components. But I can't think of a way to work around this issue given we can't tell, at the time of copy/cut, whether the content will be pasted in a document with a give custom element. The most devastating requirement here is that the pasted content can't run any script for security reasons. - R. Niwa On Feb 6, 2014, at 5:03 AM, Hayato Ito hay...@google.com wrote: I remember that there was a session to discuss this topic last year's blinkon conference. - https://docs.google.com/a/chromium.org/document/d/1SDBS1BUJHdXQCvcDoXT2-8o6ATYMjEe9PI9U2VmoSlc/edit?pli=1#heading=h.ywom0phsxcmo Session: 'Deep Dive on editing/selection' However, I couldn't find non-normative notes attached there. I guess no one has clear answer for this topic yet unless there is a progress. On Thu, Feb 6, 2014 at 6:57 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, What is expected to happen if a custom element or an element with shadow DOM is copied and pasted from one contenteditable area to another? Are we expected to serialize the composed tree and paste that? We can't keep the shadow DOM structure as there is no serialized form for it, and no script could run when it's pasted. I understand that there is no normative documentation on how copy and paste work to begin with but I'd like to see at least a non-normative note as to what UAs are expected to do since this would surely have a huge compatibility and usability implications down the road. Any thoughts?
Re: [webcomponents] Copying and Pasting a Web Component
On Feb 6, 2014, at 3:56 PM, Hajime Morrita morr...@google.com wrote: On Thu, Feb 6, 2014 at 2:54 PM, Erik Arvidsson a...@google.com wrote: All good points. One issue that we should track... On Thu, Feb 6, 2014 at 5:20 PM, Hajime Morrita morr...@google.com wrote: This seems related to discussion around selection [1]. My claim there was that the selection shouldn't cross shadow boundary, at least from the boundary crossing shouldn't be visible script. If this invariant is kept, we can model copy-pasting in DOM land, without thinking about Shadow DOM nor composed tree because the selection sees only one level of (shadow) subtree. This means copying/pasting does drop Shadow tree. This might look bad from pure Shadow-DOM perspective. But it isn't that bad in practice where Shadow DOM is expected to be used with Custom Elements. Though callbacks, custom element definition rebuilds shadow trees of copied elements. This is similar to what built-in elements like input are doing. This also means that: - Each Custom Element needs to keep serializing states in non-Shadow DOM if it wants to be copy-paste ready. If you build x-menu and and want to make it copy-pasteable, you will have to hold item or something in your (non-shadow) DOM. input is good example. It holds state in @type and @value attributes. input is actually bad because the value attribute maps to the defaultValue property. The value property is not reflected as an attribute. We should add a hook to custom elements to handle cloning of internal data. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24570 I think is isn't about cloning but about serialization. Copying HTML into clipboard means it needs to be serialized into byte stream and be read back as another tree. Well, such hooks could be used to ensure the sate being serialized into DOM. It'd be great if the hook supports serialization scenario as well. Right. Hooks for custom elements, however, are somewhat irrelevant here if we're allowing shadow DOM outside of custom elements. I'm not really keen on the idea to let custom elements define its copy paste behavior in that we don't have different copy/paste behaviors among different builtin HTML elements we have. - R. Niwa
Update on Streams API Status
Hi All, I wanted to update everyone on the latest plan for moving forward on the Streams spec. For a variety of reasons, there are currently two Streams Specs being worked on - one in the W3C, and one in the WHATWG. Each of these specs have their strengths and weaknesses, and were looking at problems from different perspectives. After meeting with the WHATWG folks and discussing the various scenarios being targeted by the Streams specs as well as other considerations, we all agreed that we have the same goals and should work together to get alignment and avoid having different implementations. This is an opportunity to get a strong consistent API which behaves similarly across the various platforms, from browsers to servers. We are excited with the potential here, because it lets us tell one story. Moving forward, we've agreed to revise the approach to working on the Streams spec as follows: Create a 'base' Stream spec, which we will work together on. This will be seeded with the base of the WHATWG spec, and we will incorporate various pieces from either spec as needed. This base Stream should: 1. Be the lowest primitive that is independent of any platform 2. Be a layer that could make it into the JS language/ES 3. Could be prototyped in JavaScript directly to showcase it 4. Supports the various Stream goals we discussed, such as creation, backpressure, read/write behaviors, etc. In addition to the base Stream spec, the remaining platform-specific pieces which do not fit into the shared-base spec will live in an independent spec. This includes things such as support in other APIs (XHR, MediaStreaming, etc) or DOM specific scenarios - (createObjectURL()). The current W3C Streams API will focus on this aspect of the API surface, while leaving the core functionality to be defined in the base spec. Once we've reorganized the components as defined above, we will share out further details for locations of the specs as well as solicit review. Thanks, Feras
[webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)
Hi, Could chairs of the working group please clarify whether we have had a reach of consensus on the default encapsulation level in shadow DOM? More concretely, have we _decided_ that we only want Type 1 encapsulation for the level 1 specifications of Web components instead of Type 2 or Type 1 and Type 2 encapsulations as defined in Maciej's email sent out in June 29th, 2011: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html I don't recall any consensus being reached about this matter. In fact, http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312 (referred by http://lists.w3.org/Archives/Public/www-style/2014Feb/0221.html) clearly shows the lack of consensus in my eyes as both Boris Zbarsky from Mozilla and Maciej Stachowiak from Apple have voiced to prefer Type 2 encapsulation: http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0406.html http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0421.html http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0628.html while representatives of Google preferring Type 1 encapsulations. - R. Niwa
Re: [webcomponents] Decoupling Custom Elements and Shadow DOM (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 8, 2013, at 5:21 PM, Dominic Cooney domin...@google.com wrote: On Fri, Dec 6, 2013 at 12:49 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 7:32 PM, Scott Miles sjmi...@google.com wrote: We don't think decoupling custom elements and shadow DOM completely is useful given that most important and natural use cases of custom elements involve the use of shadow DOM. Separating concerns is always useful, especially when it involves contentious standards. I also would like to point out that Mozilla's X-Tags/Brick custom elements library is built entirely without Shadow DOM. Could you elaborate on what value does document.register add in that world? Web developers could use mutation observers to manipulate elements of a given name and add a bunch of properties already. Custom Elements adds a lot of value over Mutation Observers. Mutation Observers are great, but for other things. A couple of the benefits are: Instances get callbacks/the right prototype more eagerly than they do with Mutation Observers. If element authors follow local discipline, they end up with a composition of elements that is consistent. This makes it easier to create more robust applications. Technically, more eager callbacks (more eager than typical uses of Mutation Observers, but less eager than Custom Elements) are possible with Mutation Observers through takeRecords. However it turns out this is infeasible because developers end up cargo-culting takeRecords. (It doesn't work? Add a call to the thing that flushes changes with takeRecords! Something else broke? ...) That seems like a problem/limitation with mutation observers that we should fix regardless of custom elements. It is easier to get consistent availability of the element than it is with Mutation Observers. For example, Custom Elements are upgraded even if the element instance is not in the document. With Mutation Observers this is extremely difficult because it requires registering observers as subtrees are disconnected... and modifications including disconnections may have happened in the interim. With Custom Elements, the responsibility of understanding how operations affect elements lies with the UA, which has comprehensive knowledge of this now and into the future, and not with the author. On the other hand, this is a good point. Thanks for the clarification. If we should probably include it in http://w3c.github.io/webcomponents/spec/custom/#motivations - R. Niwa
Re: [webcomponents] Binding Custom Element without Polluting Global Scope (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Dec 7, 2013, at 3:25 PM, Dominic Cooney domin...@google.com wrote:
On Sat, Dec 7, 2013 at 10:06 AM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 6, 2013, at 5:01 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 6, 2013, at 1:20 AM, Brian Di Palma off...@gmail.com wrote:
On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
1) It is not friendly to ES6 classes. In fact, you can't use class syntax
and this syntax together.
Okay, let the author define the constructor.
3) The approach pollutes global name space with constructors. This had been
voiced many times as unacceptable by developers.
We can solve this problem by using JavaScript object path as opposed to a
variable name.
So instead of:
template register=my-button interface=MyButton
/template
We allow:
script
var my = {views:{MyButton: ~}};
/script
template register=my-button interface=my.views.MyButton
/template
While this requires some variable to be exposed on the global scope,
libraries and frameworks do this already,
Hopefully though they won't do that any longer in the ES6 module world.
They had to be exposed on the global scope in some way otherwise they
couldn't be used, in future that will no longer be the case.
Are you proposing to provide some mechanism to declaratively define a custom
element inside a module?
How does a ES6 module end up having markup?
I'll also point out that with our proposal to add an optional template
argument, we could do:
template id=myButton
...
/template
script
(function () {
class MyButton extends HTMLElement {
...
}
document.register('my-button', MyButton,
document.getElementById('myButton'));
)();
/script
so authors DO have an option to hide the class entirely from the global
scope. It's just not declarative.
I don't think this proposal is an improvement over the document.register in
the spec today.
It is an improvement in that it reduces the boilerplate code that we expect
many custom elements to have.
The existing spec for document.register does not add a binding to the
JavaScript scope. So it does not suffer the problem discussed in this thread.
Sorry, I don't really understand what you mean by this. Could you clarify?
Given that we don't want to change this or the global object per previous
discussion in the working group,
I don't know what discussion you are specifically referring to so my next
statement is not agreeing or disagreeing with the preceding clause of this
sentence.
See Erik's inline comment in
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0122.html
Unfortunately NodeJS broke this invariant already. `this` inside a module that
has been required is a not the [[Global]] object. This has caused me a lot of
personal porting pain so I agree we must not break this invariant on the web.
I don't see how we can refer to a JS class/constructor declaratively.
Yes. I can't think of an example where DOM attributes do this. onclick, etc.
handlers relate to script, but they do not refer to specific objects.
This is a problem with your proposal.
I don't think this is an issue with our proposal. I don't think any proposal
for declarative syntax can simultaneously satisfy requirements to not change
the meaning of this inside the element definition and not pollute the global
namespace at all.
I think a proposal for declarative Custom Elements must also deal with the
problems the group discovered when it last tried. They are summarized here:
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0287.html
A lot of problems listed there appears to stem from an implicit assumption that
the declarative syntax should have the same expressiveness as imperative API.
I disagree with that proposition. Any moderately complicated Web apps will
inevitably involve scripts. The existing Web APIs are designed around this
principle; they address common use cases with declarative syntax and provide
imperative APIs for more complicated use cases.
- R. Niwa
Re: [webcomponents] Async Registration of Custom Elements
I'll also note that none of builtin HTML elements have resolved state. If the goal of custom elements is: Rationalize the platform. The specification ensures that all of its new features and abilities are in concert with how the relevant bits of the Web platform work today, so that these new features could be used to explain the functionality of existing Web platform features, such as HTML elements. as currently stated in the latest WG and ED, then we should not be adding new magical state to the platform. - R. Niwa On Jan 30, 2014, at 3:03 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, Could someone clarify why we want to allow out-of-order registration of custom elements? Can we also have (a pointer to) concrete use cases for this feature? The thing is if an author wants to replace or customize a placeholder element using a script that loads later, that’s pretty easy to achieve in the script itself: // Placeholder elements already exist in the document. document.registerElement(…); // This line of code is present no matter what. // Four more lines of code finish the job. var placeholders = document.querySelectorAll(…); for (var placeholder of placeholders) placeholder.parentNode.replaceChild(…); techcrunch.com does this for all of its like buttons, for example — although they do the replacement on hover, and not on load. There’s very little upside to building replacement behavior into the browser engine when it’s so easy to achieve in script — and the script had to run anyway in order to document.registerElement(). In fact, it may be actively harmful in preventing developers from implementing potentially desirable patterns (e.g. Techcrunch’s on demand replacement, which may be advantageous if the components are expensive). Furthermore, synchronous loading of all scripts that define custom elements is not required to unblock the browser's main thread from keep parsing and processing the other page contents. What is required is that scripts that want to load asynchronously and define custom elements that replace placeholder elements in the document must also define the replacement behavior — Should I make a new element and remove the placeholder element? Should I make a new element that’s a child of the placeholder element? Should I move some of the contents of the placeholder element into the new element? Should the placeholder element remain in the DOM somewhere? What happens to event listeners and custom properties added to the placeholder element? Styles? etc... Building a one-size-fits-all solution to these questions into the browser appears to be the root cause of many complexities in the current specification like nodes that automatically become other nodes and JavaScript wrappers that get “nulled out” — whatever that means. It’s fundamentally weird to replace one node with another node and yet try to pretend that no invariants of the first node have been violated. It seems much saner to require the author to actually replace the old node with a new node, or perform some other well-known DOM manipulation instead. (Credit: Geoffrey Garen Gavin Barraclough). - R. Niwa
