from:"Hayato Ito"

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 early morning or late evening?
> >
> > Because Bay Area, Tokyo, and Europe are almost uniformly distributed
> across the timezone, our time slots are limited:
> >
> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20160405=900=248=268
> >
> > Do people from Tokyo can participate in the meeting around midnight?
> >
> > If so, we can schedule it at UTC 3PM, which is 8AM in bay area, midnight
> in Tokyo, and 5AM in Europe.
> >
> > Another option is at UTC 7AM, which is 11PM in bay area, 3PM in Tokyo,
> and 8AM in Europe.
> >
> > - R. Niwa
> >
>
> I can afford to attend remotely! :)
>

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:
>
>> Hi all,
>>
>> We've been making a good progress on shadow DOM and custom elements API
>> but there seems to be a lot of open questions still.  I've asked a couple
>> of people involved in the discussion, and there seems to be an interest for
>> having another tele-conference or an in-person meeting.
>>
>> Can we schedule one in the second week of April (April 4th through 8th)?
>>
>> - R. Niwa
>>
>>
>>
>

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

2015-11-15 Thread Hayato Ito

Thank you, Ryosuke. I'm fine not to have a meeting in Dec.

Let me add a link to GitHub issue(s) for each item:

> 1. Clarify focus navigation

I think the following two GitHub issues are good starting points to know
the current status.
https://github.com/w3c/webcomponents/issues/103
https://github.com/w3c/webcomponents/issues/126

> 2. Clarify selection behavior (at least make it interoperable to JS)

https://github.com/w3c/webcomponents/issues/79
I think this is the hardest issue for us.

> 3. Decide on the style cascading order

https://github.com/w3c/webcomponents/issues/316
I think everyone can agree on Proposal 1, as I commented in the issue.

> 4. style inheritance

https://github.com/w3c/webcomponents/issues/314
I've already closed this issue. Please feel free to re-open the issue to
restart the discussion.


On Sat, Nov 14, 2015 at 1:31 AM Ryosuke Niwa <rn...@apple.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?
> >
> > Again, not I, but Hayato Ito raised these. I just happen to agree. He
> > emailed this list on November 2:
> >
> >
> https://lists.w3.org/Archives/Public/public-webapps/2015OctDec/0149.html
>
> Of the four issues listed there:
>
> > On Nov 1, 2015, at 7:52 PM, Hayato Ito <hay...@chromium.org> wrote:
> >
> > > 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'd like to resolve 3 and 4 ASAP since we're pretty close.  I don't think
> we necessarily need an in-person meeting to do that though.  If anything,
> it's probably more helpful to have discussion over mailing lists so that
> each person can spend as much time as needed to understand / come up with
> examples and proposals.
>
> For 1, we had a rough consensus on how current focus model (in particular
> focus ordering) should be changed to support shadow DOM during TPAC.
> Namely, we would create a new tab index "scope" at both shadow roots as
> well as slots, and follow the composed tree order for tab ordering.  I
> think someone should document that first.
>
> I just started working on 2 but I probably won't have a time to come up
> with a proposal until mid December.
>
>
> So if you guys can't make it, I don't think we necessarily need a shadow
> DOM meeting in December.
>
> - R. Niwa
>
>
>

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:

- We have well-defined one-or-more proposals other than the current spec
- We've discussed the pros and cons of each proposal (and the current spec)
well
- However, we can not reach the consensus.

Unless a well-defined proposal before the meeting, I'm afraid it would be
difficult to have a consensus in the meeting.

Topic 1)
I can see one proposal about this topic:
https://github.com/w3c/webcomponents/issues/126.
This proposal doesn't replace the current behavior. It just adds the new
feature to current behavior.

Topic 2)
This issue has been an unresolved problem for years. There is no proposal
at all.

Topic 3)
This is the summary I've written:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order-in-v1.md

Topic 4)
There is no well-defined proposal other than the current spec.

It wold be nice to make the situation clear before the meeting so that we
don't have additional topics other than Custom Elements on f2f meetings.

On Thu, Oct 29, 2015 at 3:07 PM Ryosuke Niwa  wrote:

> >
> > On Oct 29, 2015, at 9:47 AM, Chris Wilson  wrote:
> >
> > Or host in Seattle.  :)
> >
> > On Thu, Oct 29, 2015 at 9:20 AM, Travis Leithead <
> travis.leith...@microsoft.com> wrote:
> >> I would prefer a late January date so as to allow me to arrange travel.
> Otherwise, I’m happy to attend remotely anytime.
>
> I'm okay with either option with a slight preference on having it earlier
> since we didn't have much time discussing custom elements at TPAC.
>
> I would like to resolve the following issues for shadow DOM:
> 1. Clarify focus navigation
> 2. Clarify selection behavior (at least make it interoperable to JS)
> 3. Decide on the style cascading order
>
> And the following issues for custom elements:
> 4. Construction model. Do we do sync / almost-sync / dance?
> 5. Do we support upgrading?  If we do, how?
>
> Any other issues?
>
> - R. Niwa
>
>
>

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-trivial monkey patches to DOM.  I have a
> plan
> > to upstream the Shadow DOM spec into DOM in the near future. After that,
> I
> > think we can address some of issues by updating DOM spec directly.
>
> That sounds great!
>
> It also seems there's still a number of issues around integration with
> HTML. That is, what the effect of HTML elements should be inside
> shadow trees. I seem to remember Ian having more detailed notes, but
> quickly looking around I only found:
>
> * https://www.w3.org/Bugs/Public/show_bug.cgi?id=27406
> * https://www.w3.org/Bugs/Public/show_bug.cgi?id=26952
> * https://www.w3.org/Bugs/Public/show_bug.cgi?id=28748
>
> And these don't seem to mention the effects of various algorithms.
> E.g., named access on the global object currently finds child browsing
> contexts, but I don't think we would want it to return any that are
> inside a shadow tree. And should browsing contexts inside shadow trees
> have an effect on history?
>
>
I think the spec should address these issues and define the well-defined
behavior clearly. The current spec looks too lazy because it only mention
the following:

> Window object named properties [HTML] must access the nodes in the
document tree.

I think this is not enough to achieve the interoperability among UAs.


> Then there's the matter of text selection which we're not sure about
> what to do. Have you folks worked on that?
>
>
I've discussed this topic several times in Google, however, this is still
an unsolved problem.
We don't have anything which we can upstream to the spec yet.
In Blink, we've supported only "Copy" for a selection which spans shadow
boundaries.
Any ideas are highly welcome.


>
> --
> https://annevankesteren.nl/
>

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

2015-09-01 Thread Hayato Ito

Thank you for the feedback! Let me take a look at the filed issues. I
really appreciate it.
It looks  https://github.com/w3c/webcomponents/issues/308 is the only
conceptual problem. I think I can send "Intent to Implement: Shadow DOM v1"
in Blink soon. :)

On Wed, Sep 2, 2015 at 5:43 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/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__w3c.github.io_webcomponents_spec_shadow_=BQMFaQ=eEvniauFctOgLOKGJOplqw=051zrPFUkWGMfGlKdhy9Uw=Ob0zDi81QSdDXfbw7D4TwLer5St-dE9GmsZoIHDLcqM=ao7lIY8fDs6pqDsJ_OCg2uo6IX3xsRHMs575RmV_ZCE=>
>
> I've almost done the spec work for Shadow DOM v1. I think it's time to be
> reviewed and get feedback. I hope that a browser vendor, including me, can
> start to implement it based on the current spec.
>
> You might want to use https://github.com/w3c/webcomponents/issues/289
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_webcomponents_issues_289=BQMFaQ=eEvniauFctOgLOKGJOplqw=051zrPFUkWGMfGlKdhy9Uw=Ob0zDi81QSdDXfbw7D4TwLer5St-dE9GmsZoIHDLcqM=KbtdA0FA-hhRaB8W46DFmZ_DI9PMd0dE8iGwvJ1x61Y=>
> to give me feedback. Please feel free to file a new issue if preferred.
>
>
> I've filed a bunch of editorial issues.
>
> One conceptual problem I have with the current spec is how it "unwrap"
> nested slots.  I thought we had a consensus not to do this at F2F?
> https://github.com/w3c/webcomponents/issues/308 tracks this particular
> issue.
>
> - R. Niwa
>
>

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 we agreed:
https://github.com/w3c/webcomponents/commits/gh-pages/spec/shadow/

ETA is the end of this month, excluding other V1 issues which have not been
contentious bits so far.

On Mon, Aug 10, 2015 at 10:21 PM Wilson Page wilsonp...@me.com wrote:

 Hi All,

 I was unable to attend the latest F2F so would like clarification on what
 the takeaway action items were and who is responsible for pushing them
 forward. I don't believe this information was included in the minutes.

 I heard there was agreement around Shadow DOM. Who is tasked with updating
 the spec and in what time frame?

 Cheers :)

 Wilson

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 to the cascade order in the CSS Scoping spec
 on www-style[1] a while back. I've had positive feedback from Google,
 but I thought I'd notify WebApps, as some Web Components people might
 not be on www-style.

 I've sent a github pull request for adding the proposal[2] to
 w3c/webcomponents.

 [1] https://lists.w3.org/Archives/Public/www-style/2015Jun/0303.html
 [2]
 https://github.com/rune-opera/webcomponents/blob/rune/shadow-cascade-order-20150804/proposals/Shadow-DOM-Cascade-Order.md

 --
 Rune Lillesveen

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

2015-07-06 Thread Hayato Ito

I've finished the migration. All 141 bugs have been migrated [1]. I'll
triage the migrated bugs manually later.

I'm sorry that public-webapps@ has received the mass flood of bugspam mail
again this time. That's unintentional.
The lesson for for the future: We need to change also the setting of
*every* bugs to stop the auto-emails, not only from the default CC list.

From now on, please use the GitHub issues [2] to file a bug for Web
Components. I've already updated [3] the editors' drafts of Custom Elements
and HTML Imports so that they have a link to GitHub Issues.
xiaoqian@ will kindly disable the bugzilla component, Component Models,
so that people won't add a bug there.

- [1]: https://github.com/w3c/webcomponents/issues/119
- [2]: https://github.com/w3c/webcomponents/issues
- [3]:
https://github.com/w3c/webcomponents/commit/54434ada278440999649915b00772b6e96e57d4d


On Wed, Jul 1, 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 finish, I'll announce that.


 SGTM. Please go ahead.

 —
 xiaoqian

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: [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

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

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 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
 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 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 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 spec bugs will be migrated into GitHub issues

2015-05-27 Thread Hayato Ito

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 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 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 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 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 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

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 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: [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. 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.
 Both, Multiple Templates and Imperative APIs are deferred to v2.
 There is still no convincing proposal about how these are interacted in the
 future.


 Those were never conjoined that much. Slots and multiple templates are
 part of the same proposal, but they are largely independent pieces. As for
 slots being a prerequisite for imperative APIs, I only remember it being
 mentioned in the sense that any flavor of declarative API should be
 implementable by the imperative API.



 I'd like to see a concrete proposal which explains all together in v2.
 For v1, I don't see any strong reason to replace the current select.


 Is the situation where no other vendors are willing to implement the
 current select not a strong reason?



Agreed.


 I am not fan of bedding something which is unclear.

 Could someone summarize the pros and cons of content-slot, compared to
 select?
 For me, cons are much bigger than pros in v1. I don't want to miss
 anything.


 That's a good request. I'll work on the comparison, including Domenic's
 request to outline the constant-timeliness.



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 by a
fixed id using attribute.

I'd like to make sure that everyone understand the pros and cons for both
as a separated topic from Imperative APIs and Multiple Templates so that
we can do the best judgement.




 :DG

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

2015-05-18 Thread Hayato Ito

I think we can learn something from existing programming languages.
For example, I like Python's way to handle function's parameters. That
enables us to select:

- By Position
- By Keyword
- *args (Grab unused positional arguments)
- *kwds* (Grap unused keyword arguments)

I think this is over-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 *hint* to the nodes beforehand
 if we wish.

 Is this a correct problem statement? I think we don't have to limit our
 answers to this problem by the current select and the content-slot.
 Any better ideas can be acceptable, I think.

 The hint we can use is:

 - tag name
 - id attribute
 - class attribute
 - any other attributes. (Okay to have a dedicated attribute, such as
 'content-slot')
 - The position of the node in the list
 - Other status, such as :focused (in CSS's terminology)
 - Anything else?

 I think the current content select  has been there in the spec for a
 long time. No one hasn't spent much time on thinking a replacement of it
 until recently.
 I hope that this discussion might be a good opportunity to get an
 agreement between us.


 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 by
 a fixed id using attribute.


 BTW, here's one bit of research I'd done:
 https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Partial-Redistributions-Analysis.md

 :DG

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

2015-05-18 Thread Hayato Ito

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 *hint* to the nodes beforehand if we
wish.

Is this a correct problem statement? I think we don't have to limit our
answers to this problem by the current select and the content-slot.
Any better ideas can be acceptable, I think.

The hint we can use is:

- tag name
- id attribute
- class attribute
- any other attributes. (Okay to have a dedicated attribute, such as
'content-slot')
- The position of the node in the list
- Other status, such as :focused (in CSS's terminology)
- Anything else?

I think the current content select  has been there in the spec for a long
time. No one hasn't spent much time on thinking a replacement of it until
recently.
I hope that this discussion might be a good opportunity to get an agreement
between us.


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 by a
 fixed id using attribute.


 BTW, here's one bit of research I'd done:
 https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Partial-Redistributions-Analysis.md

 :DG

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.
Both, Multiple Templates and Imperative APIs are deferred to v2. There
is still no convincing proposal about how these are interacted in the
future.

I'd like to see a concrete proposal which explains all together in v2. For
v1, I don't see any strong reason to replace the current select.
I am not fan of bedding something which is unclear.

Could someone summarize the pros and cons of content-slot, compared to
select?
For me, cons are much bigger than pros in v1. I don't want to miss anything.

On Tue, May 19, 2015 at 10:37 AM Domenic Denicola d...@domenic.me wrote:

From: Justin Fagnani [mailto:justinfagn...@google.com]

They're not equivalent, because any element can have the right
content-slot value, but with tag names, only one (or maybe N) names would
be supported.

Hmm, I don't understand, and fear we might be talking past each other. Can
you give an example where content-slot works but tag names do not? For
example
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution.md#proposal-part-1-syntax-for-named-insertion-points
gets translated from

combo-box
icon/icon
dropdown
… Choices go here …
/dropdown
/combo-box

Your stated sentence doesn't make much sense to me; you can have multiple
elements with the same tag name. Literally, just take any example you can
write x content-slot=y ... /x and replace those with y and /y.

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. The
responsibility of UA is just to make sure the distribution is updated
whenever UA has to return any result which depends on the distribution. UA
can choose any evaluation strategy as long as it's not observable from the
outside.

Looks the spec needs more good wording for this.
Any good ideas for wording?



   All the issues Dimitri highlighted are symptoms of layout running before
 distribution.
 
  On Fri, May 15, 2015 at 3:46 PM, Olli Pettay o...@pettay.fi mailto:
 o...@pettay.fi wrote:
 
  On 05/15/2015 05:37 PM, Wilson Page wrote:
 
  Would it be possible to leave the calling of the shadowRoot's
 distribute() function to the engine? This way the engine can be in full
 control over
  *when* distribution happens.
 
 
 
  We would need to define when the engine calls it, otherwise web
 pages start to rely on the behavior of whatever engine the developers of the
  particular page mostly use.
 
 
 
  -Olli
 
 
 
  On Wed, May 13, 2015 at 5:46 PM, Dimitri Glazkov 
 dglaz...@google.com mailto:dglaz...@google.com mailto:
 dglaz...@google.com
  mailto:dglaz...@google.com wrote:
 
   I did a quick experiment around distribution timing:
 
 https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Distribution-Timing-Experiment.md.
 Hope you find it helpful.
 
   :DG

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.

 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 bottom line.

 In the current distribution model, I expect we can achieve this goal,
 thanks to the lazy evaluation of distribution.

 Is there any plan how we should evaluate these proposals in terms of
 performance primitives?


 On Thu, May 7, 2015 at 7:53 AM Ryosuke Niwa rn...@apple.com wrote:


  On May 6, 2015, at 2:39 PM, Elliott Sprehn espr...@chromium.org
 wrote:
 
  The 3 proposal is what the houdini effort is already researching for
 custom style/layout/paint. I don't think it's acceptable to make all usage
 of Shadow DOM break when used with libraries that read layout information
 today, ie. offsetTop must work. I also don't think it's acceptable to
 introduce new synchronous hooks and promote n^2 churn in the distribution.

 Sorry, I don't follow. If we're making offsetTop to synchronously return
 the correct value, then authors can easily write code that performs in
 Ω(n^2) by obtaining the value of offsetTop between adding/removing direct
 children of a shadow host.  On the other hand, if we're trying to prevent
 O(n^2) behavior, then we should be adding API to asynchronously retrieve
 layout information.

 - R. Niwa

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

2015-05-07 Thread Hayato Ito

Ryosuke, could you file a bug for the spec if you find an uncomfortable
part in the spec?
I want to understand exactly what you are trying to improve.

On Fri, May 8, 2015 at 2:21 AM Ryosuke Niwa rn...@apple.com wrote:


  On May 6, 2015, at 11:10 PM, Elliott Sprehn espr...@chromium.org
 wrote:
 
  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 and I simply disagree with that assessment. CSS
  operates on the composed tree (and forms a render tree from it).
  Events operate on the composed tree. Selection operates on the
  composed tree (likely, we haven't discussed this much).
 
  Selection operates on the render tree. The current selection API is
 (completely) busted for modern apps, and a new one is needed that's based
 around layout. Flexbox w/ order, positioned objects, distributions, grid,
 none of them work with the DOM based API.

 Please state your presumptions like that before making a statement such as
 composed street is a style concept.

 Now, even if selection were to operate on the CSS box tree, of which I
 will not express my opinion of, event path is still not a style concept.
 If you're proposing to make it a style concept, then I just need to object
 to that.

 - R. Niwa

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

2015-05-07 Thread Hayato Ito

Yeah, we, in Google, had several discussion about how the next *Selection
APIs* should be. However we don't have any concrete proposals yet.
We are aware that we need the new APIs because the existing APIs is not
suitable.

On Thu, May 7, 2015 at 3:10 PM Elliott Sprehn espr...@chromium.org wrote:

 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 and I simply disagree with that assessment. CSS
 operates on the composed tree (and forms a render tree from it).
 Events operate on the composed tree. Selection operates on the
 composed tree (likely, we haven't discussed this much).


 Selection operates on the render tree. The current selection API is
 (completely) busted for modern apps, and a new one is needed that's based
 around layout. Flexbox w/ order, positioned objects, distributions, grid,
 none of them work with the DOM based API.

 - E

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 hay...@chromium.org wrote:
 
  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 Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn 
 espr...@chromium.org wrote:
   We can solve this
   problem by running the distribution code in a separate scripting
 context
   with a restricted (distribution specific) API as is being
 discussed for
   other extension points in the platform.
  
   That seems like a lot of added complexity, but yeah, that would be
 an
   option I suppose. Dimitri added something like this to the
 imperative
   API proposal page a couple of days ago.
  
  
   One thing to consider here is that we very much consider
 distribution a
   style concept. It's about computing who you inherit style from and
 where you
   should be in the box tree. It just so happens it's also leveraged
 in event
   dispatch too (like pointer-events). It happens asynchronously from
 DOM
   mutation as needed just like style and reflow though.
  
   I don't really see it that way. The render tree is still computed
 from
   the composed tree. The composed tree is still a DOM tree, just
   composed from various other trees. In the open case you can access
   it synchronously through various APIs (e.g.  if we keep that for
   querySelector() selectors and also deepPath).
  
   I agree. I don't see any reason node distribution should be
 considered as a style concept. It's a DOM concept. There is no CSS involved
 here.
  
   Yes there is.  As Elliot stated in the elided parts of his quoted
   response above, most of the places where we update distribution are
   for CSS or related concerns:
  
   # 3 event related
   # 3 shadow dom JS api
 
  These two are nothing to do with styles or CSS.
 
  I'd like to inform all guys in this thread that Composed Tree is for
 resolving CSS inheritance by the definition.
  See the Section 2.4 Composed Trees in the spec:
  http://w3c.github.io/webcomponents/spec/shadow/#composed-trees
 
  Let me quote:
   If an element doesn't participate in a composed tree whose root node
 is a document, the element must not appear in the formating structure
 [CSS21] nor create any CSS box. This behavior must not be overridden by
 setting the 'display' property.
 
   In resolving CSS inheritance, an element must inherit from the parent
 node in the composed tree, if applicable.
 
  The motivation of a composed tree is to determine the parent node in
 resolving CSS inheritance. There is no other significant usages, except for
 event path.

 Event path / retargeting is definitely event related, and it (e.g.
 deepPath) is definitely a part of shadow DOM JS API.  Again, they're
 nothing to do with styles or CSS.

 - R. Niwa

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 Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org
 wrote:
  We can solve this
  problem by running the distribution code in a separate scripting
 context
  with a restricted (distribution specific) API as is being discussed
 for
  other extension points in the platform.
 
  That seems like a lot of added complexity, but yeah, that would be an
  option I suppose. Dimitri added something like this to the imperative
  API proposal page a couple of days ago.
 
 
  One thing to consider here is that we very much consider distribution
 a
  style concept. It's about computing who you inherit style from and
 where you
  should be in the box tree. It just so happens it's also leveraged in
 event
  dispatch too (like pointer-events). It happens asynchronously from DOM
  mutation as needed just like style and reflow though.
 
  I don't really see it that way. The render tree is still computed from
  the composed tree. The composed tree is still a DOM tree, just
  composed from various other trees. In the open case you can access
  it synchronously through various APIs (e.g.  if we keep that for
  querySelector() selectors and also deepPath).
 
  I agree. I don't see any reason node distribution should be considered
 as a style concept. It's a DOM concept. There is no CSS involved here.
 
  Yes there is.  As Elliot stated in the elided parts of his quoted
  response above, most of the places where we update distribution are
  for CSS or related concerns:
 
  # 3 event related
  # 3 shadow dom JS api

 These two are nothing to do with styles or CSS.


I'd like to inform all guys in this thread that Composed Tree is for
resolving CSS inheritance by the definition.
See the Section 2.4 Composed Trees in the spec:
http://w3c.github.io/webcomponents/spec/shadow/#composed-trees

Let me quote:
 If an element doesn't participate in a composed tree whose root node is a
document, the element must not appear in the formating structure [CSS21]
nor create any CSS box. This behavior must not be overridden by setting the
'display' property.

 In resolving CSS inheritance, an element must inherit from the parent
node in the composed tree, if applicable.

The motivation of a composed tree is to determine the parent node in
resolving CSS inheritance. There is no other significant usages, except for
event path.



  I have issues with the argument that we should do it lazily.  On one
 hand, if node distribution is so expensive that we need to do it lazily,
 then it's unacceptable to make event dispatching so much slower.  On the
 other hand, if node distribution is fast, as it should be, then there is no
 reason we need to do it lazily.
 
  The problem is really the redistributions. If we instead had explicit
 insertion points under each shadow host, then we wouldn't really need
 redistributions at all, and node distribution can happen in O(1) per child
 change.
 
  As repeatedly stated, redistribution appears to be a necessity for
  composition to work in all but the most trivial cases.

 Where?  I have not yet to see a use case for which selective
 redistribution of nodes (i.e. redistributing only a non-empty strict subset
 of nodes from an insertion point) are required.

 - R. Niwa

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

2015-05-06 Thread Hayato Ito

I'm feeling that there is a misunderstanding about the relation between DOM
tree and Composed Tree in this discussion.
If you understand the difference, the discussion might be more productive.

In short,
- Composed Tree DOES NOT replace DOM tree. Most of existing APIs work for
DOM tree. Composed 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:


  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 Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn espr...@chromium.org
 wrote:
  We can solve this
  problem by running the distribution code in a separate scripting
 context
  with a restricted (distribution specific) API as is being discussed
 for
  other extension points in the platform.
 
  That seems like a lot of added complexity, but yeah, that would be an
  option I suppose. Dimitri added something like this to the imperative
  API proposal page a couple of days ago.
 
 
  One thing to consider here is that we very much consider
 distribution a
  style concept. It's about computing who you inherit style from and
 where you
  should be in the box tree. It just so happens it's also leveraged in
 event
  dispatch too (like pointer-events). It happens asynchronously from
 DOM
  mutation as needed just like style and reflow though.
 
  I don't really see it that way. The render tree is still computed from
  the composed tree. The composed tree is still a DOM tree, just
  composed from various other trees. In the open case you can access
  it synchronously through various APIs (e.g.  if we keep that for
  querySelector() selectors and also deepPath).
 
  I agree. I don't see any reason node distribution should be considered
 as a style concept. It's a DOM concept. There is no CSS involved here.
 
  Yes there is.  As Elliot stated in the elided parts of his quoted
  response above, most of the places where we update distribution are
  for CSS or related concerns:
 
  # 3 event related
  # 3 shadow dom JS api

 These two are nothing to do with styles or CSS.


 I'd like to inform all guys in this thread that Composed Tree is for
 resolving CSS inheritance by the definition.
 See the Section 2.4 Composed Trees in the spec:
 http://w3c.github.io/webcomponents/spec/shadow/#composed-trees

 Let me quote:
  If an element doesn't participate in a composed tree whose root node is
 a document, the element must not appear in the formating structure [CSS21]
 nor create any CSS box. This behavior must not be overridden by setting the
 'display' property.

  In resolving CSS inheritance, an element must inherit from the parent
 node in the composed tree, if applicable.

 The motivation of a composed tree is to determine the parent node in
 resolving CSS inheritance. There is no other significant usages, except for
 event path.



  I have issues with the argument that we should do it lazily.  On one
 hand, if node distribution is so expensive that we need to do it lazily,
 then it's unacceptable to make event dispatching so much slower.  On the
 other hand, if node distribution is fast, as it should be, then there is no
 reason we need to do it lazily.
 
  The problem is really the redistributions. If we instead had explicit
 insertion points under each shadow host, then we wouldn't really need
 redistributions at all, and node distribution can happen in O(1) per child
 change.
 
  As repeatedly stated, redistribution appears to be a necessity for
  composition to work in all but the most trivial cases.

 Where?  I have not yet to see a use case for which selective
 redistribution of nodes (i.e. redistributing only a non-empty strict subset
 of nodes from an insertion point) are required.

 - R. Niwa

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
bottom line.

In the current distribution model, I expect we can achieve this goal,
thanks to the lazy evaluation of distribution.

Is there any plan how we should evaluate these proposals in terms of
performance primitives?


On Thu, May 7, 2015 at 7:53 AM Ryosuke Niwa rn...@apple.com wrote:


  On May 6, 2015, at 2:39 PM, Elliott Sprehn espr...@chromium.org wrote:
 
  The 3 proposal is what the houdini effort is already researching for
 custom style/layout/paint. I don't think it's acceptable to make all usage
 of Shadow DOM break when used with libraries that read layout information
 today, ie. offsetTop must work. I also don't think it's acceptable to
 introduce new synchronous hooks and promote n^2 churn in the distribution.

 Sorry, I don't follow. If we're making offsetTop to synchronously return
 the correct value, then authors can easily write code that performs in
 Ω(n^2) by obtaining the value of offsetTop between adding/removing direct
 children of a shadow host.  On the other hand, if we're trying to prevent
 O(n^2) behavior, then we should be adding API to asynchronously retrieve
 layout information.

 - R. Niwa

Re: Inheritance Model for Shadow DOM Revisited

2015-04-30 Thread Hayato Ito

Thanks, let me update my understanding:

- There is no use cases which shadow as function can't support, but
content slot can support.
- The purpose of the proposal is to remove an *extra* syntax. There is no
other goals.
- There is no reason to consider content slot proposal if we have a use
case which this *extra* syntax can achieve.

I'm also feeling that several topic are mixed in the proposal, Imperative
APIs, Multiple Templates and content slot, which makes me hard to
understand the goal of each.
Can I assume that the proposal is trying to remove content select, not
only from 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 shadow as function can't support, but
 content slot can support.
  - there are use cases which shadow as function can support, but
 content slot can't support.

 I disagree. What shadow as function provides is an extra syntax by
 which authors can choose elements. That's not a use case. A use case is a
 solution for a concrete user scenario such as building a social network
 button.

  - shadow as function is more expressive than content slot

 Again, I disagree.

  - content slot is trying to achieve something by removing
 expressiveness from web developers, instead of trusting them.
 
  I still don't understand fully what the proposal is trying to achieve.
 I've never heard such a complain, content select is too expressive and
 easy to be misused. Please remove it, from web developers.
 
  I think any good APIs could be potentially wrongly used by a web
 developer. But that shouldn't be a reason that we can remove a expressive
 API from web developers who can use it correctly and get benefits from the
 expressiveness.

 Now let me make an analogous comparison between C++ and assembly language.

 - There is no use cases which assembly can't support, but C++ can support.
 - There are use cases which assembly can support, but C++ can't support.
 - Assembly language is more expressive than C++.
 - C++ is trying to achieve something by removing expressiveness from
 programmers, instead of trusting them.

 Does that mean we should all be coding in assembly? Certainly not.

 For a more relevant analogy, one could construct the entire document using
 JavaScript without using HTML at all since DOM API exposed to JavaScript
 can construct the set of trees which is a strict superset of what HTML tree
 building algorithm can generate. Yet, we don't see that happening even in
 the top tier Web apps just because DOM API is more expressive. The vast
 majority of Web apps still use plenty of templates and declarative formats
 to construct DOM for simplicity and clarity even though imperative
 alternatives are strictly more powerful.

 Why did we abandon XHTML2.0? It was certainly more expressive. Why not
 SGML? It's a lot more expressive than XML. You can re-define special
 character as you'd like. Because expressiveness is not necessary the most
 desirable characteristics of anything by itself. The shape of a solution we
 need depends on the kind of problems we're solving.

 - R. Niwa

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 =
 console.log(e.path))
   someNodeThatIsDistributed.dispatchEvent(ev);
 
  Can you explain in a bit more detail why this causes interop problems?
 What browsers would give different results for this code? What would those
 results be?

 This essentially forces distribution to happen since you can observe
 the result of distribution this way. Same with element.offsetWidth
 etc.


That's the exactly intended behavior in the current spec.
The timing of distribution is not observable. That enables UA to optimize
the distribution calc. We can delay the calculation of the distribution as
possible as we can. We don't need to calc distribution every time when a
mutation occurs.

If you find any interop issue in the current spec about distribution,
please file a bug with a concrete example.






 --
 https://annevankesteren.nl/

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 not necessarily problematic,
 
  OK. So the claim that the current spec cannot be interoperably
 implemented is false? (Not that I am a huge fan of content select, but I
 want to make sure we have our arguments against it lined up and on solid
 footing.)
 
  but it is problematic if you want to do an imperative API as I tried to
 explain in the bit you did not quote back.
 
  Sure, let's dig in to that claim now. Again, this is mostly clarifying
 probing.
 
  Let's say we had an imperative API. As far as I understand from the
 gist, one of the problems is when do we invoke the distributedCallback. If
 we use MutationObserve time, then inconsistent states can be observed, etc.
 
  Why can't we say that this distributedCallback must be invoked at the
 same time that the current spec updates the distribution result? Since it
 sounds like there is no interop problem with this timing, I don't
 understand why this wouldn't be an option.

 There will be an interop problem. Consider a following example:


The return value of (2) is the same in either case. There is no observable
difference. No interop issue.

Please file a bug for the spec with a concrete example if you can find a
observable difference due to the lazy-evaluation of the distribution.



 ```js
 someNode = ~
 myButton.appendChild(someNode); // (1)
 absolutelyPositionElement.offsetTop; // (2)
 ```

 Now suppose absolutelyPositionElement.offsetTop is a some element that's
 in a disjoint subtree of the document. Heck, it could even in a separate
 iframe. In some UAs, (2) will trigger style resolution and update of the
 layout. Because UAs can't tell redistribution of myButton can affect (2),
 such UAs will update the distribution per spec text that says the
 distribution result must be updated before any _use_ of the distribution
 result.

 Yet in other UAs, `offsetTop` may have been cached and UA might be smart
 enough to detect that (1) doesn't affect the result of
 `absolutelyPositionElement.offsetTop` because they're in a different parts
 of the tree and they're independent for the purpose of style resolution and
 layout. In such UAs, (2) does not trigger redistribution because it does
 not use the distribution result in order to compute this value.

 In general, there are thousands of other DOM and CSS OM APIs that may or
 may not _use_ the distribution result depending on implementations.

 - R. Niwa

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...@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 not necessarily problematic,
  
   OK. So the claim that the current spec cannot be interoperably
 implemented is false? (Not that I am a huge fan of content select, but I
 want to make sure we have our arguments against it lined up and on solid
 footing.)
  
   but it is problematic if you want to do an imperative API as I tried
 to explain in the bit you did not quote back.
  
   Sure, let's dig in to that claim now. Again, this is mostly
 clarifying probing.
  
   Let's say we had an imperative API. As far as I understand from the
 gist, one of the problems is when do we invoke the distributedCallback. If
 we use MutationObserve time, then inconsistent states can be observed, etc.
  
   Why can't we say that this distributedCallback must be invoked at the
 same time that the current spec updates the distribution result? Since it
 sounds like there is no interop problem with this timing, I don't
 understand why this wouldn't be an option.
 
  There will be an interop problem. Consider a following example:
 
 
  The return value of (2) is the same in either case. There is no
 observable difference. No interop issue.
 
  Please file a bug for the spec with a concrete example if you can find a
 observable difference due to the lazy-evaluation of the distribution.

 The problem isn't so much that the current shadow DOM specification has an
 interop issue because what we're talking here, as the thread title clearly
 communicates, is the imperative API for node distribution, which doesn't
 exist in the current specification.

 In particular, invoking user code at the timing specified in section 3.4
 which states if any condition which affects the distribution result
 changes, the distribution result must be updated before any use of the
 distribution result introduces a new interoperability issue because
 before any use of the distribution result is implementation dependent.
 e.g. element.offsetTop may or not may use the distribution result depending
 on UA.  Furthermore, it's undesirable to precisely spec this since doing so
 will impose a serious limitation on what UAs could optimize in the future.

 - R. Niwa

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 Imperative API as of now. Let's re-open this issue after we
 can see how an Imperative API goes.
 I'll file a bug for the spec about this inheritance challenge so that we
 can continue the discussion in the bugzilla.


 On Thu, Apr 30, 2015 at 8:43 PM Anne van Kesteren ann...@annevk.nl
 wrote:

 On Tue, Apr 28, 2015 at 7:09 PM, Ryosuke Niwa rn...@apple.com wrote:
  The problem with shadow as function is that the superclass
 implicitly selects nodes based on a CSS selector so unless the nodes a
 subclass wants to insert matches exactly what the author of superclass
 considered, the subclass won't be able to override it. e.g. if the
 superclass had an insertion point with select=input.foo, then it's not
 possible for a subclass to then override it with, for example, an input
 element wrapped in a span.

 So what if we flipped this as well and came up with an imperative API
 for shadow as a function. I.e. shadow as an actual function?
 Would that give us agreement?

 It'd be great to have something like this available.


 --
 https://annevankesteren.nl/

Re: Inheritance Model for Shadow DOM Revisited

2015-04-29 Thread Hayato Ito

Thanks. As far as my understanding is correct, the conclusions so far are:

- There is no use cases which shadow as function can't support, but
content slot can support.
- there are use cases which shadow as function can support, but
content slot can't support.
- shadow as function is more expressive than content slot
- content slot is trying to achieve something by removing
expressiveness from web developers, instead of trusting them.

I still don't understand fully what the proposal is trying to achieve. I've
never heard such a complain, content select is too expressive and easy
to be misused. Please remove it, from web developers.

I think any good APIs could be potentially wrongly used by a web developer.
But that shouldn't be a reason that we can remove a expressive API from web
developers who can use it correctly and get benefits from the
expressiveness.

On Wed, Apr 29, 2015 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 it once in the spec (and implemented
 it in blink). I think Jan Miksovsky, co-author of Apple's proposal, knows
 well that.
 
  We're (and consequently I'm) fully aware of that feature/prosal, and we
 still don't think it adequately addresses the needs of subclassing.
 
  The problem with shadow as function is that the superclass
 implicitly selects nodes based on a CSS selector so unless the nodes a
 subclass wants to insert matches exactly what the author of superclass
 considered, the subclass won't be able to override it. e.g. if the
 superclass had an insertion point with select=input.foo, then it's not
 possible for a subclass to then override it with, for example, an input
 element wrapped in a span.
 
   The reason I reverted it from the spec (and the blink), [1], is a
 technical difficulty to implement, though I've not proved that it's
 impossible to implement.
 
  I'm not even arguing about the implementation difficulty. I'm saying
 that the semantics is inadequate for subclassing.

  On Apr 28, 2015, at 10:34 AM, Hayato Ito hay...@chromium.org wrote:
 
  Could you help me to understand what implicitly means here?

 I mean that the superclass’ insertion points use a CSS selector to select
 nodes to distribute. As a result, unless the subclass can supply the
 exactly kinds of nodes that matches the CSS selector, it won’t be able to
 override the contents into the insertion point.

  In this particular case, you might want to blame the super class's
 author and tell the author, Please use content select=.input-foo so that
 subclass can override it with arbitrary element with class=input-foo”.

 The problem is that it may not be possible to coordinate across class
 hierarchy like that if the superclass was defined in a third party library.
 With the named slot approach, superclass only specifies the name of a slot,
 so subclass will be able to override it with whatever element it supplies
 as needed.

  Could you give me an concrete example which content slot can support,
 but shadow as function can't support?

 The problem isn’t so much that slot can do something shadow as
 function can’t support. It’s that shadow as function promotes over
 specification of what element can get into its insertion points by the
 virtue of using a CSS selector.

 Now, it's possible that we can encourage authors to always use a class
 name in select attribute to support this use case. But then why are we
 adding a capability that we then discourage authors from using it.

 - R. Niwa

Re: Inheritance Model for Shadow DOM Revisited

2015-04-28 Thread Hayato Ito

Could you help me to understand what implicitly means here?

In this particular case, you might want to blame the super class's author
and tell the author, Please use content select=.input-foo so that
subclass can override it with arbitrary element with class=input-foo.

Could you give me 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 the motivation I've introduced it once in the spec (and implemented
 it in blink). I think Jan Miksovsky, co-author of Apple's proposal, knows
 well that.

 We're (and consequently I'm) fully aware of that feature/prosal, and we
 still don't think it adequately addresses the needs of subclassing.

 The problem with shadow as function is that the superclass implicitly
 selects nodes based on a CSS selector so unless the nodes a subclass wants
 to insert matches exactly what the author of superclass considered, the
 subclass won't be able to override it. e.g. if the superclass had an
 insertion point with select=input.foo, then it's not possible for a
 subclass to then override it with, for example, an input element wrapped in
 a span.

  The reason I reverted it from the spec (and the blink), [1], is a
 technical difficulty to implement, though I've not proved that it's
 impossible to implement.

 I'm not even arguing about the implementation difficulty. I'm saying that
 the semantics is inadequate for subclassing.

 - R. Niwa

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 what re-distribution *means*.
  Let me use a pseudo language and define XComponent's constructor as
 follows:
 
  XComponents::XComponents(Title text, Icon icon) {
this.text = text;
this.button = new XButton(icon);
...
  }
 
  Here, |icon| is *re-distributed*.
 
  In HTML world, this corresponds the followings:
 
  The usage of x-component element:
x-components
  x-textHello World/x-text
  x-iconMy Icon/x-icon
/x-component
 
  XComponent's shadow tree is:
 
shadow-root
  h1content select=x-text/content/h1!-- (1) --
  x-buttoncontent select=x-icon/content/x-button!-- (2) --
/shadow-root

 I have a question as to whether x-button then has to select which nodes to
 use or not.  In this particular example at least, x-button will put every
 node distributed into (2) into a single insertion point in its shadow DOM.

 If we don't have to support filtering of nodes at re-distribution time,
 then the whole discussion of re-distribution is almost a moot because we
 can just treat a content element like any other element that gets
 distributed along with its distributed nodes.


x-button can select.
You might want to take a look at the distribution algorithm [1], where the
behavior is well defined.

[1]: http://w3c.github.io/webcomponents/spec/shadow/#distribution-algorithms

In short, the distributed nodes of content select=x-icons will be the
next candidates of nodes from where insertion points in the shadow tree
x-button hosts can select.




 - R. Niwa

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 must
update distribution, if it's dirty, before calculation offsetWidth
synchronously.
- event dispatching: event path requires distribution because it needs a
composed tree.

Can the current HTML/DOM specs are rich enough to explain the timing when
the imperative APIs should be run in these cases?

For me, the imperative APIs for distribution sounds very similar to the
imperative APIs for style resolution. The difficulties of both problems
might be similar.





On Tue, Apr 28, 2015 at 7:18 AM Steve Orvell sorv...@google.com wrote:

 IMO, the appeal of this proposal is that it's a small change to the
 current spec and avoids changing user expectations about the state of the
 dom and can explain the two declarative proposals for distribution.


 It seems like with this API, we’d have to make O(n^k) calls where n is
 the number of distribution candidates and k is the number of insertion
 points, and that’s bad.  Or am I misunderstanding your design?


 I think you've understood the proposed design. As you noted, the cost is
 actually O(n*k). In our use cases, k is generally very small.

 Do you mean instead that we synchronously invoke this algorithm when a
 child node is inserted or removed from the host?  If so, that’ll impose
 unacceptable runtime cost for DOM mutations.
 I think the only timing UA can support by default will be at the end of
 micro task or at UA-code / user-code boundary as done for custom element
 lifestyle callbacks at the moment.


 Running this callback at the UA-code/user-code boundary seems like it
 would be fine. Running the more complicated distribute all the nodes
 proposals at this time would obviously not be feasible. The notion here is
 that since we're processing only a single node at a time, this can be done
 after an atomic dom action.

 “always correct” is somewhat stronger statement than I would state here
 since during UA calls these shouldDistributeToInsertionPoint callbacks,
 we'll certainly see transient offsetHeight values.


 Yes, you're right about that. Specifically it would be bad to try to read
 `offsetHeight` in this callback and this would be an anti-pattern. If
 that's not good enough, perhaps we can explore actually not working
 directly with the node but instead the subset of information necessary to
 be able to decide on distribution.

 Can you explain, under the initial proposal, how a user can ask an
 element's dimensions and get the post-distribution answer? With current
 dom api's I can be sure that if I do parent.appendChild(child) and then
 parent.offsetWidth, the answer takes child into account. I'm looking to
 understand how we don't violate this expectation when parent distributes.
 Or if we violate this expectation, what is the proposed right way to ask
 this question?

 In addition to rendering information about a node, distribution also
 effects the flow of events. So a similar question: when is it safe to call
 child.dispatchEvent such that if parent distributes elements to its
 shadowRoot, elements in the shadowRoot will see the event?

 On Mon, Apr 27, 2015 at 1:45 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Apr 27, 2015, at 11:47 AM, Steve Orvell sorv...@google.com wrote:

 Here's a minimal and hopefully simple proposal that we can flesh out if
 this seems like an interesting api direction:


 https://gist.github.com/sorvell/e201c25ec39480be66aa


 It seems like with this API, we’d have to make O(n^k) calls where n is
 the number of distribution candidates and k is the number of insertion
 points, and that’s bad.  Or am I misunderstanding your design?


 We keep the currently spec'd distribution algorithm/timing but remove
 `select` in favor of an explicit selection callback.


 What do you mean by keeping the currently spec’ed timing?  We certainly
 can’t do it at “style resolution time” because style resolution is an
 implementation detail that we shouldn’t expose to the Web just like GC and
 its timing is an implementation detail in JS.  Besides that, avoiding style
 resolution is a very important optimizations and spec’ing when it happens
 will prevent us from optimizing it away in the future/

 Do you mean instead that we synchronously invoke this algorithm when a
 child node is inserted or removed from the host?  If so, that’ll impose
 unacceptable runtime cost for DOM mutations.

 I think the only timing UA can support by default will be at the end of
 micro task or at UA-code / user-code boundary as done for custom element
 lifestyle callbacks at the moment.

 The user simply returns true if the node should be distributed to the
 given insertion point.

 Advantages:
  * the callback can be synchronous-ish because it acts only on a

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

2015-04-27 Thread Hayato Ito

Could you clarify what you are trying to achieve? If we don't support,
everything would be weird.

I guess you are proposing the alternative of the current pool population
algorithm and pool distribution algorithm.
I appreciate you could explain what are expected result using algorithms.



On Tue, 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 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 icon) {
this.text = text;
this.button = new XButton(icon);
...
  }
 
  Here, |icon| is *re-distributed*.
 
  In HTML world, this corresponds the followings:
 
  The usage of x-component element:
x-components
  x-textHello World/x-text
  x-iconMy Icon/x-icon
/x-component
 
  XComponent's shadow tree is:
 
shadow-root
  h1content select=x-text/content/h1!-- (1) --
  x-buttoncontent select=x-icon/content/x-button!-- (2) --
/shadow-root

 I have a question as to whether x-button then has to select which nodes
 to use or not.  In this particular example at least, x-button will put
 every node distributed into (2) into a single insertion point in its shadow
 DOM.

 If we don't have to support filtering of nodes at re-distribution time,
 then the whole discussion of re-distribution is almost a moot because we
 can just treat a content element like any other element that gets
 distributed along with its distributed nodes.


 x-button can select.
 You might want to take a look at the distribution algorithm [1], where
 the behavior is well defined.


 I know we can in the current spec but should we support it?  What are
 concrete use cases in which x-button or other components need to select
 nodes in nested shadow DOM case?

 - R. Niwa

Re: Inheritance Model for Shadow DOM Revisited

2015-04-27 Thread Hayato Ito

I'm aware that our consensus is to defer this until v2. Don't worry. :)

The feature of shadow as function supports *subclassing*. That's
exactly the motivation I've introduced it once in the spec (and implemented
it in blink).
I think Jan Miksovsky, co-author of Apple's proposal, knows well that.

The reason I reverted it from the spec (and the blink), [1], is a technical
difficulty to implement, though I've not proved that it's impossible to
implement.

[1] https://codereview.chromium.org/137993003

On Tue, Apr 28, 2015 at 1:33 PM Ryosuke Niwa rn...@apple.com wrote:

Note: Our current 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 everything in a unified
way using a single tree of trees, without bringing yet another complexity
such as multiple templates.

Please see
https://github.com/w3c/webcomponents/wiki/Multiple-Shadow-Roots-as-%22a-Shadow-Root-hosts-another-Shadow-Root%22

That's a great mental model for multiple generations of shadow DOM but it
doesn't solve any of the problems with API itself. Like I've repeatedly
stated in the past, the problem is the order of transclusion. Quoting from
[1],

The `shadow` element is optimized for wrapping a base class, not filling
it in. In practice, no subclass ever wants to wrap their base class with
additional user interface elements. A subclass is a specialization of a
base class, and specialization of UI generally means adding specialized
elements in the middle of a component, not wrapping new elements outside
some inherited core.

In the three component libraries [1] described above, the only cases where
a subclass uses `shadow` is if the subclass wants to add additional
styling. That is, a subclass wants to override base class styling, and can
do so via:

```
template
stylesubclass styles go here/style
shadow/shadow
/template
```

One rare exception is `core-menu` [3], which does add some components in a
wrapper around a `shadow`. However, even in that case, the components in
question are instances of `core-a11y-keys`, a component which defines
keyboard shortcuts. That is, the component is not using this wrapper
ability to add visible user interface elements, so the general point stands.

As with the above point, the fact that no practical component has need for
this ability to wrap an older shadow tree suggests the design is solving a
problem that does not, in fact, exist in practice.

[1]
https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution
[2] Polymer’s core- elements, Polymer’s paper- elements, and the Basic Web
Components’ collection of basic- elements
[3]
https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FPolymer%2Fcore-menu%2Fblob%2Fmaster%2Fcore-menu.htmlsa=Dsntz=1usg=AFQjCNH0Rv14ENbplb6VYWFh8CsfVo9m_A

- R. Niwa

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 multiple templates.

Please see
https://github.com/w3c/webcomponents/wiki/Multiple-Shadow-Roots-as-%22a-Shadow-Root-hosts-another-Shadow-Root%22




On Tue, Apr 28, 2015 at 12:51 PM Ryosuke Niwa rn...@apple.com wrote:


  On Apr 27, 2015, at 12:25 AM, Justin Fagnani justinfagn...@google.com
 wrote:
 
  On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren ann...@annevk.nl
 wrote:
  On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa rn...@apple.com wrote:
   If we wanted to allow non-direct child descendent (e.g. grand child
 node) of
   the host to be distributed, then we'd also need O(m) algorithm where
 m is
   the number of under the host element.  It might be okay to carry on
 the
   current restraint that only direct child of shadow host can be
 distributed
   into insertion points but I can't think of a good reason as to why
 such a
   restriction is desirable.
 
  The main reason is that you know that only a direct parent of a node can
 distribute it. Otherwise any ancestor could distribute a node, and in
 addition to probably being confusing and fragile, you have to define who
 wins when multiple ancestors try to.
 
  There are cases where you really want to group element logically by one
 tree structure and visually by another, like tabs. I think an alternative
 approach to distributing arbitrary descendants would be to see if nodes can
 cooperate on distribution so that a node could pass its direct children to
 another node's insertion point. The direct child restriction would still be
 there, so you always know who's responsible, but you can get the same
 effect as distributing descendants for a cooperating sets of elements.

 That's an interesting approach. Ted and I discussed this design, and it
 seems workable with Anne's `distribute` callback approach (= the second
 approach in my proposal).

 Conceptually, we ask each child of a shadow host the list of distributable
 node for under that child (including itself). For normal node without a
 shadow root, it'll simply itself along with all the distribution candidates
 returned by its children. For a node with a shadow root, we ask its
 implementation. The recursive algorithm can be written as follows in pseudo
 code:

 ```
 NodeList distributionList(Node n):
   if n has shadowRoot:
 return ask n the list of distributable noes under n (1)
   else:
 list = [n]
 for each child in n:
   list += distributionList(n)
 return list
 ```

 Now, if we adopted `distribute` callback approach, one obvious mechanism
 to do (1) is to call `distribute` on n and return whatever it didn't
 distribute as a list. Another obvious approach is to simply return [n] to
 avoid the mess of n later deciding to distribute a new node.

  So you mean that we'd turn distributionList into a subtree? I.e. you
  can pass all descendants of a host element to add()? I remember Yehuda
  making the point that this was desirable to him.
 
  The other thing I would like to explore is what an API would look like
  that does the subclassing as well. Even though we deferred that to v2
  I got the impression talking to some folks after the meeting that
  there might be more common ground than I thought.
 
  I really don't think the platform needs to do anything to support
 subclassing since it can be done so easily at the library level now that
 multiple generations of shadow roots are gone. As long as a subclass and
 base class can cooperate to produce a single shadow root with insertion
 points, the platform doesn't need to know how they did it.

 I think we should eventually add native declarative inheritance support
 for all of this.

 One thing that worries me about the `distribute` callback approach (a.k.a.
 Anne's approach) is that it bakes distribution algorithm into the platform
 without us having thoroughly studied how subclassing will be done upfront.

 Mozilla tried to solve this problem with XBS, and they seem to think what
 they have isn't really great. Google has spent multiple years working on
 this problem but they come around to say their solution, multiple
 generations of shadow DOM, may not be as great as they thought it would be.
 Given that, I'm quite terrified of making the same mistake in spec'ing how
 distribution works and later regretting it.

 In that regard, the first approach w/o distribution has an advantage of
 letting Web developer experiment with the bare minimum and try out which
 distribution algorithms and mechanisms work best.

 - R. Niwa

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 icon) {
  this.text = text;
  this.button = new XButton(icon);
  ...
}

Here, |icon| is *re-distributed*.

In HTML world, this corresponds the followings:

The usage of x-component element:
  x-components
x-textHello World/x-text
x-iconMy Icon/x-icon
  /x-component

XComponent's shadow tree is:

  shadow-root
h1content select=x-text/content/h1
x-buttoncontent select=x-icon/content/x-button
  /shadow-root

Re-distribution enables the constructor of X-Component to pass the given
parameter to other component's constructor, XButton's constructor.
If we don't have a re-distribution, XComponents can't create X-Button using
the dynamic information.

XComponents::XCompoennts(Title text, Icon icon) {
  this.text = text;
  // this.button = new xbutton(icon);  // We can't!  We don't have
redistribution!
  this.button = new xbutton(icon.png);  // XComponet have to do
hard-coding. Please allow me to pass |icon| to x-button!
  ...
}


On Sun, Apr 26, 2015 at 12:23 PM Olli Pettay o...@pettay.fi wrote:

 On 04/25/2015 01:58 PM, Ryosuke Niwa wrote:
 
  On Apr 25, 2015, at 1:17 PM, Olli Pettay o...@pettay.fi wrote:
 
  On 04/25/2015 09:28 AM, Anne van Kesteren wrote:
  On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com
 wrote:
  In today's F2F, I've got an action item to come up with a concrete
 workable proposal for imperative API.  I had a great chat about this
  afterwards with various people who attended F2F and here's a
 summary.  I'll continue to work with Dimitri  Erik to work out details in
 the
  coming months (our deadline is July 13th).
 
  https://gist.github.com/rniwa/2f14588926e1a11c65d3
 
  I thought we came up with something somewhat simpler that didn't
 require adding an event or adding remove() for that matter:
 
  https://gist.github.com/annevk/e9e61801fcfb251389ef
 
 
  That is pretty much exactly how I was thinking the imperative API to
 work. (well, assuming errors in the example fixed)
 
  An example explaining how this all works in case of nested shadow trees
 would be good. I assume the more nested shadow tree just may get some
  nodes, which were already distributed, in the distributionList.
 
  Right, that was the design we discussed.
 
  How does the distribute() behave? Does it end up invoking distribution
 in all the nested shadow roots or only in the callee?
 
  Yes, that's the only reason we need distribute() in the first place.  If
 we didn't have to care about redistribution, simply exposing methods to
  insert/remove distributed nodes on content element is sufficient.
 
  Should distribute callback be called automatically at the end of the
 microtask if there has been relevant[1] DOM mutations since the last manual
  call to distribute()? That would make the API a bit simpler to use, if
 one wouldn't have to use MutationObservers.
 
  That's a possibility.  It could be an option to specify as well.  But
 there might be components that are not interested in updating distributed
  nodes for the sake of performance for example.  I'm not certain forcing
 everyone to always update distributed nodes is necessarily desirable given
  the lack of experience with an imperative API for distributing nodes.
 
  [1] Assuming we want to distribute only direct children, then any child
 list change or any attribute change in the children might cause
  distribution() automatically.
 
  I think that's a big if now that we've gotten rid of select attribute
 and multiple generations of shadow DOM.

 It is not clear to me at all how you would handle the case when a node has
 several ancestors with shadow trees, and each of those want to distribute
 the node to some insertion point.
 Also, what is the use case to distribute non-direct descendants?




   As far as I could recall, one of
  the reasons we only supported distributing direct children was so that
 we could implement select attribute and multiple generations of shadow
  DOM.   If we wanted, we could always impose such a restriction in a
 declarative syntax and inheritance mechanism we add in v2 since those v2
 APIs
  are supposed to build on top of this imperative API.
 
  Another big if is whether we even need to let each shadow DOM select
 nodes to redistribute.  If we don't need to support filtering distributed
  nodes in insertion points for re-distribution (i.e. we either distribute
 everything under a given content element or nothing), then we don't need
  all of this redistribution mechanism baked into the browser and the
 model where we just have insert/remove on content element will work.
 
  - R. Niwa

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 :host is a pseudo-class rather than a
  pseudo-element. My mental model of a pseudo-class is that it allows
  you to match an element based on a boolean internal slot of that
  element. :host is not that since e.g. * does not match :host as I
  understand it. That seems super weird. Why not just use ::host?
 
  Copying WebApps since this affects everyone caring about Shadow DOM.
 
 

 My guess is it's because a shadow host element is an element, not a
 pseudo-element.

 The reason * doesn't match :host is because the host element, in the
 context of its shadow tree, is featureless, as mentioned in [1]section
 3.1.1 of css-scoping and [2]section 3.3 of selectors-4.

 Does the following note in css-scoping 3.1.1 answer your question?

  Why is the shadow host so weird?
 
  The shadow host lives outside the shadow tree, and its markup is in
  control of the page author, not the component author.
 
  It would not be very good if a component used a particular class name
  internally in a shadow tree, and the page author using the component
  accidentally also used the the same class name and put it on the host
  element. Such a situation would result in accidental styling that is
  impossible for the component author to predict, and confusing for the
  page author to debug.
 
  However, there are still some reasonable use-cases for letting a
  stylesheet in a shadow tree style its host element. So, to allow this
  situation but prevent accidental styling, the host element appears
  but is completely featureless and unselectable except through :host.

 [1]: http://dev.w3.org/csswg/css-scoping-1/#host-element-in-tree
 [2]: http://dev.w3.org/csswg/selectors-4/#data-model

 --
 Daniel Tan
 NOVALISTIC
 http://NOVALISTIC.com

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 Sat, Apr 25, 2015 at 9:32 AM Anne van Kesteren ann...@annevk.nl wrote:

 On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com wrote:
  In today's F2F, I've got an action item to come up with a concrete
 workable
  proposal for imperative API.  I had a great chat about this afterwards
 with
  various people who attended F2F and here's a summary.  I'll continue to
 work
  with Dimitri  Erik to work out details in the coming months (our
 deadline
  is July 13th).
 
  https://gist.github.com/rniwa/2f14588926e1a11c65d3

 I thought we came up with something somewhat simpler that didn't
 require adding an event or adding remove() for that matter:

   https://gist.github.com/annevk/e9e61801fcfb251389ef

 I added an example there that shows how you could implement content
 select, it's rather trivial with the matches() API. I think you can
 derive any other use case easily from that example, though I'm willing
 to help guide people through others if it is unclear. I guess we might
 still want positional insertion as a convenience though the above
 seems to be all you need primitive-wise.


 --
 https://annevankesteren.nl/

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

2015-04-25 Thread Hayato Ito

Thanks. I am really glad to see more and more guys are thinking about
Shadow DOM.
I know distribution/re-distributions is a tough issue. A lot of exciting
things are waiting for you. :)

On Sat, Apr 25, 2015 at 10:19 AM Ryosuke Niwa rn...@apple.com wrote:

 Sure, I'll put the summary of discussion 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 not fan of the discussion being
 scattered. :)

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


 On Sat, Apr 25, 2015 at 9:32 AM Anne van Kesteren ann...@annevk.nl
 wrote:

 On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa rn...@apple.com wrote:
  In today's F2F, I've got an action item to come up with a concrete
 workable
  proposal for imperative API.  I had a great chat about this afterwards
 with
  various people who attended F2F and here's a summary.  I'll continue to
 work
  with Dimitri  Erik to work out details in the coming months (our
 deadline
  is July 13th).
 
  https://gist.github.com/rniwa/2f14588926e1a11c65d3

 I thought we came up with something somewhat simpler that didn't
 require adding an event or adding remove() for that matter:

   https://gist.github.com/annevk/e9e61801fcfb251389ef

 I added an example there that shows how you could implement content
 select, it's rather trivial with the matches() API. I think you can
 derive any other use case easily from that example, though I'm willing
 to help guide people through others if it is unclear. I guess we might
 still want positional insertion as a convenience though the above
 seems to be all you need primitive-wise.


 --
 https://annevankesteren.nl/

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) equivalent power, I guess the
technical difficulties to implement these features don't differ so much.
If we could implement the new proposal, I think we could implement
shadow as function too.



On Wed, Apr 22, 2015 at 3:56 PM Dimitri Glazkov dglaz...@google.com wrote:

 FWIW, I can see the appeal of a slot-based approach in Ryosuke/Ted/Jan
 proposal.

 It reduces the implementation complexity: all of the selector-checking
 logic in
 http://w3c.github.io/webcomponents/spec/shadow/#satisfying-matching-criteria
 is replaced with (what effectively is) a map lookup.

 While some loss of flexibility is a cost, I think it's worth considering
 this trade-off, especially if it is a sticking point for implementers who
 are looking to reduce the overall cost of Shadow DOM implementation.

 In fact, if we reach cross-vendor agreement and decide to go with the
 slot-based approach, we probably should avoid adding extra sugar around
 element names and attribute values as slot indicators, and instead double
 down on developing a good imperative API that overcomes the loss of
 flexibility.

 :DG

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 optimization, isn't?

I don't have a strong opinion on this. I'd like to hear more feedbacks from
web developers who is making real world UI, like Firefox UI, Firefox OS and
so on.

Currently, most of the features are *hard-coded* in the spec and users
can't customize at all. The concept of Closed Shadow Trees is the first
way to customize the feature set, however it still provides a pre-defined
features set.

In summary: (You might want to see the following in monospaced font)

   Open  Closed
Event Retargeting for a node in:
 xx
Deny DOM access, such as element.shadowRoot(), into shadow trees:
 x
CSS property values inherits into:
 xx
CSS selector doesn't piece into shadow trees:
xx
Special Shadow DOM CSS selector doesn't piece into shadow trees:
  x
Filtering a node in event.path() if they are in:
  x   (This is not spec-ed yet)
Filtering a node in element.getDestinationInsertionPoints() if they are in:
 x
..and so on


For example, in the past, event.path() filtered out a node if it's in an
(open) shadow tree, however, I changed it because developers gave us the
feedback that they want to see a node even if it's in a shadow tree.

I expect that the same thing would happen again. It might be difficult for
us to provide a pre-defined set of features which satisfies all
requirements.

Currently, we're going to have two pre-defined sets, open and closed.
Can this two sets satisfy all requirements? I'm not sure.

Other comments inlined,




On Wed, Apr 8, 2015 at 3:20 PM Anne van Kesteren ann...@annevk.nl wrote:

 We have done some brainstorming internally around what we want out of
 Shadow DOM and components in general, between those working on Gaia
 (Firefox OS applications) and those working on Platform (Gecko). We
 hope to be able to discuss this at the meeting later this month and
 also at the Extensible Web Summit that precedes it. And of course on
 this list, happy to answer any questions.

 For custom elements https://wiki.whatwg.org/wiki/Custom_Elements is
 still an accurate summary of where we are at. For shadow DOM I wrote
 this summary:

 * Layout containment. We hope that evolving
 http://dev.w3.org/csswg/css-containment/ further could allow for some
 interesting optimizations and hopefully something akin to element
 queries or a resize event down the road. (This is basically a feature
 of iframe that components lack.)

 * Declarative shadow DOM. Mostly for performance it would be nice if
 the composed tree could be serialized and cached. That way first
 render only requires HTML and CSS with JavaScript kicking in at the
 end. We reasoned it might not be too hard to add something like
 shadowroot given our experience with template. The only difference
 would be that shadowroot itself would also not be appended to the
 tree and that the DocumentFragment nee ShadowRoot is associated with
 its parent.


I agree. Declarative shadow DOM is a really nice feature. That would make
my life easier. I don't need to write JS to construct a tree of trees in
writing a test casually.

What's more important is that we can serialize/deserialize a tree of trees
by declarative syntax. For example, unless custom elements are used, users
can't copy and paste a piece of the page which uses Shadow DOM. Users will
lose Shadow DOM through copy/paste.


 * Isolated shadow DOM. This is the idea of having a DOM worker so
 that instead of ten iframes with ten globals you can have one global
 with ten somethings. This would give applications more parallelization
 opportunities and would hopefully enable a large number of companies
 from moving away of the practice of using cross-origin script with
 all its security implications.

 * Imperative distribution (C). Distribution can already be observed in
 many ways through events and selectors. As a first step we should
 probably define more precisely when it happens in terms of the event
 loop. And then make it imperative. (I was a bit surprised with the
 thread that seemed to conclude at
 https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0423.html
 as Ryosuke's proposal seemed like a good minimal API to do this.)

 * Making event retargeting opt-in/out (D). I think opt-in (or only
 with isolated) would be better and perhaps if the API needs to change
 anyway we can do that, but we could probably live with opt-out as
 well. When you use shadow DOM to compose, global reasoning about state
 and events is a fairly established pattern that we should enable.

 * Closed-but-no-sigar (B, E). We're not sure about closed shadow DOM.
 With composition/layout you want scripts to be able to go in and out.
 (See also event

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:
- https://www.w3.org/Bugs/Public/show_bug.cgi?id=23620
- https://www.w3.org/Bugs/Public/show_bug.cgi?id=27569

I think it's coincidence, but I added the following note to the spec
yesterday to make the spec reader-friendly.
-
https://github.com/w3c/webcomponents/commit/b43d98149c4c4a401fe35e115afc548031bdbc6d

It might be also worth mentioning that you can use
ShadowRoot.getElementById in a non-normative way there. Strictly speaking,
we don't have to mention it in the spec because it's implied.

On Fri, Mar 27, 2015 at 5:44 AM Elliott Sprehn espr...@chromium.org wrote:

On Thu, Mar 26, 2015 at 1:38 PM, Ryosuke Niwa rn...@apple.com wrote:

On Mar 26, 2015, at 1:23 PM, Travis Leithead
travis.leith...@microsoft.com wrote:

You make a series of excellent points.

In the sense that you have a new set of nodes to manage holistically,
then having some sort of “document” container does makes sense for that (a
ShadowRoot) in order to place all your search/navigation APIs.

You got me thinking though—getElementById is currently not available on
ShadowRoot right? Does that API in the host’s document find IDs in the
shadow? I presume not given the guidelines you mentioned. I wonder what
other APIs from Document are desired?

I thought getElementById existed in ShadowRoot at some point but the
latest Blink code doesn't have it. It looks like Blink has
querySelector/querySelectorAll via ParentNode:

https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/shadow/ShadowRoot.idl

https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/ParentNode.idl

The spec changed,
https://dom.spec.whatwg.org/#interface-nonelementparentnode

ShadowRoot is a DocumentFragment and DocumentFragment implements
NonElementParentNode.

- E

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 features?

 http://caniuse.com/#feat=style-scoped

 In suggesting @isolate declaration, I meant it would go inside a scoped
 style element. If there are nested scope style elements and each have
 @isolate then it means that the styles don't bleed from parent with scoped
 style to child with scoped style if child has @isolate

 The big question is why was scoped style element removed from Chrome 37's
 experimental flags?

 Just curious.



 On Mon, Jan 12, 2015 at 6:27 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Jan 12, 2015, at 6:11 PM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:
 
  On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa rn...@apple.com wrote:
  On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:
  [ryosuke, your mail client keeps producing flattened replies. maybe
  send as plain-text, not HTML?]
 
  Weird.  I'm not seeing that at all on my end.
 
  It's sending HTML-quoted stuff, which doesn't survive the flattening
  to plain-text that I and a lot of others do.  Plain-text is more
  interoperable.
 
  The style defined for bar *in bar's setup code* (that is, in a
  style contained inside bar's shadow tree) works automatically
  without you having to care about what bar is doing.  bar is like a
  replaced element - it has its own rendering, and you can generally
  just leave it alone to do its thing.
 
  If that's the behavior we want, then we should simply make @isolate
 pierce through isolates.  You previously mentioned that:
 
  On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:
  Alternately, say that it does work - the @isolate selector pierces
  through isolation boundaries.  Then you're still screwed, because if
  the outer page wants to isolate .example blocks, but within your
  component you use .example normally, without any isolation, whoops!
  Suddenly your .example blocks are isolated, too, and getting weird
  styles applied to them, while your own styles break since they can't
  cross the unexpected boundary.
 
  But this same problem seems to exist in shadow DOM as well.  We can't
 have a bar inside a foo behave differently from ones outside foo
 since all bar elements share the same implementation.  I agree
 
  Yes!  But pay attention to precisely what I said: it's problematic to,
  for example, have a command to isolate all class=example elements
  pierce through isolation boundaries, because classes aren't expected
  to be unique in a page between components - it's very likely that
  you'll accidentally hit elements that aren't supposed to be isolated.
  It's okay to have *element name* isolations pierce, though, because we
  expect all elements with a given tagname to be the same kind of thing
  (and Web Components in general is built on this assumption; we don't
  scope the tagnames in any way).

 I don't want to go too much on a tangent but it seems like this is a
 dangerous assumption to make once components start depending on different
 versions (e.g. v1 versus v2) of other components.  Also, it's not hard to
 imagine authors may end up defining custom elements of the same name to be
 used in their own components.  If someone else then pulls in those two
 components, one of them will be broken.

 To solve a dependency problem like this, we need a real dependency
 resolution mechanism for components.

  But then we're not actually providing selectors to the isolate
  mechanism, we're just providing tagnames, and having that affect the
  global registry of tagnames.

 I don't think having a global registry of tag names is a sufficient nor a
 necessary mechanism to address the issue at hand.  As such, I'm not
 suggesting or supporting that.

 - R. Niwa

[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 [4]
- Attribute inheritance for shadow trees [5]

[1] http://www.w3.org/TR/2014/WD-shadow-dom-20140617/
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365
[4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26033
[5] spec bug is not filed. Chrome's bug is here:
https://code.google.com/p/chromium/issues/detail?id=420772


On Wed Oct 22 2014 at 9:02:02 PM Arthur Barstow art.bars...@gmail.com
wrote:

 On 10/11/14 10:43 AM, Arthur Barstow wrote:
  If you are an Editor and you did not register for the meeting please
  note:
 
  a) If you can join the meeting via the teleconf bridge, please: 1) add
  your spec to the Potential Topics list and identify high priority
  discussion points; 2) plan to dial-in Monday morning (or let me know
  which open day + time slot you prefer to join the meeting).
 
  b) If you cannot remotely participate in the meeting, please provide a
  short status of your spec, including any major blocking issues as well
  as general plans and expectations for the next six months (including
  publications plans). Please start a separate thread and use your
  spec's short name as the Subject: prefix (f.ex. [html-imports] Oct
  2014 status report and plans).
 
  Here is the list of specs whose Editor(s) did not register for the
  meeting (if I made any mistakes, I apologize in advance, but please do
  let me know):
 
  * Custom Elements: Dimitri.
 
  * HTML Imports: Hajime and Dimitri.
 
  * Shadow DOM: Hayato and Dimitri.


 Dimitri, Hajime, Hayato,

 Please see the above and respond accordingly, for your respective specs.

 -Thanks, ArtB


  [Agenda] https://www.w3.org/wiki/Webapps/November2014Meetin

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 same node tree.
 
  For example, suppose a form element is in the node tree A. In this
  case, form elements in node tree B,  where A != B,  are not considered
  at all when submitting the form.

 I am not sure I am able to fully interpret your response: do you imply
 that an input field inside a shadow dom inside a form

 (diagram:

 form
 |
[shadow root]
 |
   input

 )

 shall get submitted?


No, the input is not considered.


 This might pose some backwards incompatibility for tools that
 automatically aggregate input values (for e.g. xhr-based submit) by
 executing form.querySelectorAll(input, select, textarea). An input
 inside a shadow root (not visible to a querySelectorAll from the outside
 world) will get ommited.


This sounds an orthogonal problem, doesn't that?
querlySelectorAll() can't select nodes in other node trees in any cases.




 Sincerely,
 O. Zara


 
  A composed tree shouldn't have any effect on submitting a from.
 
  2) I am having troubles with lifecycle callback of custom elements
 that
  are cloned from within a template element. More specifically, nor
  createdCallback nor attachedCallback are fired when an element in
  question is cloned from template.content or appended to an active
  document. Is this a specified behavior? How do I properly initialize
  custom elements that live inside a template ?
 
 
  Thanks a lot,
  sincerely,
  Ondrej Zara
 
 
 
 
  --
  *RNDr. Ondřej Žára*
  Programátor UI senior
 
  https://twitter.com/0ndras
  ondrej.z...@firma.seznam.cz mailto:ondrej.z...@firma.seznam.cz
  mailto:ondrej.zara@firma.__seznam.cz
  mailto:ondrej.z...@firma.seznam.cz
  http://www.seznam.cz/
 
  Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5
  http://mapy.cz/s/6rw4
 
 

 --
 *RNDr. Ondřej Žára*
 Programátor UI senior

 https://twitter.com/0ndras
 ondrej.z...@firma.seznam.cz mailto:ondrej.z...@firma.seznam.cz
 http://www.seznam.cz/

 Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5 http://mapy.cz/s/6rw4

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 doesn't say anything about this. Therefore,
  form elements should be in the same node tree.
 
  For example, suppose a form element is in the node tree A. In this
  case, form elements in node tree B,  where A != B,  are not considered
  at all when submitting the form.

 I am not sure I am able to fully interpret your response: do you imply
 that an input field inside a shadow dom inside a form

 (diagram:

 form
 |
[shadow root]
 |
   input

 )

 shall get submitted?


 No, the input is not considered.


 This might pose some backwards incompatibility for tools that
 automatically aggregate input values (for e.g. xhr-based submit) by
 executing form.querySelectorAll(input, select, textarea). An input
 inside a shadow root (not visible to a querySelectorAll from the outside
 world) will get ommited.


 This sounds an orthogonal problem, doesn't that?
 querlySelectorAll() can't select nodes in other node trees in any cases.


Correction.
If we use `/deep/` (or  `::shadow') in the selector, we can. :)






 Sincerely,
 O. Zara


 
  A composed tree shouldn't have any effect on submitting a from.
 
  2) I am having troubles with lifecycle callback of custom elements
 that
  are cloned from within a template element. More specifically, nor
  createdCallback nor attachedCallback are fired when an element in
  question is cloned from template.content or appended to an active
  document. Is this a specified behavior? How do I properly initialize
  custom elements that live inside a template ?
 
 
  Thanks a lot,
  sincerely,
  Ondrej Zara
 
 
 
 
  --
  *RNDr. Ondřej Žára*
  Programátor UI senior
 
  https://twitter.com/0ndras
  ondrej.z...@firma.seznam.cz mailto:ondrej.z...@firma.seznam.cz
  mailto:ondrej.zara@firma.__seznam.cz
  mailto:ondrej.z...@firma.seznam.cz
  http://www.seznam.cz/
 
  Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5
  http://mapy.cz/s/6rw4
 
 

 --
 *RNDr. Ondřej Žára*
 Programátor UI senior

 https://twitter.com/0ndras
 ondrej.z...@firma.seznam.cz mailto:ondrej.z...@firma.seznam.cz
 http://www.seznam.cz/

 Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5 http://mapy.cz/s/6rw4

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?


The Shadow DOM spec doesn't say anything about this. Therefore,
form elements should be in the same node tree.

For example, suppose a form element is in the node tree A. In this case,
form elements in node tree B,  where A != B,  are not considered at all
when submitting the form.

A composed tree shouldn't have any effect on submitting a from.


 2) I am having troubles with lifecycle callback of custom elements that
 are cloned from within a template element. More specifically, nor
 createdCallback nor attachedCallback are fired when an element in
 question is cloned from template.content or appended to an active
 document. Is this a specified behavior? How do I properly initialize
 custom elements that live inside a template ?


 Thanks a lot,
 sincerely,
 Ondrej Zara




 --
 *RNDr. Ondřej Žára*
 Programátor UI senior

 https://twitter.com/0ndras
 ondrej.z...@firma.seznam.cz mailto:ondrej.z...@firma.seznam.cz
 http://www.seznam.cz/

 Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5 http://mapy.cz/s/6rw4

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 you live with those short qualifications/clarifications?
 
  Definitely; I see the concern and am glad you caught that.

 Yeah, sounds good.  I've added an issue to Bikeshed
 https://github.com/tabatkins/bikeshed/issues/174 to address this.

 ~TJ




-- 
Hayato

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 my-webkitten-card:

  shadow
span class=nameWebKitten/span
content/content
span class=emailkit...@webkit.org/span
  /shadow

doesn't make sense here. That would be equivalent with a
shadow/shadow.

Does it have any affect for your proposal?



On Thu, Apr 17, 2014 at 6:43 PM, Ryosuke Niwa rn...@apple.com wrote:

 Sorry, I forgot to add [Shadow DOM] in the title.

 On Apr 17, 2014, at 2:42 AM, Ryosuke Niwa rn...@apple.com wrote:

 *Review: Template Inheritance in the Current Specification*

 In the current specification, a super class doesn't define any hooks for
 subclasses.  Instead, it defines insertion points into which nodes from the
 original DOM (light DOM) is inserted, and then subclasses use shadow
 element to replace elements that get distributed into superclass's
 insertion points.

 Consider my-card element used as follows:
   my-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@apple.com/span
   /my-card

 Suppose this element's shadow DOM looks like this:
 Name: content select=.name/content
 Email: content select=.email/content

 Then in the composed tree, the first span is distributed into the first
 content element and the second span is distributed into the second content
 element as follows:
   my-card
 !-- shadow root begin --
 Name: content select=.name
   !-- distribution begin --
   span class=nameRyosuke Niwa/span
   !-- distribution end --
 /content
 Email: content select=.email
   !-- distribution begin --
   span class=emailrn...@apple.com/span
   !-- distribution end --
   /content
 !-- shadow root end --
   /my-card

 If I had my-webkitten-card that always as WebKitten as a name that
 inherits from my-card, its shadow DOM may look like this:
   shadow
 span class=nameWebKitten/span
 content/content
 span class=emailkit...@webkit.org/span
   /shadow

 If I had an instance of my-webkitten-card as follows:
   my-webkitten-card
   span class=nameRyosuke Niwa/span
   span class=emailrn...@webkit.org/span
   /my-webkitten-card

 Then its composed tree will look like this:
   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
   shadow
   !-- my-card's shadow root begin --
   Name: content select=.name
 !-- distribution begin --
 span class=nameWebKitten/span
 span class=nameRyosuke Niwa/span
 !-- distribution end --
   /content
   Email: content select=.email
 !-- distribution begin --
 span class=emailrn...@webkit.org/span
 span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card

 Here, my-card's shadow DOM was inserted into where the shadow element
 existed in my-webkitten-card's shadow DOM, and the insertion points inside
 my-card's shadow DOM got nodes distributed from shadow element's children
 including nodes inside content element.  If we didn't have the content
 element inside my-webkitten-card with name and email classes, then we
 would only see WebKitten and kit...@webkit.org distributed into my-card's
 insertion points as in:

   my-webkitten-card
 !-- my-webkitten-card's shadow root begin --
 shadow
   !-- my-card's shadow root begin --
   Name:
   content select=.name
 !-- distribution begin --
   span class=nameWebKitten/span
 !-- distribution end --
   /content
   Email:
   content select=.email
 !-- distribution begin --
   span class=emailkit...@webkit.org/span
 !-- distribution end --
   /content
   !-- my-card's shadow root end --
 /shadow
 !-- my-webkitten-card's shadow root end --
   /my-webkitten-card

 *Separating Transclusion Mechanisms for Inheritance and Data Binding*

 The current model mixes data binding and inheritance if we consider
 distributing nodes from the light DOM as a form of data binding.  Namely,
 distributing nodes from my-card's or my-webkitten-card's light DOM is data
 binding where the data model is DOM whereas distributing nodes from
 my-webkitten-card's shadow element into my-card's insertion points is an
 inheritance hook.

 Furthermore, the transclusion mechanism for inheritance happens backwards.
  Instead of a superclass defining a transclusion points for its subclasses
 to use, the subclasses are overriding the meaning of insertion points in
 the superclass by injecting nodes.  This is how existing JS libraries and
 frameworks do template inheritance.

 For example, the following two JS template libraries that support

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 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: 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 experimenting with Web Components and I have an issue,
 which I think I have represented fairly clear here:

 (Tested on Chrome)
 http://codepen.io/dbugger/pen/Hyihd

 If I understood correctly, one of the points of web components is to
 control the presentation of our component. That is why we have the Shadow
 Boundary. BUT what happens with the elements that are represented with
 content? They are not considered part of the shadow, therefore the styles
 that the author decides to apply on them, will invade the Web Component.

 Any thought on this?

 --
 Enrique Moreno Tent, Web developer
 http://enriquemorenotent.com




-- 
Hayato

[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: 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 had a similar
topic on blinkon conference (http://bit.ly/blinkon).

CC-ing yosin@, hoping he has the latest idea.



On Fri, Oct 18, 2013 at 2:24 PM, Hajime Morrita morr...@google.com wrote:

 B looks fine. We don't have to rush into the API addition though. The API
 is just a shortcut of a tree traversal and easy to polyfill. It won't too
 late to design this after hearing some concrete usecases.

 Also, we need to extend this rough idea to take reprojection (content
 and shadow) into account. I hope projection-proficient people like
 Dimitri and Hayato help to do that.


 On Fri, Oct 18, 2013 at 1:15 PM, Jonas Sicking jo...@sicking.cc wrote:


 On Oct 17, 2013 6:48 PM, Hajime Morrita morr...@google.com wrote:
 
 
 
 
  On Fri, Oct 18, 2013 at 3:56 AM, Jonas Sicking jo...@sicking.cc
 wrote:
 
  On Thu, Oct 17, 2013 at 1:55 AM, Hajime Morrita morr...@google.com
 wrote:
  
  
  
   On Thu, Oct 17, 2013 at 5:01 PM, Ryosuke Niwa rn...@apple.com
 wrote:
  
   On Oct 16, 2013, at 9:47 PM, Hajime Morrita morr...@google.com
 wrote:
  
   D. H[ello Shado]w World - selection spans outside to inside.
  
  
   Suppose we allowed this selection. Then how does one go about
 pasting this
   content elsewhere?
  
   Most likely, whatever other content editable area, mail client, or
 some
   random app (e.g. MS Word) into which the user is going to paste
 wouldn’t
   support shadow DOM and most certainly wouldn’t have the component
 the
   original page happened to have.
  
  
   We have to define how Range.cloneContents() or extractContents()
 works
   against shadow-selecting range, assuming selection is built on top
 of DOM
   Range. This doesn't seem that complicated. As cloned element drops
 its
   shadow, these range-generated nodes won't have shadow either.
 
  Oh, sounds like you are suggesting that we expand the Range API such
  that it can have awareness of spanning parts of a shadow DOM tree.
  While still keeping the existing endpoints in the same root?
 
  That like that idea!
 
 
  No, that isn't what I meant. I just want to make it explicit that Range
 API works well with shadow trees.
  However it happened to be taken by you in some interesting way, and I'm
 fine with this  ;-)
 
  So what does this mean?
 
  The subranges property exposes the selections of containing
 ShadowRoots? That sounds reasonable.
 
  Although I don't think Blink supports this in short term because it
 only has per-document selection and doesn't have per-tree ones,
  it is rather a lack of features which can be improved eventually than
 something totally incompatible and hurting the Web.
 
  Let me confirm what we're talking about.
 
  1. Each shadow tree has its own selection. Each selection spans nodes
 in the owning tree only.
  2. User initiated selection operation (like dragging) can operate
 multiple selections in different trees seamlessly
  as if it is single selection crossing boundaries.
  3. Range and/or Selection API could expose sub-selections/sub-ranges of
 containing trees.
 
  Going back to the example,
 
   C. H[ello Shadow Worl]d - selection stays outside shadow, but its
 range contains a node with shadow.
 
  This turns something like
 
  C2: H[ello (Shadow) Worl]d - There are two selections - [] for
 outside tree and () for inside tree.
 
  And this this one
 
   D. H[ello Shado]w World - selection spans outside to inside.
 
  turns
 
  D2: H[ello] (Shado)w World
 
  Is is correct?

 Yes!

 I think there are at least three ways we could expose these inner ranges:

 A) Separate function in the selection API for getting shadow ranges.
 B) Extension to the Range object for getting sub-shadow ranges.
 C) Through the existing multi-range support in the selection API.

 C has the advantage that no range or selection API changes are needed.
 But has the downside that it makes it messy to associate which ranges are
 subranges of other ranges.

 B has the advantage that it works anywhere where Range objects are used.
 But the downside is that it makes Ranges more complicated.

 A has the advantage that it keeps Ranges simple.

 I think I'm leaning towards B personally. I don't think the added
 complexity to Range objects is a big deal. Anywhere where Ranges are used
 you'd likely want to deal with shadow trees in one way or another.

 / Jonas




 --
 morrita




-- 
Hayato

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 of ShadowRoot.

Did you mean B?



On Wed, Oct 9, 2013 at 2:46 AM, Elliott Sprehn espr...@gmail.com wrote:

 Direct text children of ShadowRoot are full of sadness:

 1) You can't call getComputedStyle on them since that's only allowed for
 Elements, and the old trick of parentNode doesn't work since that's a
 ShadowRoot. ShadowRoot doesn't expose a host property so I can't get
 outside to find the host style that's inherited either. If the ShadowRoot
 has resetStyleInheritance set then the text uses a root default style,
 but I have no way to get that as well.

 2) There's no way to set the style of the Text. Normally I can do
 parentNode.style.color = ...; but since ShadowRoot has no style property I
 have no way to influence the text of the ShadowRoot without dynamically
 changing a style element.

 3) You can't use elementFromPoint(). It returns null since
 ShadowRoot.elementFromPoint should always return an element in that scope,
 but there is no element in that scope. This means you have no sensible way
 to do a hit test of the text in the shadow root.

 - E




-- 
Hayato

60 matches

Mail list logo