<scribe> scribe: Grisha

<johanneswilm> present

<BoCupp> present

Discussing order of business

johanneswilm: we should make sure that there is no overhead
... nevertheless, we can try them and see if they work

First issu on agenda: https://github.com/w3c/editing/issues/176

BoCupp: we've had some objection at TPAC due to the way we enable wed ves to opt-out but not opting in. Also, had some reservations around the name.

MS has a case where we may have a case for it: Dictation UI.

Had some proposal to the name change and also provide ability to enable commands.

SO wanted to make sure that I was the only one with objections.

johanneswilm: i don't have any objections around the name. Just wanted to make sure I co-edit to make sure things get included

BoCupp: @Wenson: do you have any objections?
... we can have a spec PR for next month's call. Where should the spec live?

johanneswilm: we had a similar conversation around CE. And Anne said that we could maintain it here for now.

BoCupp: sounds good

<scribe> ACTION: BoCupp to complete a PR

<johanneswilm> 225: Grisha: usecase simple - disable software keyboard

<johanneswilm> to mimic desktop app behavior

<johanneswilm> two aspects: 1. how to prevent from shopwing up, 2. get current state

<johanneswilm> this is only about 1

<johanneswilm> input panel policy is proposal

<johanneswilm> two values: automatic (OS takes care of it)

<johanneswilm> second value: manual (will not show up, even when tapping on it)

<johanneswilm> ...more difficult to show sip. still requires user interaction. JS sets input to text, etc. and then it shows up on tap

<johanneswilm> 1. is this a real problem?

<johanneswilm> 2. Do you agree with approach?

<johanneswilm> proposal to make changes to HTML spec (?)

<johanneswilm> Apple has expressed similar concerns

<johanneswilm> we aded this ability in EditContext. this is an extension to that

<johanneswilm> Johs: so for everything except editcontext

<johanneswilm> Grisha: yes

<whsieh> could you clarify the scenario where a developer would want to use inputPanelPolicy=manual instead of inputmode=none?

<johanneswilm> Bo: yes, inputmode=none is really about shape of keyboard. users can still pull it up. but it will have generic shape

<whsieh> ah, I see (Apple mobile devices have no explicit "show me the keyboard" button, so i was confused)

<whsieh> okay, yeah

<johanneswilm> in excel, there is an issue with tab. they only want the keyboard to show up on second tab

<whsieh> so in the second case

<johanneswilm> Johs: Android only?

<whsieh> one could still change inputmode to none in order to switch to the custom input mode?

<johanneswilm> Grisha: initially yes, but we have cases where any tocuh device will need that

<johanneswilm> Johs: annoying that keyboard shows up in richtext, but hasn't been a priority due to other issues

<whsieh> right yeah

<johanneswilm> Bo: Is this not an issue for iOS.. ok, I get it

<whsieh> it seems reasonable!

<johanneswilm> Bo: action - Grisha can you make spec PR?

<johanneswilm> Grisha: will do

<scribe> ACTION: Grisha to create spec PR before next call

<scribe> SCRIBE: GRisha

Isssue: https://github.com/w3c/editing/issues/200

same as https://github.com/w3c/input-events/issues/91

execCommand is still used by the quite a few people

proposal to put in execCommand specificcation of beforeInput event and use empty string for input types that do not have an execCommands

<whsieh> but we have formatBold

<whsieh> image resizing maybe

BoCupp: what is the example of execCommand with inputType empty?

johanneswilm: execCommand shouldn't be used really
... I would like to propose modifying execCommand spec
... would not want to make it part of inputEvent spec

<whsieh> yeah that was just an example of an execCommand that shouldn’t get an inputType

I don't mind having the behavior specced in execCommands.

johanneswilm: we can prepare a spec PR and let people address it

*let people object to it

<scribe> ACTION: Johannes will prepare a spec PR for next call

BoCupp: does webkit have the same behavior do they need to implement it?

already implemented in Webkit

there was another question on the order of events when JS fires its own beforeInput event. We should create a separate issue for it.

johanneswilm: yes we need to have a way of firing beforeINput events

<scribe> ACTION: Grisha will create a separate issue for next call

issue: https://github.com/w3c/contentEditable/issues/1

johanneswilm: need to confirm with marcoscaceres
... nothing to discuss

issue https://rawgit.com/w3c/input-events/v1/index.html

johanneswilm: proposing to move this to reccomendation

<scribe> ACTION: johanneswilm will contact Marcos

issue: https://github.com/w3c/input-events/issues/91

johanneswilm: the same as https://github.com/w3c/editing/issues/200

<scribe> ACTION: johanneswilm close issue 91

for next time: we'll review old actions and work on the newly tagged issues

zakim bye

small correction to issue https://github.com/w3c/editing/issues/176. Bo was not looking for ways to add support for enabling commands. Instead, he meant to say he wanted to withdraw this as a blocker.

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: grisha
Present: grisha

WARNING: Fewer than 3 people found for Present list!

Found Scribe: Grisha
Inferring ScribeNick: grisha
Found Scribe: GRisha
Inferring ScribeNick: grisha

WARNING: No "Topic:" lines found.

Agenda: https://github.com/w3c/editing/issues/226

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: bocupp grisha johannes johanneswilm

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)