Re: [selection-api] Moving toward First Public Working Draft

2014-09-26 Thread Kenji Baheux
Publishing an FPWD sounds reasonable.

On Sat, Sep 20, 2014 at 9:52 PM, Arthur Barstow art.bars...@gmail.com
wrote:

 Hi Ryosuke, Ben, Kenji, All,

 I'm looking for feedback about moving the Selection API [ED] to First
 Public Working Draft (FPWD) ...

 A `rule of thumb` I generally use when considering if a spec is ready for
 a FPWD is if the feature set is mostly complete although there is no
 expectation all features are fleshed out in detail (IOW, looking for
 breadth mostly complete but not depth). The breadth question is important
 because a FPWD is also used as an attorney snapshot vis-à-vis the [PP].
 Regarding the spec's open [Issues], there is no expectation a FPWD be
 bug/issue free (in fact, it would be rare if that was the case).

 What are your thoughts about publishing a FPWD? Do you consider the latest
 ED to be feature complete; and if not, what major features are missing?

 -Thanks, AB

 [ED] http://w3c.github.io/selection-api/
 [Issues] https://github.com/w3c/selection-api/issues
 [PP] http://www.w3.org/Consortium/Patent-Policy/




-- 
Kenji BAHEUX
Product Manager - Chrome
Google Japan


Re: [Editing] Splitting Selection API Into a Separate Specification

2014-03-13 Thread Kenji Baheux
Looking into selection in this brave new world (Shadow DOM for sure, but
there are issues as well with flexbox if I'm not mistaken), is definitely
something we are interested in.

We haven't gotten around it yet which I believe explain our lack of
feedback so far.


2014-03-14 8:43 GMT+09:00 Ryosuke Niwa rn...@apple.com:

 Hi,

 It appears that there is a lot of new features such as CSS regions and
 shadow DOM that have significant implications on selection API, and we
 really need a spec. for selection API these specifications can refer to.

 Thankfully, Aryeh has done a great work writing the spec. for selection
 API as a part of HTML Editing APIs specification [1] but no browser vendor
 has been able to give meaningful feedback or has implemented the spec due
 to the inherent complexity in HTML editing.  As a result, the specification
 hasn't made much progress towards reaching Last Call or CR.

 Given the situation, I think it's valuable to extract the parts of the
 spec that defines selection API into its own specification and move it
 forward in the standards process so that we can make it more interoperable
 between browsers, and let CSS regions, shadow DOM, and other specifications
 refer to the specification.

 Any thoughts and opinions?

 [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html

 - R. Niwa





Re: [IME] Preparing some feedback

2013-04-02 Thread Kenji Baheux
Thanks Travis.

We are eager to hear your feedback.
The spec was down scoped to exclude Javascript based IME because we could
not find any compelling use case but we would be happy to reconsider if you
do.


2013/3/30 Travis Leithead travis.leith...@microsoft.com

 Thanks for submitting these updates to the Input Method Editor API. I've
 had an opportunity to review them and would like to offer some feedback for
 the spec.

 On the IE team, we have also been working on building an IME-related API,
 but one geared specifically toward working with the operating system's IME
 (vs. a JavaScript-implemented IME). Long term, we think that it makes sense
 to have an IME API Spec that supports both system and JavaScript-based IME
 scenarios. We would like to work with you to land on a unified design that
 includes the right set of API for working with both system and
 JavaScript-based IMEs. We'll write up a proposal to start the discussion.

 Thanks,
 Travis




-- 
Kenji BAHEUX
Product Manager - Chrome
Google Japan


[IME API] Our plan to move the spec forward in light of our F2F discussion

2013-01-07 Thread Kenji Baheux
Happy new year!

At our last F2F, I gave examples of use cases that would benefit from
better interactions with IMEs and asked for the WG's opinion.

In light of the feedback (see minutes), we have decided to focus our effort
on the use case around positioning (e.g. avoiding the UX overlap issue that
typically occur between the IME candidates/UI and the webapp's
suggestions/UI).

We'll have an updated draft of the spec scoped down to this particular use
case by the end of January. Feel free to follow along and reach out with
any suggestions/questions you may have.

TPAC minutes: http://www.w3.org/2012/10/30-webapps-minutes.html#item04

Note: we'll put the remaining use cases on the side and hopefully
reconsider them in a follow up effort.


Thanks.