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

2016-01-06 Thread
On Wed, Jan 6, 2016 at 7:00 PM, Ryosuke Niwa <rn...@apple.com> wrote:

>
> > On Jan 6, 2016, at 12:05 AM, Takayoshi Kochi (河内 隆仁) <ko...@google.com>
> wrote:
> >
> > Is there any option to attend this remotely (telcon or video conference)?
> >
> > 2015年12月9日(水) 10:26 Ryosuke Niwa <rn...@apple.com>:
> >>
> >> > 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)

2016-01-06 Thread
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...

2015-10-29 Thread
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

2015-10-02 Thread
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: [shadow-dom] ::before/after on shadow hosts

2015-07-03 Thread
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 (河内 隆仁) ko...@google.com
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. jackalm...@gmail.com
 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: Better focus support for Shadow DOM

2015-07-02 Thread
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 (河内 隆仁) ko...@google.com
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 d...@domenic.me 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 custom-a) and the more
 complicated ones with a shadow DOM (like custom-input type=date). 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: [shadow-dom] ::before/after on shadow hosts

2015-07-02 Thread
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. jackalm...@gmail.com 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

2015-06-03 Thread
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 d...@domenic.me 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 custom-a) and the more
 complicated ones with a shadow DOM (like custom-input type=date). 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


Re: Better focus support for Shadow DOM

2015-02-25 Thread
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, cha...@yandex-team.ru 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 (河内 隆仁) ko...@google.com:

 [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 (河内 隆仁) 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



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

2015-02-18 Thread
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 (河内 隆仁) 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


Re: Better focus support for Shadow DOM

2015-01-20 Thread
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


Re: Better focus support for Shadow DOM

2015-01-16 Thread
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 (河内 隆仁) 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


Re: Better focus support for Shadow DOM

2015-01-14 Thread
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, cha...@yandex-team.ru 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 (河内 隆仁) ko...@google.com:

 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

2015-01-13 Thread
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

2014-10-06 Thread
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 ja...@foksa.name 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

2014-09-11 Thread
Ondrej,

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

The node tree mentioned in Hayato's mail means that form and input
belong to different trees.
Only elements in the same tree as form 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 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?

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





-- 
Takayoshi Kochi


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

2013-12-19 Thread
Hi,

On Thu, Dec 19, 2013 at 7:23 PM, Takayoshi Kochi (河内 隆仁)
ko...@google.comwrote:


 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
implementedhttp://msdn.microsoft.com/en-us/library/ie/dn433251(v=vs.85).aspxit
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

2013-12-05 Thread
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

2013-10-09 Thread
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 art.bars...@nokia.comwrote:

 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] 
 http://www.w3.org/2008/**webapps/wiki/PubStatushttp://www.w3.org/2008/webapps/wiki/PubStatus
 




-- 
Takayoshi Kochi


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

2013-08-20 Thread
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 jcr...@apple.com wrote:

 On Aug 16, 2013, at 5:44 AM, Arthur Barstow art.bars...@nokia.com 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] http://www.w3.org/2013/04/25-webapps-minutes.html#item12
 


 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

2013-05-28 Thread
+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.comjohannesw...@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

2013-05-02 Thread
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.

 ** **

 sequence DOMString   getCompositionAlternatives ();

 ** **

 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 

Re: Proposal for a DOM L3 Events Telecon

2013-05-01 Thread
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 w...@google.com wrote:

 Hi guys, mind if I tag along with Gary on the call?


 On 30 April 2013 13:46, Gary Kačmarčík (Кошмарчик) gary...@google.comwrote:

 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

2013-04-25 Thread
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.

 ** **

 sequence DOMString   getCompositionAlternatives ();

 ** **

 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 position. Therefore we are
 proposing getCandidateWindowClientRect together with a group of CSS
 properties to give more flexibility for 

Re: Feedback about W3C Input Method Editor API draft

2013-04-23 Thread
Hi James,

Thanks for the comments!
My replies inlined.


On Tue, Apr 23, 2013 at 5:35 PM, James Su su...@google.com 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 {

 InputMethodContexthttp://www.w3.org/TR/ime-api/#idl-def-InputMethodContext
 getInputContexthttp://www.w3.org/TR/ime-api/#widl-HTMLElement-getInputContext-InputMethodContext();
 };

 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  
 texthttp://www.w3.org/TR/2013/WD-ime-api-20130404/#widl-Composition-text
 ;
readonly attribute Range 
 carethttp://www.w3.org/TR/2013/WD-ime-api-20130404/#widl-Composition-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 sequenceRange segments so apps can render
the segmented composition during conversion properly.  What do you think?


 * 7. The InputMethodContext Interface

 interface InputMethodContext {
readonlyattribute 
 Compositionhttp://www.w3.org/TR/ime-api/#idl-def-Composition
 compositionhttp://www.w3.org/TR/ime-api/#widl-InputMethodContext-composition
 ;
attribute boolean 
 enabledhttp://www.w3.org/TR/ime-api/#widl-InputMethodContext-enabled
 ;
readonlyattribute DOMString   
 localehttp://www.w3.org/TR/ime-api/#widl-InputMethodContext-locale
 ;
void
 confirmCompositionhttp://www.w3.org/TR/ime-api/#widl-InputMethodContext-confirmComposition-void();
void
 setCaretRectanglehttp://www.w3.org/TR/ime-api/#widl-InputMethodContext-setCaretRectangle-void-Node-anchor-long-x-long-y-long-w-long-h(
 Node anchor, long x, long y, long w, long h);
void
 setExclusionRectanglehttp://www.w3.org/TR/ime-api/#widl-InputMethodContext-setExclusionRectangle-void-Node-anchor-long-x-long-y-long-w-long-h(
 Node anchor, long x, long y, long w, long h);
boolean 
 openhttp://www.w3.org/TR/ime-api/#widl-InputMethodContext-open-boolean();
 };

 Feedback:

 1. attribute boolean 
 enabledhttp://www.w3.org/TR/ime-api/#widl-InputMethodContext-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 
 elementhttp://www.w3.org/TR/html-markup/input.html#input.
 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   
 localehttp://www.w3.org/TR/ime-api/#widl-InputMethodContext-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
 confirmCompositionhttp://www.w3.org/TR/ime-api/#widl-InputMethodContext-confirmComposition-void();

 I suggest to change this method to 

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

2013-04-05 Thread
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 (河内 隆仁)
ko...@google.comwrote:

 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]

2013-03-19 Thread
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