Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

[河内 隆仁]

On Wed, Jan 6, 2016 at 7:00 PM, Ryosuke Niwa  wrote:

>
> > On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁) 
> wrote:
> >
> > Is there any option to attend this remotely (telcon or video conference)?
> >
> > 2015年12月9日(水) 10:26 Ryosuke Niwa :
> >>
> >> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
> >> >
> >> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
> >> >
> >> >> we are trying to shift the date of the Custom Elements meeting to
> *25* Jan, from the previously proposed date of 29th.
> >> >>
> >> >> We are currently looking for a host in the Bay area - offers
> gratefully received.
> >> >
> >> > Apple have kindly agreed to host the meeting, so it will be at 1
> Infinite Loop, Cupertino. I'll update the page shortly with logistics
> information.
> >> >
> >> > Note that if you are driving, you should allow an extra 10 minutes or
> so for parking. Carpool!
> >>
> >> Added logistics on
> >> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md
>
> The conference room has a video/telephone conference capability so we
> should be able to set up Webinars assuming someone from W3C can help us set
> it up.
>
>
Thanks!
Please update the logistics page if it is set up.


> - R. Niwa
>
>
-- 
Takayoshi Kochi

Re: Apple will host Re: Custom Elements meeting will be 25th Jan (not 29th)

[河内 隆仁]

Is there any option to attend this remotely (telcon or video conference)?

2015年12月9日(水) 10:26 Ryosuke Niwa :

>
> > On Dec 8, 2015, at 2:55 AM, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
> >
> > On Mon, 07 Dec 2015 13:39:25 +1000, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
> >
> >> we are trying to shift the date of the Custom Elements meeting to *25*
> Jan, from the previously proposed date of 29th.
> >>
> >> We are currently looking for a host in the Bay area - offers gratefully
> received.
> >
> > Apple have kindly agreed to host the meeting, so it will be at 1
> Infinite Loop, Cupertino. I'll update the page shortly with logistics
> information.
> >
> > Note that if you are driving, you should allow an extra 10 minutes or so
> for parking. Carpool!
>
> Added logistics on
> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/25janWC.md
>
> - R. Niwa
>
>
>

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

[河内 隆仁]

On Thu, Oct 29, 2015 at 3:04 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
>
>
In addition, I'd propose

+ Decide on style inheritance (
https://github.com/w3c/webcomponents/issues/314)



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


-- 
Takayoshi Kochi

Re: Tests for new shadow DOM API

[河内 隆仁]

Hi,

Thanks Ryosuke for starting contributing tests to shadow-dom/ and moving
the old ones under untriaged/.

I would like to continue triaging old tests in untriaged/ directory.
The general rule of thumb (for me) for working on them are:

- Remove tests that test out-of-date features (e.g. attributes that is
removed from spec)
- If the test is doing something valid, carefully examine what is tested
and whether it is not
  duplicate of other tests (outside of untriaged/*). If it is a duplicate,
remove it.
- If the test passes above 2 bullets, then rewrite so that the test runs in
more sane way and
  submit for review, and remove the original once the new test lands.

And I'm happy to review any new or triaged test, please add @TakayoshiKochi
in your pull request.

Thank you!

On Fri, Sep 4, 2015 at 5:13 PM, Ms2ger  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Ryosuke,
>
> On 09/03/2015 10:06 PM, Ryosuke Niwa wrote:
> > Hi all,
> >
> > Where should we put tests for new shadow DOM API?  It looks like
> > the tests in
> > https://github.com/w3c/web-platform-tests/tree/master/shadow-dom/shado
> w-trees
> >
> >
>  - -trees>
> > are mostly obsolete and I'm not certain how many of them could be
> > adopted for the new API.
> >
> > Would it make sense to rename this old one to
> > "deprecated-shadow-don" and then create a new top-level directory
> > "shadow-dom"?  We can then migrate or write new tests there.
> >
>
> If you believe a significant fraction of the existing tests is out of
> date with the specification, I'd suggest moving them all into
> `shadow-dom/untriaged` and adding a `README` file there to explain the
> situation.
>
> HTH
> Ms2ger
> -BEGIN PGP SIGNATURE-
>
> iQEcBAEBAgAGBQJV6VK2AAoJEOXgvIL+s8n2asAIAJEXWz8vyAGqPI6BFNNYQYXb
> 4i/knAt1/GEeiUOzjzbwJG38NRtGr9cZO0MCYW8S13gzzqKbtdCWwF0FbBvzvMR1
> OHqkdR7tLo/aLV00GQzrLSgNDnqQ2M1+P/lq5QUU53DsbpTM2Ih0P1pjDsvaLs75
> TZFggKN8UKhvjQrKuL1wjtCSKrdkemXKbdl2FfWgXj1hsUklNwKSmTd8Hr+g6FaS
> eK+l74G7xhxbqwKvIo8MgcLjwNYJG5hPJWoP6T9b9rBnE4W+x8J9ojcVVMuCWz/4
> 0GOGvgyRXwobDcKsAcBomNhTruOC8pqNVn6e84oScOyNf8QRP6GDjyj/a2jd71I=
> =Z5oS
> -END PGP SIGNATURE-
>
>


-- 
Takayoshi Kochi

Re: Tests for new shadow DOM API

[河内 隆仁]

Yeah, many of them are still relevant, and I'm working on removing/fixing
obsolete tests (but slowly :).

The most relevant change needed right now is renaming all
"createShadowRoot" to "attachShadow",
which is mechanical, and otherwise all shadow DOM tests are irrelevant ;)

These tests were written a long time ago, so there is definitely lack of
tests for the spec that is
added afterwards.  Some can be modified to adapt the new spec, but we
seriously need tests
for newly-added/modified spec in v1 (notably,  etc.).

So feel free to add new tests, but for existing ones, please leave as they
are, and I'll triage them.
If you are certain that any test is obsolete or irrelevant, please make a
pull request and ping me.




On Fri, Sep 4, 2015 at 5:21 AM, Ryosuke Niwa  wrote:

> I think many of them are still relevant.  The key problem I have at the
> moment is that I can't tell which ones are relevant and which ones aren't.
> So I wanted to create a new directory and migrate or delete the existing
> tests over time.
>
> On Sep 3, 2015, at 1:19 PM, Travis Leithead 
> wrote:
>
> Why not deprecate/remove the existing tests in the current folder
> structure? Presumably we can replace them with new tests that are aligned
> with the recent spec changes?
>
>
>
> If the existing tests really aren’t relevant anymore, I don’t see a reason
> to keep them around.
>
>
>
> *From:* rn...@apple.com [mailto:rn...@apple.com ]
> *Sent:* Thursday, September 3, 2015 1:07 PM
> *To:* public-webapps 
> *Subject:* Tests for new shadow DOM API
>
>
>
> Hi all,
>
>
>
> Where should we put tests for new shadow DOM API?  It looks like the tests
> in
> https://github.com/w3c/web-platform-tests/tree/master/shadow-dom/shadow-trees
> 
>  are
> mostly obsolete and I'm not certain how many of them could be adopted for
> the new API.
>
>
>
> Would it make sense to rename this old one to "deprecated-shadow-don" and
> then create a new top-level directory "shadow-dom"?  We can then migrate or
> write new tests there.
>
>
>
> - R. Niwa
>
>
>
>
>


-- 
Takayoshi Kochi

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

[河内 隆仁]

Oops, found that you were already there :)
https://code.google.com/p/chromium/issues/detail?id=393490#c15

On Fri, Jul 3, 2015 at 2:49 PM, Takayoshi Kochi (河内 隆仁) 
wrote:

> Sorry for coming late, but
>
> - crbug.com/393490 Before and After pseudo elements don't work in
> ShadowRoots (with :host styles)
> - crbug.com/393509 :host()::before or :host()::after should work
>
> have the relevant discussion about the current implementation in Blink
> (#2).
>
>
> On Thu, Jul 2, 2015 at 1:16 AM, Tab Atkins Jr. 
> wrote:
>
>> All right, sounds pretty unanimous that #2 (current behavior) is what
>> we should go with. I'll clarify the Scoping spec.  Thanks!
>>
>> ~TJ
>>
>>
>
>
> --
> Takayoshi Kochi
>



-- 
Takayoshi Kochi

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

[河内 隆仁]

Sorry for coming late, but

- crbug.com/393490 Before and After pseudo elements don't work in
ShadowRoots (with :host styles)
- crbug.com/393509 :host()::before or :host()::after should work

have the relevant discussion about the current implementation in Blink (#2).


On Thu, Jul 2, 2015 at 1:16 AM, Tab Atkins Jr.  wrote:

> All right, sounds pretty unanimous that #2 (current behavior) is what
> we should go with. I'll clarify the Scoping spec.  Thanks!
>
> ~TJ
>
>


-- 
Takayoshi Kochi

Re: Better focus support for Shadow DOM

[河内 隆仁]

Hi,

Changes for Blink have landed and now you can play this by enabling
"experimental web platform features"
in chrome://flags.

Now I am proposing this as a patch to shadow DOM, at
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/ShadowRoot-delegatesFocus-Proposal.md
Feel free to comment here, or at github issue tracker.

(The full version of the doc also moved to markdown format, at
https://github.com/TakayoshiKochi/tabindex-focus-navigation-explainer/blob/master/TabindexFocusNavigationExplainer.md
)


On Wed, Jun 3, 2015 at 4:47 PM, Takayoshi Kochi (河内 隆仁) 
wrote:

> Hi,
>
> (cross-posting mostly the same content to blink-...@chromium.org, sorry
> for duplication if you encounter this twice)
>
> With much feedback from many people, I've updated the design doc.
>
> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
> Thanks all who have shared thoughts and experience with me.
>
> The biggest change is that "tabStop" property on Element moved to
> ShadowRoot, as "delegatesFocus".
>
> After implementing the spec on Blink, I noticed that even tabStop property
> is
> on every Element, it has effect only on shadow hosts, which is very
> confusing.
> So delegatesFocus should make more clear sense on shadow hosts.
>
> With the new spec, delegatesFocus can be specified via ShadowRootInit
> dictionary,
> which is a parameter to createShadowRoot().
>
> I'll start making changes in Blink immediately.
>
> For reference, I copied a snapshot of old doc (Mar. 19):
>
> https://docs.google.com/document/d/1wFXrPYmoqb8-b-rfZdmcVfZt09NaTFyOLvGztdlIPxE/edit#
>
> Any comment is welcome.
>
> On Thu, Jan 22, 2015 at 6:38 AM, Domenic Denicola  wrote:
>
>>  Thanks Takoyoshi! This new version looks great to me. It would allow
>> people to create custom elements with the same focus capabilities as native
>> elements, including both the simple cases (like ) and the more
>> complicated ones with a shadow DOM (like ). Very
>> exciting stuff!
>>
>>
>>
>> I hope others are as enthused as I am :)
>>
>>
>>
>> *From:* Takayoshi Kochi (河内 隆仁) [mailto:ko...@google.com]
>> *Sent:* Wednesday, January 21, 2015 02:41
>> *To:* public-webapps
>> *Subject:* Re: Better focus support for Shadow DOM
>>
>>
>>
>> Hi,
>>
>>
>>
>> After conversation with Domenic Denicola, I changed the title and the
>> whole story of
>>
>> solving this issue, though the result is not quite different.  Instead of
>> adding "delegatesFocus"
>>
>> property, we added "isTabStop()" to expose "tab focusable flag" explained
>> in HTML5 spec.
>>
>>
>>
>>
>> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
>>
>>
>>
>> Any comments/suggestions welcome.
>>
>>
>>
>> On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) <
>> ko...@google.com> wrote:
>>
>>  Hi,
>>
>>
>>
>> For shadow DOMs which has multiple focusable fields under the host,
>>
>> the current behavior of tab navigation order gets somewhat weird
>>
>> when you want to specify tabindex explicitly.
>>
>>
>>
>> This is the doc to introduce a new attribute "delegatesFocus" to resolve
>> the issue.
>>
>>
>> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
>>
>>
>>
>> Any comments are welcome!
>>
>> --
>>
>> Takayoshi Kochi
>>
>>
>>
>>
>>
>> --
>>
>> Takayoshi Kochi
>>
>
>
>
> --
> Takayoshi Kochi
>



-- 
Takayoshi Kochi

Re: Better focus support for Shadow DOM

[河内 隆仁]

Hi,

(cross-posting mostly the same content to blink-...@chromium.org, sorry for
duplication if you encounter this twice)

With much feedback from many people, I've updated the design doc.
https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
Thanks all who have shared thoughts and experience with me.

The biggest change is that "tabStop" property on Element moved to
ShadowRoot, as "delegatesFocus".

After implementing the spec on Blink, I noticed that even tabStop property
is
on every Element, it has effect only on shadow hosts, which is very
confusing.
So delegatesFocus should make more clear sense on shadow hosts.

With the new spec, delegatesFocus can be specified via ShadowRootInit
dictionary,
which is a parameter to createShadowRoot().

I'll start making changes in Blink immediately.

For reference, I copied a snapshot of old doc (Mar. 19):
https://docs.google.com/document/d/1wFXrPYmoqb8-b-rfZdmcVfZt09NaTFyOLvGztdlIPxE/edit#

Any comment is welcome.

On Thu, Jan 22, 2015 at 6:38 AM, Domenic Denicola  wrote:

>  Thanks Takoyoshi! This new version looks great to me. It would allow
> people to create custom elements with the same focus capabilities as native
> elements, including both the simple cases (like ) and the more
> complicated ones with a shadow DOM (like ). Very
> exciting stuff!
>
>
>
> I hope others are as enthused as I am :)
>
>
>
> *From:* Takayoshi Kochi (河内 隆仁) [mailto:ko...@google.com]
> *Sent:* Wednesday, January 21, 2015 02:41
> *To:* public-webapps
> *Subject:* Re: Better focus support for Shadow DOM
>
>
>
> Hi,
>
>
>
> After conversation with Domenic Denicola, I changed the title and the
> whole story of
>
> solving this issue, though the result is not quite different.  Instead of
> adding "delegatesFocus"
>
> property, we added "isTabStop()" to expose "tab focusable flag" explained
> in HTML5 spec.
>
>
>
>
> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
>
>
>
> Any comments/suggestions welcome.
>
>
>
> On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) 
> wrote:
>
>  Hi,
>
>
>
> For shadow DOMs which has multiple focusable fields under the host,
>
> the current behavior of tab navigation order gets somewhat weird
>
> when you want to specify tabindex explicitly.
>
>
>
> This is the doc to introduce a new attribute "delegatesFocus" to resolve
> the issue.
>
>
> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
>
>
>
> Any comments are welcome!
>
> --
>
> Takayoshi Kochi
>
>
>
>
>
> --
>
> Takayoshi Kochi
>



-- 
Takayoshi Kochi

Re: Better focus support for Shadow DOM

[河内 隆仁]

Hi Chaals,

Thanks for the comment.
Honestly I'm not so familiar with ARIA/a11y requirements but the problem
sounds to apply Shadow DOMs overall,
not specific to the problem I'm trying to address here.  Do you have any
concrete cases that this (isTabStop feature et al.)
can regress or degenerate (or improve?) any a11y?

For issue 27965, I commented on it with an example.


On Thu, Feb 19, 2015 at 7:45 PM,  wrote:

> Hi,
>
> I noted the bugs, this thread, and the document in the HTML accessibility
> wiki where I am trying to collate stuff about focus navigation and similar
> keyboard access issues (in what might yet be a vain attempt to really
> improve the situation which is overall pretty dismal still):
> https://www.w3.org/WAI/PF/HTML/wiki/Keyboard
>
> 19.02.2015, 04:56, "Takayoshi Kochi (河内 隆仁)" :
>
> [Shadow]: Shadow host with tabindex=-1, all descendent tree should be
> ignored for tab navigation
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965
>
>
>
> I am not sure if this really is a problem (which might just be my brain
> going slowly). See my comment for more details, but it isn't clear to me
> that this needs to be fixed. On further reflection, I wonder if the point
> is where the author has explicitly marked tabindex="-1" - and how this
> relates to comound ARIA controls...
>
>
> cheers
>
>
> Focus on shadow host should slide to its inner focusable node
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=28054
>
> On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁)  > wrote:
>
> Hi,
>
> For shadow DOMs which has multiple focusable fields under the host,
> the current behavior of tab navigation order gets somewhat weird
> when you want to specify tabindex explicitly.
>
> This is the doc to introduce a new attribute "delegatesFocus" to resolve
> the issue.
>
> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
>
> Any comments are welcome!
> --
> Takayoshi Kochi
>
>
>
>
> --
> Takayoshi Kochi
>
>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> cha...@yandex-team.ru - - - Find more at http://yandex.com
>
>



-- 
Takayoshi Kochi

Re: Better focus support for Shadow DOM

[河内 隆仁]

Hi,

Thanks for the feedback from you all.

During the discussion on the feedback, I've filed a couple of bugs.
Any comments are welcome.

[Shadow]: Shadow host with tabindex=-1, all descendent tree should be
ignored for tab navigation
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27965

Focus on shadow host should slide to its inner focusable node
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28054

On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) 
wrote:

> Hi,
>
> For shadow DOMs which has multiple focusable fields under the host,
> the current behavior of tab navigation order gets somewhat weird
> when you want to specify tabindex explicitly.
>
> This is the doc to introduce a new attribute "delegatesFocus" to resolve
> the issue.
>
> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
>
> Any comments are welcome!
> --
> Takayoshi Kochi
>



-- 
Takayoshi Kochi

Re: Better focus support for Shadow DOM

[河内 隆仁]

Hi,

After conversation with Domenic Denicola, I changed the title and the whole
story of
solving this issue, though the result is not quite different.  Instead of
adding "delegatesFocus"
property, we added "isTabStop()" to expose "tab focusable flag" explained
in HTML5 spec.

https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing

Any comments/suggestions welcome.

On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) 
wrote:

> Hi,
>
> For shadow DOMs which has multiple focusable fields under the host,
> the current behavior of tab navigation order gets somewhat weird
> when you want to specify tabindex explicitly.
>
> This is the doc to introduce a new attribute "delegatesFocus" to resolve
> the issue.
>
> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
>
> Any comments are welcome!
> --
> Takayoshi Kochi
>



-- 
Takayoshi Kochi

Re: Better focus support for Shadow DOM

[河内 隆仁]

Thanks for those who gave me the first round of comments on the document.

I'm now rewriting many parts of the document for suggestions by Domenic,
so it also applies to regular HTML elements behavior.
During the rewrite, the document will be updated real time - which means
the doc is inconsistent.

Once it finishes, I'll post the updates.


On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) 
wrote:

> Hi,
>
> For shadow DOMs which has multiple focusable fields under the host,
> the current behavior of tab navigation order gets somewhat weird
> when you want to specify tabindex explicitly.
>
> This is the doc to introduce a new attribute "delegatesFocus" to resolve
> the issue.
>
> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
>
> Any comments are welcome!
> --
> Takayoshi Kochi
>



-- 
Takayoshi Kochi

Re: Better focus support for Shadow DOM

[河内 隆仁]

Hi Chaals,

Thanks for the pointers.

I was not aware that positive tabindex value is being deprecated, but
anyway it should make sense
when tabindex=0 specified on the shadow host. And as it has not been
completely deprecated,
it should be okay to keep the document as is, but I will add some comments
or pointer.

For aria-activedescendant, I was not aware either, do you think it still
make sense when the
real active descendant is in a shadow tree (i.e. the host and the active
element live in different scope)?
(added public-html-a11y to cc)


On Wed, Jan 14, 2015 at 6:28 PM,  wrote:

> Hi,
>
> please consider how thi relates to the management of
> "aria-active-descendant" and why we should not be working to bring the two
> of these in line.
>
> Note also that in HTML there is a proposal to deprecate (and hopefully one
> day abandon) tabindex with positive values, in favour of something less
> painful than forcing the user to press tab a zillion times as the way to
> get around an app. The HTML accessibility task force is currently looking
> at these issues for HTML, and it would be good to align the work.
>
> There is a question of where it makes more sense to have the conversation,
> but for the moment it is on public-html-a...@w3.org and on their wiki -
> listed as accesskey for increasingly irrelevant historical reasons
> http://www.w3.org/WAI/PF/HTML/wiki/51wishlist
>
> cheers
>
> Chaals
>
> 14.01.2015, 08:30, "Takayoshi Kochi (河内 隆仁)" :
>
> Hi,
>
> For shadow DOMs which has multiple focusable fields under the host,
> the current behavior of tab navigation order gets somewhat weird
> when you want to specify tabindex explicitly.
>
> This is the doc to introduce a new attribute "delegatesFocus" to resolve
> the issue.
>
> https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing
>
> Any comments are welcome!
> --
> Takayoshi Kochi
>
>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> cha...@yandex-team.ru - - - Find more at http://yandex.com
>
>



-- 
Takayoshi Kochi

Better focus support for Shadow DOM

[河内 隆仁]

Hi,

For shadow DOMs which has multiple focusable fields under the host,
the current behavior of tab navigation order gets somewhat weird
when you want to specify tabindex explicitly.

This is the doc to introduce a new attribute "delegatesFocus" to resolve
the issue.
https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing

Any comments are welcome!
-- 
Takayoshi Kochi

Re: [Custom]: Rename "createdCallback" to "created"

[河内 隆仁]

Hi Jarek,

What I learned from people around me is that these names have "Callback"
suffixes because
- to indicate that it is for a callback function and not a callable API
- it is low-level API and had to use non-trivial name

So even it doesn't seem to add any information, the suffix has some meaning
by existing there.

I'm concerned about what you said about "inconsistent with the rest of the
Web Platform".
What are examples of the rest?

On Thu, Oct 2, 2014 at 3:09 AM, Jarek Foksa  wrote:

> Custom elements spec defines following lifycycle callbacks:
>
> - createdCallback()
> - attachedCallback()
> - detachedCallback()
> - attributeChangedCallback()
>
> I'm wondering what was the reasoning behind the naming convention used
> here, it feels verbose and inconsistent with the rest of the Web Platform.
> Even Polymer authors, which I thought were also contributing to the spec,
> decided to drop the "callback" postfix.
>
> The postfix doesn't add any additional information. If method name states
> what has happened (“created”, “attached”) rather than what should happen
> (“create”, “attach”) then it’s obvious that such method is a callback.
>
>


-- 
Takayoshi Kochi

Re: Web Components: two questions

[河内 隆仁]

Ondrej,

The short answer to whether  inside shadow root under a  will
be sent or not is "No".

The "node tree" mentioned in Hayato's mail means that  and 
belong to different trees.
Only elements in the same tree as  will be considered for submission.

So you don't have to worry about backward compatibility.


On Thu, Sep 11, 2014 at 3:24 PM, Ondřej Žára 
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  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  field inside a shadow dom inside a 
>
> (diagram:
>
> 
>|
>   [shadow root]
>|
>  
>
> )
>
> shall get submitted?
>
> 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.
>
>
> 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  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  ?
>>
>>
>> Thanks a lot,
>> sincerely,
>> Ondrej Zara
>>
>>
>>
>>
>> --
>> *RNDr. Ondřej Žára*
>> Programátor UI senior
>>
>> https://twitter.com/0ndras
>> ondrej.z...@firma.seznam.cz 
>> > >
>> http://www.seznam.cz/
>>
>> Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5
>> 
>>
>>
>>
> --
> *RNDr. Ondřej Žára*
> Programátor UI senior
>
> https://twitter.com/0ndras
> ondrej.z...@firma.seznam.cz 
> http://www.seznam.cz/
>
> Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5 
>
>
>


-- 
Takayoshi Kochi

Re: [IME API]Some Insights from Chinese Input Methods

[河内 隆仁]

Hi,

On Thu, Dec 19, 2013 at 7:23 PM, Takayoshi Kochi (河内 隆仁)
wrote:

>
>> FYI, this is (still) being discussed at
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22018
> And your suggestion is almost same as the reason Microsoft people proposed
> this.
>
> One of the issue blocking this is a privacy issue, which may leak a
> personalized dictionary
> (user-defined dictionary or history).
>

For the suggestion use case for using getCompositionAlternatives(), I'm
still not really convinced that
it could be useful.  As Microsoft
implemented<http://msdn.microsoft.com/en-us/library/ie/dn433251(v=vs.85).aspx>it
in IE11, I'd be interested if it improved quality of
Bing suggestion :)

One reason is that for suggestion use case is that it is questionable that
giving alternate candidates
will yield better suggestions in general.  A simple case like yours (sogou
-> 搜狗) may look working
very well, though.

As the area for the suggestion is usually very limited, a suggestion
provider should give *really* probable
candidates for users.  So usually if composition has candidates, at best
only top one or two could be *good*
for hinting suggestions, when they are sorted by relevancy.

I'd wish there were an API that exposes relevancy/confidence/whatever score
for each candidate
for the composition, which an IME should have internally, then it could be
useful for this use case.
E.g. you can imagine a case where there are 4 candidates, and their scores
are all even (25, 25, 25, 25) or
the top has a very high score (96, 2, 1, 1).  It is less likely that the
former yields better suggestion than the latter,
if a suggestion provider picks the top candidate.  If a suggestion provider
can get such information,
it can even drop any suggestions for the all-even case, as it may not be
sufficient input for generating
suggestions.

One solution for this which can be possible today is to have IME on the
server side, and
browsers send 'raw' text (before conversion) to the server, then server can
interact with its local
IME and retrieve such score information.  Then getCompositionAlternatives()
is unnecessary.


The other reason is that it is questionable that how much such suggestions
could save users'
typing (or time).  For the reason above, unless a suggestion provider can
give really probable
suggestions, users won't get any benefit, or worse, users just get visual
noise for distraction.

For saving typing, IMEs should provide candidates as early as possible, by
predicting
user's typing.  For example, when you type 's' and IME could provide '搜狗'
as a candidate, then
suggestion provider might be able to show suggestions that 搜狗 provides - it
would be awesome,
if it were user's intention.  But 's' or 'so'  is usually too short to give
a specific candidate.  I
tested with plain MS pinyin on windows8, after typing 'sog', "搜狗" was 2nd
after "送给".
If the user typed "搜狗" in the past and IME can suggest it with only 's' -
it is nice, but
it implies privacy concern if such history is exposed to the web.

For Japanese, typically Japanese IMEs have 2 modes during composition, one
for
typing composition text (in romanized form to compose reading in
'Hiragana') and
then the other for converting the reading into Kanji and Kana mixed text.
 IMEs
can provide candidate suggestions during the first mode, but (although this
is implementation dependent) some IMEs cannot expose such suggestions to
applications on Windows (e.g. Google Japanese Input).  For suggestions use
case,
such suggestions would be more valuable, but not available technically.
 Once
a user starts conversion after having typed reading, then candidates become
available,
but it may be too late for this use case.


It got a bit long but this is my current thought about the usefulness of
getCompositionAlternatives()
for suggestion use case.  Overall,my gut feeling is that it works only on
some cases,
but will not work well on most cases.

I'd appreciate you have counter examples :)

Thanks!
-- 
Takayoshi Kochi

Updating Input Method Editor API working draft

[河内 隆仁]

Hi all,

Since the last working draft in August, IME API editor's draft has been
changed
significantly with the result of discussions at TPAC 2013.  The biggest
change
is that I split the previous spec into 2 parts, streamlined main part and
others, so the main part
which has been mostly agreed on can make smoother progress on
standardization track.

See below for detailed changes.

I would like to push this version to publish a new working draft.
Here's the current cut of editor's draft:
https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html
(to be specific,
https://dvcs.w3.org/hg/ime-api/raw-file/771d75e4e177/Overview.html)

(and log https://dvcs.w3.org/hg/ime-api/log)

Any comments are welcome.


=
Here are highlights of the changes since the last working draft (20130815):

* Split the draft into main and annex
  To get the standardization process smoother, only core APIs are left in
  the main draft and the following parts are pushed to the annex for further
  discussions or refinements:
  - Drawing IME candidates in Javascript
* CompositionEvent interface extension (segment information etc.)
* setCaretRectangle() API
  - Delivering IME related events to non-editable elements
  - confirmComposition() (not used for overlapping UI usecase)
  - locale (further refinement required)

* Example/use cases/best practices
- Modified example1 code (suggest UI) to use the new candidatewindow events.
- Fixed some ReSpec warnings (no visible change).

* API
[CORE]
- Added oncandidatewindow{show,update,hide} events and
  getCandidateWindowClientRect(), as proposed by Microsoft [1],
  except
  * isCandidateWindowVisible() is omitted due to redundancy.
  * mentions about synchronousness are dropped due to consideration for
implementability on non-Windows platform.
(although this does not mean discouraging synchronous implementation.)
- Added compositionStartOffset/compositionEndOffset to InputMethodContext,
  as proposed by Microsoft [1] [4].

[ANNEX]
- Removed setExclusionRectangle in favor of using
  candidatewindow{show,update,hide} events.
- Added enableEditingEvents()/disableEditingEvents(), for getting events
  delivered to non-editable elements.  Removed a sentence about HTML5
inputmode
  attribute for getting events.[3]
- Renamed selection{Start,end} to activeSegment{Start,End} as a result of
the
  discussion at [4].
- Merge Composition interface into D3E CompositionEvent.
  This makes sense as whenever any content or state of composition changes,
  a CompositionEvent is fired, and it avoids any consistency issue between
  composition events and the content of Composition.

[1] Microsoft proposal:
  https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html
[2] Comment from James Su
  http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0361.html
[3] Adding a method to deliver editing-related events to a DOM element
  https://www.w3.org/Bugs/Public/show_bug.cgi?id=23422
[4] Composition dictionary should be changed
  https://www.w3.org/Bugs/Public/show_bug.cgi?id=22059


Thanks in advance,

-- 
Takayoshi Kochi

Re: [ime-api] Seeking status and plans

[河内 隆仁]

Hi Arthur,

Thanks for the coordination.
The status of IME API in the PubStatus page is correct.

I will make some modification to Editor's draft soon, taking some of what
Microsoft proposed [1],
and some clarification about event delivery.
If possible, I hope we can get live feedback on the TPAC session.

[1] https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html


On Thu, Oct 3, 2013 at 1:30 AM, Arthur Barstow wrote:

> Hi Takayoshi and Kenji,
>
> If any of the data for the IME spec in [PubStatus] is not accurate, please
> provide corrections.
>
> Also, if you have any new information re your plans for the spec, or the
> spec's status with respect to being feature complete, implementation
> status, etc. please let us know.
>
> -Thanks, ArtB
>
> [PubStatus] 
> 
> >
>



-- 
Takayoshi Kochi

Re: [ime-api] Re: FYI: new WD of Input Method Editor API published

[河内 隆仁]

Hi James,

Thanks for the comment.

Let me confirm I understand your comment.
The suggestion list which is rendered in your comment, is not for custom
rendering of
suggestions from IME, but those from a web service (e.g. Google Suggest).
So the intention of that example is a use of setExclusionRectangle() to
give IME hint
about where the web suggestion region is rendered, and let IME try to avoid
that
region if it wants to show any UI element overlapping that area otherwise.

It would be nice if platforms (OSX, Windows, Linux...) provide ways to
* tell IME to suppress showing UI elements (especially suggestion UI during
composition)
* get signals from IME whenever it shows/hides any UI element (and
cancelable, if possible)
but there are no platform APIs in common.

I haven't explored accessibility feature on OSX, but does it provide any of
the above?
As far as I know NSTextInputClient does not provide them.



On Sat, Aug 17, 2013 at 3:39 AM, James Craig  wrote:

> On Aug 16, 2013, at 5:44 AM, Arthur Barstow  wrote:
>
> > You may recall WebApps and PFWG discussed WebApps' Input Method Editor
> API last April ([Mins]). As such, I wanted to let you know a new WD of that
> spec was published on August 15: <
> http://www.w3.org/TR/2013/WD-ime-api-20130815/>
> >
> > If you have any comments, please send them to the public-webapps @
> w3.org list.
> >
> > -Regards, ArtB
> >
> > [Mins] 
> >
>
>
> This draft is much improved, but I still have one concern:
>
> This code sample makes it clear you intend to do custom rendering of the
> suggestions list…
>
> > // Render new suggeston list.
> > for (i = 0; i < candidates.length; i++) {
> > suggest.appendChild(document.createElement('li'));
> > suggest.childNodes[i].textContent = candidates[i];
> > }
>
> But it's not apparent to me how you're alerting the user agent to avoid
> rendering the native candidate suggestions. It's also not clear to me how,
> depending on user preference, the user agent would respond to let the web
> application know that custom rendering is not allowed in this context or
> for this user.
>
> I'd expect something like this conditional to confirm with the UA that
> it's okay for the web app to do custom rendering of the candidates.
>
> // check with the UA to see if web app can render custom suggestions list
> if (target.inputMethodContext.preventDefaultRendering()) {
> // Render new suggeston list.
> for (i = 0; i < candidates.length; i++) {
>suggest.appendChild(document.createElement('li'));
>suggest.childNodes[i].textContent = candidates[i];
> }
> } // else custom rendering is disallowed by the UA
>
>
>
>
>
>


-- 
Takayoshi Kochi

Re: [editing] nested contenteditable

[河内 隆仁]

+Ryosuke - he is actively working on editing in WebKit.


On Wed, May 29, 2013 at 2:27 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  As far as I know, there is no actively maintained editing spec at the
> moment. Aryeh’s document is a great start but by no means should it be
> considered complete, or the standard to which you should target an
> implementation… I think we would [currently] prefer to discuss specific
> issues here on the mailing list until a regular editor can be found—so
> thanks for bringing this up!
>
> ** **
>
> By the way, what you suggest sounds reasonable for the behavior.
>
> ** **
>
> *From:* johannesw...@gmail.com 
> [mailto:johannesw...@gmail.com]
> *On Behalf Of *Johannes Wilm
> *Sent:* Tuesday, May 28, 2013 6:36 AM
> *To:* public-webapps@w3.org; ro...@w3.org; Alex Mogilevsky; Travis
> Leithead; a...@aryeh.name; yo...@chromium.org
> *Subject:* [editing] nested contenteditable
>
> ** **
>
> Hey,
>
> is there any progress on finding out who is to maintain this spec:
> https://dvcs.w3.org/hg/editing/raw-file/tip/editing.htm ? Is Aryeh still
> a fulltime student?
>
> ** **
>
> There is an effort at Chromium to make deletion of non-editable
> subelements work according to the spec, but the spec doesn't seem to
> anything about this. 
>
> ** **
>
> See: https://code.google.com/p/chromium/issues/detail?id=238000
> 
>
> ** **
>
> ** **
>
> Who could we ask to get the sepcification updated with information about
> this? 
>
> ** **
>
> Our current suggestion is that backspacing/deleting into it selects it,
> and a second hit on backspace/delete will remove it. The most important to
> me though is to have clarity on this.
>
> ** **
>
> ** **
>
> -- 
>
> Johannes Wilm
>
> Fidus Writer
>
> http://www.fiduswriter.com
>



-- 
Takayoshi Kochi

Re: [IME] Preparing some feedback

[河内 隆仁]

Hi Travis,

Before getting into details, is it appropriate to discuss CSS properties
(ime-*) and HTML attribute (inputmode) here?

At least, I think I should not incorporate CSS/HTML spec into the IME API
spec, as they are already in the separate specs
and duplication will make lots of issues.


On Thu, Apr 25, 2013 at 3:41 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  Kenji, et al.:
>
> ** **
>
> We appreciate the work you’ve put into this IME API spec so far and hope
> that this feedback will help further improve it! Jianfeng Lin, another
> program manager from the IE team put the following feedback together, as
> well as drafted the proposal, which I’ve uploaded to the mercurial server
> for easy viewing at:
> https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html.
> The proposal contains API designs that are the result of various feedback
> from several different teams inside of Microsoft including use cases from
> Microsoft Japan team, and designs from the folks who work on the in-box
> Windows IMEs and the IME integration layer inside Internet Explorer.
>
> ** **
>
> Thanks for taking the time to review,
>
> -Travis
>
> ** **
>
> Some Points of feedback:
>
> ** **
>
> Composition Dictionary
>
> ** **
>
> dictionary Composition {
>
> readonly attribute Nodetext;
>
> readonly attribute Range   caret;
>
> };
>
> ** **
>
> We can see exposing IME clauses as child nodes of “text” node, and making
> them real DOM nodes with styles being useful for a JS-based IME as the IME
> needs to tell the web application how to render the composition, but if JS
> IME is not a goal, is there any other scenarios that will benefit from
> this? If not, how about a simple design that expose the text being composed
> as DOMString?
>
> ** **
>
> For “caret” attribute, if it’s for enabling JS-based IME, then exposing
> the caret ranges of IME clauses is helpful, but if it’s not for JS IME, is
> there any other usage? We understand that web applications want to know
> about the whole string of the tentative composition, but we are not sure in
> which case they want to know how the whole tentative composition string is
> divided into several parts. Another issue is that the range type only tells
> the start and end offsets of the composition from its immediate parent. Web
> application usually wants to know the offset from the beginning of the text
> field so that it could combine the composition alternate with the text
> before it to create a full text string. But the beginning of the text field
> can be up in the parent tree if it’s a contentEditable element and requires
> JavaScript code to trace up in the parent tree to get the right offset. **
> **
>
> ** **
>
> So instead of a dictionary type for composition, we suggest this directly
> under InputMethodContext interface. Please let us know if you have
> scenarios that need to be the other way.
>
> ** **
>
> readonly attribute DOMStringcompositionText;
>
> readonly attribute unsigned long   compositionStartOffset;
>
> readonly attribute unsigned long   compositionEndOffset;
>
> ** **
>
> Beyond that, we also propose exposing the composition alternatives. For
> example a search engine can use the current non-committed alternatives to
> fine tune the real-time search suggestion list.
>
> ** **
>
> sequencegetCompositionAlternatives ();
>
> ** **
>
> For the following in your proposal, is there any usage scenario besides
> enabling IME on non-editable elements like canvas? 
>
> ** **
>
>  attribute boolean   enabled;
>
>  void   setCaretRectangle (Node anchor, long x, long y, long w, long
> h); 
>
>  boolean   open ();
>
> ** **
>
> As we raised in the following discussion threads before, we don’t think
> using canvas to create an editor is the right way to go. Please let’s
> discuss about issues you are trying to solve and find out a better solution.
> 
>
> http://lists.w3.org/Archives/Public/public-html/2011Nov/0210 
>
> http://lists.w3.org/Archives/Public/public-html/2011Dec/0157.html 
>
> http://lists.w3.org/Archives/Public/public-canvas-api/2012JanMar/0029.html
> 
>
> ** **
>
> For the following function
>
> ** **
>
>  void   setExclusionRectangle (Node anchor, long x, long y, long w,
> long h); 
>
> ** **
>
> We recommend replacing with this 
>
> ** **
>
>  ClientRect   getCandidateWindowClientRect ();
>
> ** **
>
> Because although setExclusionRectangle can ensure that the IME candidate
> window doesn't overlap with some specific UI that the web application
> doesn't want to be occluded (e.g. search suggestion list), it doesn’t seem
> to be able to ensure that the two UIs layout in a desirable way. For
> example, if the web application wants to render a search suggestion list
> that docks below the IME candidate window and aligns nicely without gap, it
> can't do so w

Re: Proposal for a DOM L3 Events Telecon

[河内 隆仁]

If Masayuki-san is joining and the time is JST-friendly, I would also like
to join,
but feel free to ignore me if not.


On Wed, May 1, 2013 at 6:30 PM, Wez  wrote:

> Hi guys, mind if I tag along with Gary on the call?
>
>
> On 30 April 2013 13:46, Gary Kačmarčík (Кошмарчик) wrote:
>
>> On Mon, Apr 29, 2013 at 12:59 PM, Travis Leithead <
>> travis.leith...@microsoft.com> wrote:
>>
>>>  I’d like to propose we start a call to begin to work toward resolving
>>> the final bugs in the spec and for other business related to getting DOM L3
>>> Events to CR. On the call we can workout what subsequent meetings we should
>>> also arrange.
>>>
>>> ** **
>>>
>>> Does next Tuesday (May 7th), at 11 am PST work your you?
>>>
>>
>> Note that 11am PDT = 3am JST.  If Masayuki is interested in joining, we
>> should pick a late afternoon PDT time:
>>4pm PDT (Tue) = 8am JST (Wed)
>>5pm PDT (Tue) = 9am JST (Wed)
>>
>>
>


-- 
Takayoshi Kochi

Re: [IME] Preparing some feedback

[河内 隆仁]

Hi Travis,

Thanks for the detailed spec and comments!
I'll read it through and will post comments on them.


On Thu, Apr 25, 2013 at 3:41 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  Kenji, et al.:
>
> ** **
>
> We appreciate the work you’ve put into this IME API spec so far and hope
> that this feedback will help further improve it! Jianfeng Lin, another
> program manager from the IE team put the following feedback together, as
> well as drafted the proposal, which I’ve uploaded to the mercurial server
> for easy viewing at:
> https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html.
> The proposal contains API designs that are the result of various feedback
> from several different teams inside of Microsoft including use cases from
> Microsoft Japan team, and designs from the folks who work on the in-box
> Windows IMEs and the IME integration layer inside Internet Explorer.
>
> ** **
>
> Thanks for taking the time to review,
>
> -Travis
>
> ** **
>
> Some Points of feedback:
>
> ** **
>
> Composition Dictionary
>
> ** **
>
> dictionary Composition {
>
> readonly attribute Nodetext;
>
> readonly attribute Range   caret;
>
> };
>
> ** **
>
> We can see exposing IME clauses as child nodes of “text” node, and making
> them real DOM nodes with styles being useful for a JS-based IME as the IME
> needs to tell the web application how to render the composition, but if JS
> IME is not a goal, is there any other scenarios that will benefit from
> this? If not, how about a simple design that expose the text being composed
> as DOMString?
>
> ** **
>
> For “caret” attribute, if it’s for enabling JS-based IME, then exposing
> the caret ranges of IME clauses is helpful, but if it’s not for JS IME, is
> there any other usage? We understand that web applications want to know
> about the whole string of the tentative composition, but we are not sure in
> which case they want to know how the whole tentative composition string is
> divided into several parts. Another issue is that the range type only tells
> the start and end offsets of the composition from its immediate parent. Web
> application usually wants to know the offset from the beginning of the text
> field so that it could combine the composition alternate with the text
> before it to create a full text string. But the beginning of the text field
> can be up in the parent tree if it’s a contentEditable element and requires
> JavaScript code to trace up in the parent tree to get the right offset. **
> **
>
> ** **
>
> So instead of a dictionary type for composition, we suggest this directly
> under InputMethodContext interface. Please let us know if you have
> scenarios that need to be the other way.
>
> ** **
>
> readonly attribute DOMStringcompositionText;
>
> readonly attribute unsigned long   compositionStartOffset;
>
> readonly attribute unsigned long   compositionEndOffset;
>
> ** **
>
> Beyond that, we also propose exposing the composition alternatives. For
> example a search engine can use the current non-committed alternatives to
> fine tune the real-time search suggestion list.
>
> ** **
>
> sequencegetCompositionAlternatives ();
>
> ** **
>
> For the following in your proposal, is there any usage scenario besides
> enabling IME on non-editable elements like canvas? 
>
> ** **
>
>  attribute boolean   enabled;
>
>  void   setCaretRectangle (Node anchor, long x, long y, long w, long
> h); 
>
>  boolean   open ();
>
> ** **
>
> As we raised in the following discussion threads before, we don’t think
> using canvas to create an editor is the right way to go. Please let’s
> discuss about issues you are trying to solve and find out a better solution.
> 
>
> http://lists.w3.org/Archives/Public/public-html/2011Nov/0210 
>
> http://lists.w3.org/Archives/Public/public-html/2011Dec/0157.html 
>
> http://lists.w3.org/Archives/Public/public-canvas-api/2012JanMar/0029.html
> 
>
> ** **
>
> For the following function
>
> ** **
>
>  void   setExclusionRectangle (Node anchor, long x, long y, long w,
> long h); 
>
> ** **
>
> We recommend replacing with this 
>
> ** **
>
>  ClientRect   getCandidateWindowClientRect ();
>
> ** **
>
> Because although setExclusionRectangle can ensure that the IME candidate
> window doesn't overlap with some specific UI that the web application
> doesn't want to be occluded (e.g. search suggestion list), it doesn’t seem
> to be able to ensure that the two UIs layout in a desirable way. For
> example, if the web application wants to render a search suggestion list
> that docks below the IME candidate window and aligns nicely without gap, it
> can't do so with setExclusionRectangle()  because it doesn't know where is
> the candidate window, how tall it is below the text field, and whether it
> is horizontally shifted to follow the caret pos

Re: Feedback about W3C Input Method Editor API draft

[河内 隆仁]

Hi James,

Thanks for the comments!
My replies inlined.


On Tue, Apr 23, 2013 at 5:35 PM, James Su  wrote:

> Hi all,
>   Please see below my initial feedback about *
> http://www.w3.org/TR/2013/WD-ime-api-20130404/.*
>
> * 5. The getInputContext() method
>
> partial interface HTMLElement {
>
> InputMethodContext
> getInputContext();
> };
>
> Feedback:
>
> 1. The name of the method and its return value type doesn’t match. Suggest
> to rename the method to getInputMethodContext().
>
> *
>

Certainly.  I'll change the spec.


> * 6. The Composition Dictionary
>
> dictionary Composition {
>readonly attribute Node  
> text
> ;
>readonly attribute Range 
> caret
> ;
> };
>
> Question: I’m wondering how should a web app render the styled text on a
> canvas? Can you provide an example code?
>
> Feedback: how about rename caret to selectedRange?
> *
>

As I wrote in
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0042.html
I agree with you that "Node text" is questionable and am wondering whether
it is
really useful for web developers who want to draw the composition by
themselves.

I also agree that caret can be renamed to selectedRange.  i.e. it is a
zero-width
position when user is composing and it can have width while user is
converting the composition.

I believe we would need sequence segments so apps can render
the segmented composition during conversion properly.  What do you think?


> * 7. The InputMethodContext Interface
>
> interface InputMethodContext {
>readonlyattribute 
> Composition
> composition
> ;
>attribute boolean 
> enabled
> ;
>readonlyattribute DOMString   
> locale
> ;
>void
> confirmComposition();
>void
> setCaretRectangle(
> Node anchor, long x, long y, long w, long h);
>void
> setExclusionRectangle(
> Node anchor, long x, long y, long w, long h);
>boolean 
> open();
> };
>
> Feedback:
>
> 1. attribute boolean 
> enabled
> ;
>
> Instead of using a boolean value to tell the system whether or not the IME
> should be enabled, I suggest to add a mechanism to tell the IME the
> supported input type of the current focused node, it may either be a
> DOMString attribute or a method like setInputType(DOMString type).
>
> The acceptable values of the input type can be a subset of the types
> defined for HTML Input 
> element.
> So that the browser can enable/disable the IME or maybe switch to a
> specific IME according to the input type. For example, if the web app wants
> to implement a password input box by itself, it can specify the input type
> to ‘password’, then the browser will switch the current IME to a special
> one suitable for inputting password. Setting the input type to ‘none’ or an
> empty value to disable the input method.
>
> *
>

The input types for input element is useful to determine whether to *turn
off* IME, but which one do you think
appropriate to turn on IME?  E.g. I think 'type=text' is neutral and the
user agent cannot guess the appropriate state.

So I think we still need an explicit way to turn on IME.

Also see comment for 4.open below.



> *
>
> 2. readonlyattribute DOMString   
> locale
> ;
>
> Having this attribute is good, but may not enough. We probably need a
> mechanism to notify the web app whenever the IME’s locale gets changed. For
> example, when the locale is changed from a LTR to a RTL one, the web app
> may want to adjust its text alignment and cursor position automatically.
>
> *
>

This is true, and I agree that the current locale information may be
insufficient for e.g. changing the
cursorposition upon changing input locale.  Probably another DOM event
should be added outside of
this spec's scope.

Fortunately or unfortunately, we already have the same locale in key, input
and composition events
so this spec also follows it.



> *
>
> 3. void
> confirmComposition

Re: Update of the IME API spec working draft [call for comments]

[河内 隆仁]

Hi all,

The updated IME API spec is now published as a second working draft at:
http://www.w3.org/TR/ime-api/ (Apr 04, 2013)

Thanks to Arthur for helping this published.
We are open to any feedback and comments.

In particular, I'd like to get feedback for some things:

1. Is composition dictionary sufficient/useful?

   The intention of the existence of this structure is to give more
information for composition text
   which is already available via D3E composition events.  The previous
version had some style
   information for the text, and after its publication the previous author
simplified it to have just
   "Node text" and "Range caret" following the feedback.

   A typical use case for this is to use it for drawing composition text
yourself, but for that case
   I suppose using Node and Range object sounds too generic.  If a web
application just
   want to use a simple [start, end) positions of caret for text, deriving
it from Node and Range
   object needs unnecessarily complex Javascript code to get these numbers.

   For Japanese use cases, we think plain composition text and vector of
[start, end) of char index in the text
   for each segment, and which segment is being converted - are probably
enough  (but to be honest,
   I am not sure there applies for Chinese, Korean and other languages).

   If the Node object contains style information that the user agent would
be using for drawing the text,
   it would be nice because the app can just put the node in DOM then it
would look identical
   as it is drawn by the user agent, but extracting e.g. segment
information from it would be very hard,
   as such style information is inevitably implementation dependent and
cannot be standardized.

2. Is "Caret" an appropriate name for APIs?

   The term "caret" is used in this API (in composition dicrionary and
setCaretRectangle() method) to mean
   some range in the composition text, but usually it is used for
zero-width vertical bar
   which indicates the position in the text that typed characters are
inserted.
   Probably we should have a better name for it.

On Tue, Mar 19, 2013 at 6:40 PM, Takayoshi Kochi (河内 隆仁)
wrote:

> Hi all,
>
> It's been a while since the last update for the IME API spec, but we
> restarted the work on this.
> I (Takayoshi Kochi) have taken over this authorship from the previous
> author (Hironori Bono)
> for updating the spec.
>
> If you are interested, please take a look at the current working draft:
> https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html
> (and log https://dvcs.w3.org/hg/ime-api/log)
>
> Any comments are welcome.
>
> Here are highlights of the changes since the last draft:
>
> * Removed Javascript IME from the spec.
>   (no compelling use case for this)
> * Added an API to hint IME UI positioning (setExclusionRectangle()).
>   (e.g. when showing autocomplete suggestions, IME UI may interfere with
> it)
> * Updated example Javascript code.
> * InputMethodContext interface changes
> * Simplified 'enabled' attribute
> * Simplified 'setOpenState()' to just 'open()' (as we don't have to
> turn off system IME
>   for Javascript IME)
> * Clarified what 'locale' attribute is expected, instead of 'source'
> which may sound like
>   User-Agent of IME.
>
> Thanks in advance,
> --
> Takayoshi Kochi
>



-- 
Takayoshi Kochi

Update of the IME API spec working draft [call for comments]

[河内 隆仁]

Hi all,

It's been a while since the last update for the IME API spec, but we
restarted the work on this.
I (Takayoshi Kochi) have taken over this authorship from the previous
author (Hironori Bono)
for updating the spec.

If you are interested, please take a look at the current working draft:
https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html
(and log https://dvcs.w3.org/hg/ime-api/log)

Any comments are welcome.

Here are highlights of the changes since the last draft:

* Removed Javascript IME from the spec.
  (no compelling use case for this)
* Added an API to hint IME UI positioning (setExclusionRectangle()).
  (e.g. when showing autocomplete suggestions, IME UI may interfere with it)
* Updated example Javascript code.
* InputMethodContext interface changes
* Simplified 'enabled' attribute
* Simplified 'setOpenState()' to just 'open()' (as we don't have to
turn off system IME
  for Javascript IME)
* Clarified what 'locale' attribute is expected, instead of 'source'
which may sound like
  User-Agent of IME.

Thanks in advance,
-- 
Takayoshi Kochi