<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.)[End of scribe.perl diagnostic output]