Re: [webcomponents]: Allowing text children of ShadowRoot is a bad time

2013-10-09 Thread Hayato Ito
Good points. All you pointed out make sense to me. But I am wondering what we should do for these issues: A). Discourage developers to use direct text children of ShadowRoot. B). Disallow direct text children of ShadowRoot in the Shadow DOM spec. C). Find a nice way to style direct text children

Re: Shadow DOM and Fallback contents for images

2013-10-17 Thread Hayato Ito
I am aware that there are issues related to selections regarding Shadow DOM both in the spec and the implementation. But I don't have a clear answer to resolve that and couldn't satisfy users. This is one of the toughest issues, I think. Some of us have already started to tackle this issue. We

[webcomponents] The latest editor's drafts of the Web Components specifications are now hosted on github.

2013-11-10 Thread Hayato Ito
Hi all, Let me announce that the latest editor's drafts of the Web Components specifications are now hosted on github under W3C organization. The location of the repository is: http://github.com/w3c/webcomponents/ -- Hayato

Re: Controling style of elements in Injection Points

2013-11-28 Thread Hayato Ito
We can use '::content' pseudo elements if we want to apply styles to distributed nodes from a shadow tree. See http://w3c.github.io/webcomponents/spec/shadow/#content-pseudo-element On Thu, Nov 28, 2013 at 9:14 AM, Enrique Moreno Tent enriquemorenot...@gmail.com wrote: Hello, I have been

Re: Controling style of elements in Injection Points

2013-11-28 Thread Hayato Ito
Yeah, Chrome has already implemented that. I've implemented that. :) On Thu, Nov 28, 2013 at 6:25 PM, Enrique Moreno Tent enriquemorenot...@gmail.com wrote: Oh, interesting! Has this been implemented in any browser? On 28 November 2013 08:46, Hayato Ito hay...@google.com wrote: We can

Re: [webcomponents] Copying and Pasting a Web Component

2014-02-06 Thread Hayato Ito
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

Re: [Shadow DOM] Separating Transclusion Mechanisms for Inheritance and Data Binding

2014-04-21 Thread Hayato Ito
Thank you for the proposal. Sounds like the first part of the proposal is based on the feature which was reverted in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24288. In the current spec, the child elements in shadow are simply *ignored*. Therefore, I'm afraid that a shadow tree for

Re: publish new WD of Shadow DOM on June 12

2014-06-09 Thread Hayato Ito
Sounds good to me. That's much better. Thank you for catching that. On Sun, Jun 8, 2014 at 4:38 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Jun 6, 2014 at 3:14 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Arthur Barstow [mailto:art.bars...@gmail.com] Could

Re: Web Components: two questions

2014-09-10 Thread Hayato Ito
On Wed Sep 10 2014 at 8:26:43 PM Ondřej Žára ondrej.z...@firma.seznam.cz wrote: Hi, unable to seek a qualified answer via IRC or Web/spec, I decided to post my two beginner questions here. 1) Are form elements (input, select, textarea) inside a shadow dom considered when submitting a form?

Re: Web Components: two questions

2014-09-11 Thread Hayato Ito
On Thu Sep 11 2014 at 3:25:01 PM Ondřej Žára ondrej.z...@firma.seznam.cz wrote: 1) Are form elements (input, select, textarea) inside a shadow dom considered when submitting a form? The Shadow DOM spec doesn't say anything about this. Therefore, form elements should be in the

Re: Web Components: two questions

2014-09-11 Thread Hayato Ito
On Thu Sep 11 2014 at 4:04:27 PM Hayato Ito hay...@chromium.org wrote: On Thu Sep 11 2014 at 3:25:01 PM Ondřej Žára ondrej.z...@firma.seznam.cz wrote: 1) Are form elements (input, select, textarea) inside a shadow dom considered when submitting a form? The Shadow DOM spec

[shadow-dom] [Re: [WebComponents] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]]

2014-10-23 Thread Hayato Ito
Hi Arthur and WebAppsWG, Status of Shadow DOM: Update since the last TPAC: - The new WD [1] was published. I plan to address the followings in the next six months: - Update the event path calculation algorithm [2] - Resolve 'In Document' issues [3] - Bring back 'shadow as function' to the spec

Re: Shadow tree style isolation primitive

2015-01-12 Thread Hayato Ito
Intent to remove style scoped in blink-dev is here: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/R1x18ZLS5qQ On Tue Jan 13 2015 at 1:26:52 PM Marc Fawzi marc.fa...@gmail.com wrote: Can someone shed light at why Scoped Style Element was removed from Chrome experimental

Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

2015-03-26 Thread Hayato Ito
getElement* functions have been removed, [1], [2], from the ShadowRoot. [1]: https://github.com/w3c/webcomponents/commit/3d5f147812edaf74cc4f07d294836cafdf48534f [2]: https://github.com/w3c/webcomponents/commit/6416fdfe7fc87e47aa89aac8ce5430389b9ad653 See also the relevant discussions: -

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Hayato Ito
Thank you, guys. I really appreciate if you guys could use the W3C bug, 18429, to discuss this kind of specific topic about Shadow DOM so that we can track the progress easily in one place. I'm not fan of the discussion being scattered. :) https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429 On

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Hayato Ito
there later. - R. Niwa On Apr 25, 2015, at 10:00 AM, Hayato Ito hay...@chromium.org wrote: Thank you, guys. I really appreciate if you guys could use the W3C bug, 18429, to discuss this kind of specific topic about Shadow DOM so that we can track the progress easily in one place. I'm

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-26 Thread Hayato Ito
I think Polymer folks will answer the use case of re-distribution. So let me just show a good analogy so that every one can understand intuitively what re-distribution *means*. Let me use a pseudo language and define XComponent's constructor as follows: XComponents::XComponents(Title text, Icon

Re: :host pseudo-class

2015-04-26 Thread Hayato Ito
I think using ::host pseudo element can avoid this kind of *controversial* discussion and we can get benefits from that. +1 for ::host pseudo element. On Sun, Apr 26, 2015 at 4:02 AM Daniel Tan li...@novalistic.com wrote: On 4/26/2015 12:32 AM, Anne van Kesteren wrote: I don't understand why

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Hayato Ito
For the comparison, I've re-written the examples by using shadow as function syntax. https://gist.github.com/hayatoito/f2df8e10cb8cc551f80c Can I assume that both have the same power, fundamentally? (Please ignore that power of the CSS selector here ;) If both approaches have the (almost)

Re: Inheritance Model for Shadow DOM Revisited

2015-04-30 Thread Hayato Ito
such a multiple templates, but also from everywhere? On Thu, Apr 30, 2015 at 4:18 PM Ryosuke Niwa rn...@apple.com wrote: On Apr 29, 2015, at 9:17 PM, Hayato Ito hay...@chromium.org wrote: Thanks. As far as my understanding is correct, the conclusions so far are: - There is no use cases which

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-30 Thread Hayato Ito
On Thu, Apr 30, 2015 at 9:54 PM Anne van Kesteren ann...@annevk.nl wrote: On Thu, Apr 30, 2015 at 2:44 PM, Domenic Denicola d...@domenic.me wrote: From: Anne van Kesteren ann...@annevk.nl var x = new Event(eventType) someNodeThatIsDistributed.addEventListener(eventType, e =

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-27 Thread Hayato Ito
On Tue, Apr 28, 2015 at 6:18 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 26, 2015, at 6:11 PM, Hayato Ito hay...@chromium.org wrote: I think Polymer folks will answer the use case of re-distribution. So let me just show a good analogy so that every one can understand intuitively

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-27 Thread Hayato Ito
I think there are a lot of user operations where distribution must be updated before returning the meaningful result synchronously. Unless distribution result is correctly updated, users would take the dirty result. For example: - element.offsetWidth: Style resolution requires distribution. We

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-27 Thread Hayato Ito
, Apr 28, 2015 at 6:58 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 2:38 PM, Hayato Ito hay...@chromium.org wrote: On Tue, Apr 28, 2015 at 6:18 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 26, 2015, at 6:11 PM, Hayato Ito hay...@chromium.org wrote: I think Polymer folks

Re: Inheritance Model for Shadow DOM Revisited

2015-04-27 Thread Hayato Ito
consensus is to defer this until v2. On Apr 27, 2015, at 9:09 PM, Hayato Ito hay...@chromium.org wrote: For the record, I, as a spec editor, still think Shadow Root hosts yet another Shadow Root is the best idea among all ideas I've ever seen, with a shadow as function, because it can explain

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-27 Thread Hayato Ito
For the record, I, as a spec editor, still think Shadow Root hosts yet another Shadow Root is the best idea among all ideas I've ever seen, with a shadow as function, because it can explain everything in a unified way using a single tree of trees, without bringing yet another complexity such as

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-30 Thread Hayato Ito
On Fri, May 1, 2015 at 2:59 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 6:00 AM, Domenic Denicola d...@domenic.me wrote: This essentially forces distribution to happen since you can observe the result of distribution this way. Same with element.offsetWidth etc. And that's

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-30 Thread Hayato Ito
Thanks, however, we're talking about https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0442.html. On Fri, May 1, 2015 at 12:57 PM Ryosuke Niwa rn...@apple.com wrote: On Apr 30, 2015, at 8:17 PM, Hayato Ito hay...@chromium.org wrote: On Fri, May 1, 2015 at 2:59 AM Ryosuke Niwa rn

Re: Inheritance Model for Shadow DOM Revisited

2015-04-28 Thread Hayato Ito
an concrete example which content slot can support, but shadow as function can't support? On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 9:50 PM, Hayato Ito hay...@chromium.org wrote: The feature of shadow as function supports *subclassing*. That's exactly

Re: Inheritance Model for Shadow DOM Revisited

2015-04-29 Thread Hayato Ito
at 3:52 AM Ryosuke Niwa rn...@apple.com wrote: On Wed, Apr 29, 2015 at 2:09 AM Ryosuke Niwa rn...@apple.com wrote: On Apr 27, 2015, at 9:50 PM, Hayato Ito hay...@chromium.org wrote: The feature of shadow as function supports *subclassing*. That's exactly the motivation I've introduced

Re: Inheritance Model for Shadow DOM Revisited

2015-04-30 Thread Hayato Ito
Filed as https://www.w3.org/Bugs/Public/show_bug.cgi?id=28587. On Fri, May 1, 2015 at 1:16 AM Hayato Ito hay...@chromium.org wrote: Thanks Anne, I agree that it would be great to have something like this. I think it's too early for us to judge something because we don't have a well defined

Re: Shadow DOM: state of the distribution API

2015-05-07 Thread Hayato Ito
I'm happy to implement some of these proposals in blink to compare the performance when the time comes, if I or other guys can afford to do. On Thu, May 7, 2015 at 1:20 PM Hayato Ito hay...@chromium.org wrote: I'm wondering how we should estimate the performance impact of these proposals

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-07 Thread Hayato Ito
: On Wed, May 6, 2015 at 11:08 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 7, 2015 at 6:02 AM, Hayato Ito hay...@chromium.org wrote: I'm saying: - Composed tree is related with CSS. - Node distribution should be considered as a part of style concept. Right, I think

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-06 Thread Hayato Ito
I'm not saying the event path is not related to a composed tree. I'm saying: - Composed tree is related with CSS. - Node distribution should be considered as a part of style concept. On Thu, May 7, 2015 at 12:54 PM Ryosuke Niwa rn...@apple.com wrote: On May 6, 2015, at 6:18 PM, Hayato Ito

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-06 Thread Hayato Ito
On Wed, May 6, 2015 at 10:22 AM Ryosuke Niwa rn...@apple.com wrote: On May 5, 2015, at 11:55 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa rn...@apple.com wrote: On May 4, 2015, at 10:20 PM, Anne van Kesteren ann...@annevk.nl wrote: On

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-06 Thread Hayato Ito
Tree doesn't have any affect on (most of) existing APIs. - Composed Tree is used in resolving CSS inheritance. That's all, except for a few exception. On Thu, May 7, 2015 at 10:18 AM Hayato Ito hay...@chromium.org wrote: On Wed, May 6, 2015 at 10:22 AM Ryosuke Niwa rn...@apple.com wrote

Re: Shadow DOM: state of the distribution API

2015-05-06 Thread Hayato Ito
I'm wondering how we should estimate the performance impact of these proposals. In the era of Web Components, I expect that one page has 1k Web Components. The page must work without any significant noticeable performance regression, compared to a page which doesn't use Web Components. That's our

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-05-07 Thread Hayato Ito
: On Wed, May 6, 2015 at 11:08 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, May 7, 2015 at 6:02 AM, Hayato Ito hay...@chromium.org wrote: I'm saying: - Composed tree is related with CSS. - Node distribution should be considered as a part of style concept. Right, I think Ryosuke

Re: Shadow DOM: state of the distribution API

2015-05-17 Thread Hayato Ito
On Sat, May 16, 2015 at 12:41 AM Olli Pettay o...@pettay.fi wrote: On 05/15/2015 06:39 PM, Wilson Page wrote: Wouldn't it likely need to be called just before layout? Probably yes, but it is not defined when that actually happens. Yeah, the exact timing is not defined. That's intentional.

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Hayato Ito
On Tue, May 19, 2015 at 12:06 PM Dimitri Glazkov dglaz...@google.com wrote: On Mon, May 18, 2015 at 6:48 PM, Hayato Ito hay...@chromium.org wrote: My preference in v1: 1. select (strongly preferred). okay to rename it if we have a better name. e.g. content select=xxx == slot select=xxx 2

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Hayato Ito
-engineering for us. But this might be interesting to us as a reference. On Tue, May 19, 2015 at 12:54 PM Hayato Ito hay...@chromium.org wrote: I think the problem we have to solve is: Problem: Given that we have a list of nodes, what's the best way to select nodes from the list? We can give any

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Hayato Ito
. On Tue, May 19, 2015 at 12:23 PM Dimitri Glazkov dglaz...@google.com wrote: On Mon, May 18, 2015 at 8:18 PM, Hayato Ito hay...@chromium.org wrote: Thank you! I'm afraid that we don't have enough discussion about the pros and cons between select nodes using a selector and select nodes

Re: [webcomponents] How about let's go with slots?

2015-05-18 Thread Hayato Ito
My preference in v1: 1. select (strongly preferred). okay to rename it if we have a better name. e.g. content select=xxx == slot select=xxx 2. select + content-slot 3. content-slot I was assuming that content-slot is one of required parts in the Multiple Templates proposal and Imperative APIs.

Re: Mozilla and the Shadow DOM

2015-04-08 Thread Hayato Ito
Anne, Thank you for sharing. I'm feeling that we might want to divide each feature provided by ShadowDOM into more fine-grained opt-in/opt-out features, if developers want it. At the same time, however, I still have a concern, Do developers really need such a fine-grained control? Is it too early

Custom Elements bugs will be also migrated. [Was: Re: Shadow DOM spec bugs will be migrated into GitHub issues]

2015-06-25 Thread Hayato Ito
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

Re: Shadow DOM spec bugs will be migrated into GitHub issues

2015-05-26 Thread Hayato Ito
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 wrote: Regarding with the Shadow DOM spec, more and more workflows are happening [1] on GitHub w3c/webcomponents

Re: Shadow DOM spec bugs will be migrated into GitHub issues

2015-05-27 Thread Hayato Ito
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 wrote: PSA: I've finished

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

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

2015-07-06 Thread Hayato Ito
, 2015 at 4:24 PM Xiaoqian Wu xiaoq...@w3.org wrote: On 1 Jul, 2015, at 1:30 pm, Hayato Ito hay...@google.com wrote: Thank you. I appreciate that. Then, let me migrate all open bugs of 'Component Model'. I think that include also HTML Imports bugs in addition to Custom Elements bugs. When I

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

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

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

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

Shadow DOM spec bugs will be migrated into GitHub issues

2015-05-25 Thread Hayato Ito
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

Re: Custom Element Action Items?

2015-08-10 Thread Hayato Ito
As for Custom Elements, I think the following is one of the Action Items: https://github.com/w3c/webcomponents/issues/287 Could someone add a missing action item to GitHub Issues if it exists? As for the Shadow DOM spec, I'm updating the spec so that it adapts the Slots and other changes which

Re: CSS cascading order and Shadow DOM

2015-08-04 Thread Hayato Ito
Thanks. I merged the pull request, https://github.com/w3c/webcomponents/pull/292. Now the proposal is at https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order.md On Tue, Aug 4, 2015 at 11:41 PM Rune Lillesveen r...@opera.com wrote: Hi, I proposed some changes

Re: [web components] proposed meetings: 15 dec / 29 jan

2015-11-15 Thread Hayato Ito
pple.com> wrote: > > > On Nov 13, 2015, at 8:08 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > > > > On Fri, Nov 13, 2015 at 4:57 PM, Ryosuke Niwa <rn...@apple.com> wrote: > >> What outstanding problems are you thinking of? > > > &g

Re: [Web Components] proposing a f2f...

2015-11-01 Thread Hayato Ito
> 1. Clarify focus navigation > 2. Clarify selection behavior (at least make it interoperable to JS) > 3. Decide on the style cascading order > 4. style inheritance (https://github.com/w3c/webcomponents/issues/314) I'm happy to have the mentioned topics about Shadow DOM on the f2f if and only if:

Re: Shadow DOM spec for v1 is ready to be reviewed

2015-09-01 Thread Hayato Ito
AM Ryosuke Niwa <rn...@apple.com> wrote: > Thanks for the update! > > On Aug 27, 2015, at 11:33 PM, Hayato Ito <hay...@google.com> wrote: > > Let me post a quick update for the Shadow DOM spec: > https://w3c.github.io/webcomponents/spec/shadow/ > <ht

Re: Shadow DOM spec for v1 is ready to be reviewed

2015-09-07 Thread Hayato Ito
On Sun, Sep 6, 2015 at 12:53 AM Anne van Kesteren <ann...@annevk.nl> wrote: > On Fri, Aug 28, 2015 at 8:33 AM, Hayato Ito <hay...@google.com> wrote: > > - Some of the remaining issues are difficult to address in the Shadow DOM > > spec because it requires non-trivia

Re: Telecon / meeting on first week of April for Web Components

2016-03-15 Thread Hayato Ito
Though I'm afraid that I can not attend the in-person meeting in April, I can join remotely, per unusual. On Tue, Mar 15, 2016 at 1:35 PM Dimitri Glazkov wrote: > I am game, per usual. > > :DG< > > On Mon, Mar 14, 2016 at 4:55 PM, Ryosuke Niwa wrote: > >>

Re: Telecon / meeting on first week of April for Web Components

2016-03-21 Thread Hayato Ito
Either option is okay to me. I'll attend the meeting from Tokyo. On Tue, Mar 22, 2016 at 11:36 AM Brian Kardell wrote: > > On Mar 21, 2016 3:17 PM, "Ryosuke Niwa" wrote: > > > > For people participating from Tokyo and Europe, would you prefer having > it in