<chaals> Scribe: chaals

introductions

GL: Grisha, MS Edge.

WH: Winsen, Apple platform integration and editing

JW: Johannes, editing input events / content editable / exec command

CMN: Chaals, co-chair of webplat

GK: Gary, Google, editor of ui events, clipboard API, ...

DT: Dave, Google, work in input stack in blink.

CR: Changwan Ryu: Chong, Google, chrome on Android and formerly IME

<kochi> Yoichi Osato

<changwan> Changwan Ryu

YO: Yoichi, google, implementing side of editing and selection API

TK: Takayashi Kochi, Google, worked on IME API proposal

OP: Olli, Mozilla, sworks on stuff.

agenda stuff

JW: First thing is Input events level 2 is what Apple did but not Chrome. Will we do the level 1 now-ish, and then level 2, or follow Alexander's alternative and move away from contentEditable towards a hidden textarea
... If we continue with level 2, can we make more things cancelable
... if we continue with input events we need to be able to disable things from menus
... (and what colour should that bikeshed^Wattribute name be

Input Events level 2...

CW: The vision doc is Alex' thoughts. But I have some opinions.
... two observations: compsition is hard to cancel - the input APIs are not designed to be cancelable.
... the IME tells the editor to do something and the editor cannot say NO
... to cancel an event the input handling is done in one flow and IME on another. So they need to be synchronised to be cancelable.
... IME has sequence of commands. When we cancel the first, the rest of them make no sense. How do we handle that?

<johanneswilm> +q

CW: we have to wait until author decides what to do
... Second observation: Most uses of contenteditiable are for styling and layout, not complex editing. Says Alex, at least...
... using textarea not as we know it today, but have a lean layer putting in an MVC model, interacting with JS in plaintext, and a seperate layer for rendering.

GL: The hidden textarea is browser generated? How does the JS find it?

CW: Not sure exactly, maybe a textarea that listens to inputs on the hidden textarea, and the user sees it reflected onto a text canvas.

GL: Is this the browser or library implementing?

CW: My understanding is it is mostly the web author's work to implement.
... Browser has to e.g. expose composition to get the rendering right.

WH: Details like cursor and selection would have to be rendered on top of the content?

JW: Plan includes giving a bunch of primitives that allow a selection in the hidden textarea to be matched in the viewable with some cursos and stuff you can manipulate.
... With Input events over the last 2 years, we found IME is really hard. We isolated that and made everything else cancelable, with special non-cancelable types for IME.
... To isolate the IME process, we need one event cancelable before composition starts, and after it is done.
... but the stuff in the middle of that happening cannot be canceled

WH: Webkit does this.

JW: As I understand Alex, he didn't want the DOM update at the start of the process. But there are a lot of DOM updates, and that seems even more expensive to handle all the bits in the middle.

DT: The events aren't changing the DOM in the middle.

JW: The JS trying to track all the events, and having to diff the DOM, seems expensive by comparison. Although I am not implmneting in the browser, I wonder why it is worse for Android than webkit.
... Which is why my thinking at the moment is that input events 2 seems the shortest path to nirvana

DT: I think the problem was a difference in the way apple/android IMEs select things to start with.

WH: Yes.

DT: So the different IMEs were the motivation.
... so is there a reasonable approach to avoid handling all the JS events in the middle?

JW: hidden textarea isn't mad. There have been a lot of efforts in this century, and people keep finding problems with their approaches. We don't know yet.
... presented Alex' proposal to CKeditor, prosemirror and substance.io they all said the hard bit is keeping the selection - you have two hidden places for text and one visible and you need to keep selection in synch.
... and if you try to select half a table and some following text, that gets REALLY messy.
... It is possible, but doesn't seem like we should decide to support just this moving forward.

DT: I guess there is a can of worms with RTL text too.

JW: That was one area the prosemirror identified, along with vertical caret movbement. He went back to cE ...
... we have an implementation that makes sense

GL: Is it all performance, or are there other concerns?

DT: There is performance - removing a word and indicate the event wants to do something. You could passively listen, so if people preventDefault we can rewind or something.
... The other thing is the asynch behaviour of multiple processes and we cannot unwind the IME.
... is webkits IME asynch?

WH: It is asynch, but we can prevent the start/end. The updates in the middle cannot be unwound.

DT: So we can't cancel IME in mid-composition?

WH: Not really.

DT: So when you commit the text do we unwind and redo it?
... performance thing was that we underline the word when you first press it.
... we have a fast path instead of removing and replacing. You press on the word, and you can replace by typing.
... selecting on a word boundary. that is cheap on graphics

CW: We try to keep users close to replacement. We don't mutate the DOM.

DT: But the view is mutated.

WH: So then it is hard to mess with the composition?

TK: My understanding... in the old IME model, modeled on more complex keyboard, communication is one-way

user types something, IME translates to something else and then sends it to the application.

scribe: On Android, IME is like collaborative editing. Your app and IME share the same document.

So they are both editing the text.

JW: just tried this with gboard, click n content and choose contents as alternative. I get compostionEnd, then everything else outside - deleteContentBackward, beforeInput, beforeIOnput, ... outside the composition

CW: Gboard took a detour around because they thought it was cheaper. And we were not happy but now accepted it.
... SHortest path from authors' view would be to get a composition update.

JW: Reason to isolate the composition was enable touch, underline, update, happening inside the composition.
... but this seems to stop the composition before it does the replacement work.

CW: Yeah, but gboard is just on of the keyboards we have.
... it isn't a bug strictly...

JW: If everyone did it this way the problem would go away.

CW: I think we will still have problems even in gboard.
... So on Android IME sends a command, editor does something, and state is updated back to the IME.
... it isn't two-way, editor changing whatever they want, because it is very asynch. So almost impossible for IME to incorporate changes made by the editor independently

TK: There are issues about getting surrounding text around the caret

GL: like selection updates?

CW: Get the current status. IME can modify or query current status. Latter is a synch method.
... we had to work around that.

JW: SO hard to conclude if input events 2 or hidden textarea is the way forward?

DT: We are committed to fixing level 1, but no, we currently haven't changed our position on level 2

JW: And then?

DT: If performance was a concern for level 2, how do we enhance the API so changes don't force non-rich editors through the full state machine

JW: Without listeners could you work differently

DT: That's what we need to think about. The blink code sends events without caring if there is a listener.
... We have talked about checking first but don't

HW: Is the concern with JS doing stuff or browser spinning?

DT: To fire event you need to manipulate the DOM. Which is mostly irrelevant in practice.
... we don't normally have to do that manipulation. If we knew it was going to be prevented, we might be able to make a new codepath, but that gets complex.

GL: Basic assumption is we should fire the events regardless. How do you know if there is someone listening?

DT: Yeah, you can look at the target... problem we are trying to solve is aspecific case as opposed to looking at a higher level.
... cE is not very interoperable. So we need to do something or walk away from that and find a new solution.

JW: POint of input events was that we can make further modes of cE, and when nobody uses standard cE anymore we can throw it away and use JS libraries.
... Input is used in all sorts of cases. Hard to see cE used outside JS editors, or other large bits of code.
... because it is so broken that otherwise you wouldn't use it.
... checking whether there is cE without anyone listening we could do something different.
... So propose we continue to work on Input events.

DT: We agree - finish level 1. If Apple supports level 2, go ahead, we may or may not ever implement

JW: You also made a lot of stuff non-cancelable in level 1.

GL: Only cancelable stuff is formatting.

DT: Thought it was consistent that way.
... having unpredictably cancelable was weird. On Android, we think of everything as IME, so "only IME" is everything.

JW: There are things Alexander says have to be outside IME. Enter key... Alex said "yeah, gmail needed that"...
... seems like at some point Alex started walking away from "everything is IME".
... splitting textnodes could be outside IME on Android too.
... Taking stuff out of IME would help JS editors.

CW: Enter in the middle of a line may not be a physical key - can be "\n"

JW: Outside of a composition is what I mean.
... and it is outside at the moment.

CW: Why does it matter whether the user is composing text?

JW: When you are composing text you're working on continuous content of a single text node.

CW: Not necessarily.

JW: Whereas when you hit enter inside an element to split them, the JS definitely wants to handle that on its own.
... generally OK for IME to make changes, and then let us check and see if we want to do something. e.g. composing a word that was partially styled, the JS wants to reapply the same half-styling.
... You have it working like that because Gmail wants it like that. If we can get things like that out of IME, that would help...

CW: We cannot block IMEs from sending text.

[break]

<johanneswilm> break cut to 15 minutes!

<johanneswilm> we are back at 10:45

Disabling features

JW: We need to be able to disable features from the menus. The idea had been to add an attribute to the cE. Is that reasonable, what should it be called?

WH: cE can take on different values, right?

GL: major attributes are supported...

JW: We said we wanted different cE modes a few years ago - more or less of stuff would be handled by JS instead of natively, so long term we can remove cE="true" (or actually standardise it instead of it being black magic)
... issue is how can we get the menu option for bold to appear.

WH: So it is about finer granularity of what is supported.

GL: You want bold to show up in soft keyboard menu, but don't want it to execute but to let JS do the work?

JW: Right.

GL: BeforeInut takes care of it for level 2 at least.

WH: We need to know when to show UI at the chrome level, or not.

JW: Want to be able to drop them if the editor doesn't e.g. support justify.
... (since they will just confuse users, unless they work).
... and where they are there, let the editor handle the work.

GL: like input types...
... you would have a cE type.

CMN: Alternative is to have a set of flags in an attribute, to turn on (or off) the things.

DT: So you have a default set of capabilities, or you can get "bold, italic" because you did not ask for it.

JW: Should it be a blacklist or whitelist. All the things you want might be long, but really taht's not such a big deal.

DT: You would have to go to CSS for this

CMN: ? why?

GL: We should ask them.

DT: There is precedent for doing that in CSS.

GL: Talked to someone in CSS about a property, and they said they didn't want that in CSS, it is HTML attribute.

DT: Where should these things be if it is on the HTML element.

CMN: You could model it on iframe sandbox with a pile of flags in it...

DT: An argument for doing it through CSS would be that you might want a lot of editable areas in a page...

CMN: Like the idea of using CSS definition approaches rather than forcing the attribute to be explicit every time.

<scribe> ACTION: Grisha to ask CSS about whether it makes sense to set up flags as CSS properties.

JW: When we were looking at this, browsers wanted blacklist defaults, JS editors wanted whitelists. Because browsers wanted to be able to ship somethig new and make it work, but JS deves didn't want to have to match taht the day it shipped.

DT: Are they preventDefault input by default?

JW: Yes.

GL: There is a visibility issue - if it is hidden the OS could have an issue.

CMN: Think OS developers will win this argument if we don't agree...

<ojan> Side comment: I'd also want to avoid CSS for this. Means we need to do a style recalc before doing editing operations, which is bad for perf.

[+1 to Ojan because I don't think this is real style]

GL: Which channel will fix users' issues faster?
... OS update, or getting JS developers to update?

[discussion of whether we can answer this question sensibly]

<ojan> chaals: That line of reasoning tends not to be compelling because there's so much in CSS that isn't real style. The perf argument is more objective. :)

JW: Another example - smileys cannot go into databases, and a 10k document breaks because one new character was used in it...

[discussion: making blacklist default means there is some pressure on the ecosystem to communicate and implement collaboratively]

JW: So could we use e.g. cE-something ?

[bikeshed...]

[contenteditable-disable="(list of things)" ?]

Proposed resolution: We will add the attribute contenteditable-disable="(space separated flags)" as a way to disable specific features

<smaug> (we just removed menuitem from the platform)

JW: Substance.io would like a way to add their own formatting commands to native menus.
... told them it is highly unlikely.

WH: There is menuitem - we are interested in implementing that.

JW: Which would be a way to enable that.

YO: What if you have nested contenteditable with different lists for ce-disable?

JW: The outer one with more capabilities.

GK: initial use case was "I don't support this in my tool anyway"

CMN: True, but there are use cases, and besides, we *will* run across it so we need to define it.

[JW shows use case example for different features not just because they are implemented or not]

CMN: So do we inherit from the parent, or reset it?

GK: Do we have enough for Johannes to go away and figure this out sensibly?

CMN: Think you should not inherit blacklist from parents

JW: Agree... for a starting point.

GK: WfM

RESOLUTION: We will add the attribute contenteditable-disable="(space separated flags)" as a way to disable specific features

Input events resumed

GL: Chrome are not currently interested in Input Events 2?

GK: At the moment, that's our default. Ask us when we finish level 1.

DT: If ecosystem moved to hidden textarea, we would not bother with more work on cE. But if not, we need to have a think.

GL: That shift would require JS developers to adopt it, right?

DT: There are some features that we need to offer before there is much risk of them moving.

GL: Are these concerns based on pre-implmentation, or just worries?

GK: We haven't got someone dedicated to doing the preimplementation at the moment

GL: MS is on level 2 - we have some development, but we are not dealing with Android

CW: Same issue seems to apply for CJK...

GL: We haven't checked carefully, but we believe webkit works and so it can work.

CW: We share some concern about cancelability.
... think that might affect desktops too.

JW: In level 2 IMEs are non-cancelable.

CW: When key events are cancelable, IME events will eventually be cancelable.

JW: Not in level 2 - maybe in the unforeseeable future but we don't know.

CW: My major concern was that, too.

[conclusion, Google are not apparently militantly opposed to level 2]

[discussion about whether we are going to get to interop some time]

no resolution, because this is predicting the future...

inputmode / inputmode-action

DT: inputmode is in HTML but unimplemented. Would like to make an enumeration of stuff we could implement...
... none, tel, url, numeric, email, decimal, search
... these affect the virtual keyboard. With none, you get no virtual keyboard - this is a request from kiosk apps who already have a virtual keyboard
... would like to support this inside contenteditable. Think it is relatively straightforward.
... mainly focused for mobile

CMN: Virtual keyboards...

DT: Mozilla didn't want to do this, so want support from others...

WH: Seems reasonable to me.

DT: We would expose this on HTMLElement instead of input

<smaug> I think I can live with the attributes. I'd still prefer to not add more stuff to the contenteditable crap but have something spec'ed properly, but looks like that isn't happening

DT: so you can put them on anything, not just input fields.
... would take precedence over the type of the input

<smaug> (sorry, I'm multitasking badly right now)

GL: Not sure how Android handles focusing on virtual keyboard

CW: We do not let the keyboard focus at the moment.

DT: If you switch from decimal to octal in value the keyboard will change.

CMN: Sounds great, could easily be in W3C HTML again.

[seems reasonable, wait and see if that turns into implementation...]

DT: inputmode-action allows you to customise the enter key on a virtual keyboard, according to what will happen when you hit it.
... based on moz-action-hint

TL: It is a label, right?

DT: It is an enum

TL: Wouldn't you want input type="search" and have that trigger it?

DT: This is on cE
... use the input magic, and break it out in properties.
... that we can then make available in cE

TL: Proliferation of attributes is distasteful

DT: Agree. But I blame the poeple who did autocapitalize for starting it. If we add an *element* for cE, we should make it behave the same.

TL: Yes. In the short time that might take.

JW: looked at this, made sense, the editor people I spoke to thought it looked good.

Multiple ranges.

JW: Alex proposed to have selections where he can show one, and have another one in an invisible area.

<kochi> https://github.com/yoichio/public-documents/blob/master/multiranges.md

JW: that takes multiple selections. There is also a proposal from Yoichi that is related

GL: Apple was working on multi-select...

WH: Not got anywhere

GK: Firefox has it.

<smaug> Firefox has multiple ranges

<dtapuska> inputmode-action proposal

<dtapuska> inputmode proposal

[YO talks through the document. Various ways of selecting discontiguous bits of a document - text runs, table columns, things that are made with odd layout rules...]

TL: Have you tried implementing this?

YO: Not yet.

TL: It will be interesting.

CMN: Can you select a column?

TK: Hard to say.

TL: You normally select based on the content model. Users expect to select what is visible. But the web model has been based around selecting content.
... I admire this, but you will need to do a lot of work to see if it is possible to do a selection model based on layout.

JW: Selection comes from the browser. But someone from Atlassian made a thing to enable selecting columns.

GL: Sounds like an editing operation, not something the browser should add
... we tried it before, and removed it.

JW: It can be done in JS, too.

TL: Users would love more selection. But thatś tricky to map into a thing that works.
... Do you Xor when user tries to ctrl-click/drag overlapping ranges?

YO: We stop extending the selection when it enters into the existing piece of the selection.

GK: Doesn't matter...

TK: So basically if we want to implement multiple ranges, we need to restrict functionality to make it easier to start.

TL: So you opt in, and that turns of exec command with multiple range enabled.

JW: Editors don't use it. But clipboard API does, no?

GK: Yes, until life gets better sometime soon we hope.
... exec command won't be specified. Ideally we can deprecate it. One day. We are looking to get usage, and hoping it is libraries because it is so painful. Which simplifies the pathway
... Optimism is great.

GL: That's only clipboard related commands, right?

GK: Yes.

JW: And Firefox uses it.

GK: As long as people use it in Clipboard it won't go away. Once we get that out, we can deprecate it.
... clearly you need to look at timing.
... would be nice if we could stop using exec command.

GL: Why use staticrange?

GK: Performance
... You can opt in to the expensive dynamic ones, but normally you don't need to do that.

JW: Have you coordinated this with Alex' proposal for other types of selection?

[no]

JW: Is there a plan for that?

GK: Maybe, if we had hidden fields but they seem orthogonal at least on the surface.

CW: Would it be helpful if we give authors where the spellcheck is?

JW: Yes, but that opens a hole into browser dictionaries...

GK: Worth revisiting if fingerprinting is the only concern.

JW: On the other hand, yes it would be very useful.

rrasgent, draft minutes

accessibility - joint meeting with APA

Accessibility

JW: What are we going to do here... look at accessibility of input events.

JD: Seems to me there is nothing here that is an accessibility problem.
... in testing, we found that the implementations are not giving accessibility notifications.
... (that is the bad news). The good news is that screenreaders get notifications and know how to deal with it.
... The good news is that when the implementation bugs get fixed, we should be good.
... Some of the unique issues related to the spec, like Undo, on linux, through ctrl-Z I get notification for text being inserted. Does the screen reader talk about all the text that changed, or just say "undo"?
... we can do that heurisitically, but if some editor uses ctrl-v to undo or uses a button in the editor, that breaks the heuristic
... And there isn't an "undo" notification in the platform in my case :S
... Finally, we think it is worth having a spec that describes the Accessibility API mappings - how to map what the spec defines into the different platform accessibility APIs.
... So implemnentations know what message to send to the API so it gets to the user.
... Which means someone has to own a spec if we want one.
... We can do it in ARIA (I would be happy if the group lets me). Or it could be done by Steve Faulkner in webplat.

MK: It is important to work out where this lives.

JW: won't we have to be sort of in lockstep for versioning?

JD: The AAM isn't specific to input events. It's about text changes in general.
... so it doesn't have to be in lockstep.

JS: So if there are additional features we will want to drive them through the AAM

MK: And the accessibility APIs on the platform, too.

JW: If we add "crossed out" styling, you want to put it in yours

JD: But for such an example we have it in the platform, so we would need it in the AAM *before* you put it into input events.

DM: Scope of an AAM is text editing. You mentioned notifications, but sometimes there are attributes and methods as well. Are they in scope?

JD: Think so. Scope is formatting, not so much text editing.

DM: Wondering what the scope for AAM is. Formatting independent of text editing seems not quite useful, so thinking it might be sensible to have both.

<johanneswilm> +q

MK: A link in a text field has more than just text attributes - there is the fact that it is a link. In cE you need to communicate that. Would it be part of the AAM?

JD: Nope.

MK: So you would bring in the HTML AAM as well.

JD: Yep.

MK: Is a link a link object in the editor?

DM: Think so, but think the question makes sense. Don't think we can explain what happens when you enter a character in a textarea.

[exploring details]

JW: What about things that are not directly formatting? For example sticker insertion - small images inserted inline like a custom emoji that is not a character.

GL: It is an image, so it comes out as a real image.

JW: But with some metadata. It's not typical of existing word processor, how would we go about that?

JD: Not sure

JC: Don't think we want to limit it to editing events - there are some related things we might end up dealing with.

CMN: There is a deliverable we need to scope out somewhere, and we need a warm body to deal with it.

JD: I am willing to contribute, what I envision about text attributes, I am willing to do that. Will talk to ARIA WG and see what they think.

<johanneswilm> +q

LJW: Think it makes sense to keep the AAM in the WG that is dealing with the base specs - i.e. Web Platform in this case

JD: Works for me.

JC: It may fit in the charter by making it part of the main specs.

GK: Having it in the main spec actually makes a lot of sense

JC: The specs get agnostic to platforms. We are trying to move these to registry models.

CMN: Agree with Gary that having it in close collaboration with the development makes sense.

GK: Like we did with keycodes and UI-events.

JD: So what spec would it be in?

GK: Yeah, tricky question.
... it helps to have the note that you need to deal with the AAM in the spec that defines things that touch it.

JD: So do we put them in HTML, and input events, and ...?

JW: What triggers you to call the events? Is it a change in the DOM, or an input event, or?
... [outlines various scenarios that might cause something to become bold].
... Hence it is not clear where it is that you say "this should trigger the notification to the accessibility API"

MK: Why does it have to be in the DOM?
... what if it is on a canvas?

JD: If the rendering engine turns the text bold, that is the time to make the notification.

JC: There is nothing in the rendering engine, when you do this by painting on a canvas.

JD: Think Joanie is on the right track for the common case...

[detailed discussion of exemplary ratholes]

<johanneswilm> +q

CMN: We have preliminary agreement to work on something, we have an offer to work on it, the chairs need to work out if it is in scope and when it is, talk the to editor and get it underway so the group can check more carefully whether they want to keep moving it forward.

ContentEditable

SL: @@

JW: The editing TF has been working on cleaning up the mess for several years, and will continue.
... true, asking for DOM updates is sub-optimal. Think we will end up needing to tell the browser if a requested bolding step actually took place.

SL: Assumes your model has a direct correlation with what HTML actually supports.

JC: Unless there is a mainstream benefit to getting that to happen it is hard to get authors to do this effectively.
... it is hard to get authors to do things right.
... it is easier to fix the browsers than fix every author.

JW: These libraries are like browsers - there are a handful of them.

<grisha> test

<garykac_> Overall, I wanted to talk a bit about clipboard copy/paste of images

<garykac_> Tracking bug: https://github.com/w3c/clipboard-apis/issues/44

<garykac_> There are a number of issues that we need to resolve WRT images

<garykac_> If you want to paste an image on the clipboard (say, a PNG). What should the API look like?

<garykac_> How do you specify the image?

<garykac_> Do you specify as a BLOB?

<garykac_> Blob are kinda ugly and don't quite feel right?

<garykac_> What about an <img> tag or something similar?

<garykac_> cf. SetDragImage on DataTransfer

<garykac_> The way pasteboard works on Apple.

<garykac_> Each item has multiple representations (eg: image as PNG or JPG)

<garykac_> The receiver can get whatever format it wants.

<garykac_> Discussion: about image fidelity and transcoding

<johanneswilm> question: could it not be enough to provide png?

<garykac_> Agree that always trancoding is reasonable to avoid malicious images being placed on the clipboard.

<johanneswilm> why not ship it if browser contains transcoders anyway?

<garykac_> Can we have only one image type on the clipboard (eg. PNG) and have the JS convert to other image formats if desired?

<johanneswilm> *it = ability to transcode images to any image type by JS

<garykac_> Always converting to PNG (or whatever) is being explicit about the fact that the image is being transcoded.

<grisha> makes sense to expose one image type on the clipboard and give js the ability for JS to convert in other formats

<johanneswilm> makes sense to always provide png, makes it easier for JS devs as well to deal with

<dtapuska> Animated GIFS?

<dtapuska> Do you want to transcode into multiple formats?

<dtapuska> color spaces?

<dtapuska> It is only writing from the less priviledged application to the browser proces.. we only need transcoding in one direction

<garykac_> Next issue is with delayed generation of clipboard data

<garykac_> https://github.com/w3c/clipboard-apis/issues/41

<dtapuska> Windows uses WM_RENDERFORMAT

<johanneswilm> privacy issues?

<dtapuska> OSX has a promise based obj-c callback

<johanneswilm> will you snapshot at time of copy?

<johanneswilm> gary: yepp

<garykac_> REading custom mimetypes from clipboard: https://github.com/w3c/clipboard-apis/issues/46

Web rich text editing roadmap

<xiaoqian> proposal https://docs.google.com/document/d/10qltJUVg1-Rlnbjc6RH8WnngpJptMEj-tyrvIZBPSfY/edit

<xfq> ScribeNick: xfq

[unscribed discussion]

changwan: I don't think the interaction of content selection with IME is a big issue

garykac: I think realistically we can't spec this if it's not implemented

Dave: we would like to make small changes incrementally, instead of write a big document

<chaals> GK: THis is a useful document in terms of describing a bunch of ideas, whether or not we are implementing it...

<chaals> [blue handles. These are tricky because they are based on rendering of layout...]

<chaals> JW: Developers want to have a paragraph selection to be a box, not a ragged line thing.

<chaals> GL: Highlighting is powered by selection, so it follows that.

<chaals> JW: Right, but they were after finer grained control over the look of selection.

<chaals> ... it's a question of styling.

<chaals> [floating action bars]

<chaals> JW: Devs have extended menu entries, and can't fit them into the pattern.

<chaals> WH: iOS doesn't do this in the Web layer. Not sure how much we should allow customisation, for consistency

<chaals> GL: Not a context menu?

<chaals> WH: Hmm, sort of...

<chaals> GL: You can design your own contextmenu...

<chaals> WH: But this doesn't work like that.

<chaals> CW: Is contextmenu customisation prevalent

<chaals> ... why not adopted in HTML?

<chaals> CMN: There is some explanation in chrome bug tracker of why they went cold on the idea.

<chaals> JW: A reason to disable menu items was that the existing menu was a monster....

<chaals> ... it is strange if there is a native menu for bold and italic and a JS one that looks different for underline...

<chaals> [note that contextmenu support was a pretty highly-ranked request from devs, for what statistically unreliable surveying is worth]

<chaals> WH: They want to take stuff off the menu and supply their own?

<chaals> JW: Ideally.

<chaals> ... if that doesn't work, then they try to separate the menus by category...

<chaals> WH: so if we had contenteditable-disable then we could just not show the native control.

<chaals> GL: So who is drawing the menu here?

<chaals> CW: Browser

<chaals> ... but using OS primitive

<chaals> CW: We have a separate context menu too.

<chaals> TK: Adding user-defined menu item is another extension here.

<chaals> JW: That's what everyone wants to be able to do... control the menu...

<chaals> WH: Main motivator is touch.

<chaals> [Focus subprojects]

<chaals> CW: e.g. autofocus doesn't show keyboard. We might want to be able to control that. Will need it for hidden textarea.

<chaals> TK: People want to know the onscreen keyboard ate half the screen or gave it back.

<chaals> CW: Android doesn't tell you that.

<chaals> TK: How do you scroll area outside keyboard?

<chaals> CW: Onresize.

<chaals> WH: iOS doesn't let you know that either. And we want(ed) to make it hard to know

<chaals> CMN: What's the rationale?

<chaals> [unclear]

<chaals> DT: One reason is resize triggers a pile of relayout...

<chaals> [cancelable IME backspace/enter]

<chaals> CW: This is complex. IME doesn't know if stuff changes under it.

<chaals> ... this means OS-level changes.

<chaals> ... there are some opportunities for very crazy ways to make the key press. We want to streamline and special-case enter/delete out of IME

<chaals> JW: Yes please

<chaals> [JW was asking for this in the morning already :) ]

<chaals> CW: Will pass that on to gboard

<chaals> [spellcheck]

<chaals> CW: Discussed already, we might want to expose some of this, but look out for fingerprint / privacy issue

<chaals> ... would this be useful without hidden textarea?

<chaals> TK: I introduced this in an IME compositionUpdate

<chaals> ... that can be retrieved, and could be useful for rendering.

<chaals> CW: We have additional underlines. Maybe something to expose.

<chaals> ... basic idea is expose more information about composition.

<chaals> JW: You could also have temporary hidden textarea just for composition, and copy that,

<chaals> ... during composition I cannot change the DOM anyway.

<chaals> CW: IME can do a lot of editing without composition.

<chaals> ... rationale for hidden textarea will apply beyond that.

<chaals> JW: During composition, you cannot do DOM changes close by. We are used to that.

<chaals> ... We had a proposal, where compositionstart moves into a hidden area, you copy the content out to the DOM during composition, and the composition didn't freak out because you leave the area alone.

<chaals> ... You can move caret at compositionstart. Makes it easier to manage half-styled text under composition.

<chaals> GL: You also protect from DOM mutation as a result of user input.

<chaals> JW: And then windows got a new IME that would crash if we tried it, and then... oh, look, a butterfly

<chaals> GL: Think the crash was just a bug. Things changed again a bit.

<chaals> ... move focus e.g. to hidden area is a new edit context. have to check if it is possible to reroute and not terminate the composition

<chaals> JW: So yes, underline would be of interest there

<chaals> [IME dropdown menu position]

<chaals> TK: dropdown is drawn by IME, browser tells it where to do that.

<chaals> JW: We were giving the position before the composition moved to the composition window, so it got the initial coordinates as where to put it.

<chaals> TK: Browser doesn't know where the window is.

<chaals> GL: We give coordinates to the editable box, IME chooses where to put it.

<chaals> ... Do we have knowledge of final coordinates?

<chaals> DT: It's dynamic as you type.

<chaals> TK: e.g. when search suggest comes out under the typing, you want the IME suggestions to be above to avoid clashing

<chaals> GL: We had css-based disableIMEwindow, we dropped it because nobody else liked it.

<chaals> JW: Where would we write this down?

<chaals> [IME spec]

<chaals> GL: Do you need this?

<chaals> JW: Not if we have level 2

<chaals> CMN: Think we have it in scope to pick it up if you want.

<chaals> JW: If there is browser interest, it might be worth taking up.

<chaals> GL: present a good use case first.

<chaals> DT: Right.

<chaals> JW: So if these things are being implemented and there is no problem, we're great.

<chaals> ... Who is working on spec/implementation for these?

<chaals> ... [splitting selection]: nobody

<chaals> ... [blue handles]: some work

<chaals> ... get some more?

<chaals> ... but not really being worked on now.

<chaals> ...[Floating action bar] contenteditable-disable should help. Adding with menuitem?

<chaals> WH: Cannot promise menuitem will lead here.

<chaals> DT: Can you add actions in a native app?

<chaals> WH: Yes. Will look at viability.

<chaals> [show/hide keyboard]

<chaals> GL: Could this be a part of IME spec?

<chaals> DT: we would like to do this but Android doesn't help.

<chaals> ... maybe in the future.

<chaals> WH: There is a lot of information to be read from resize. Maybe we can revisit, will think about it.

<chaals> CW: IME can do what they want, keyboard isn't pinned to the bottom.

<chaals> [cancelable enter/backspace]

<chaals> WH: our stock keyboard behaves OK.

<chaals> (Android doesn't have a stock keyboard)

<chaals> GL: We could not find one.

<chaals> CW: Think that common keyboards will work fine. Probably

<chaals> ... question is whether we should call for OS-level changes

<chaals> JW: But you can do that without us making a spec or anything, it is just Android, right?

<chaals> CW: Think so.

<chaals> [underlines for spellcheck/composition]

<chaals> ?

<chaals> [IME menu position]

<chaals> Grisha and Johannes to chase up.

<chaals> [Thanks to Johannes for chairing, everyone]

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/CW/CR: Changwan Ryu/
Succeeded: s/Koichi/Kochi/
Succeeded: s/do this in/set up flags as/
Succeeded: s/email/numeric, email/
Succeeded: s|inputmode-action https://cdn.rawgit.com/dtapuska/action-hint/ee34bfcc/index.html|inputmode-action proposal|
Succeeded: s/inputmode http/-> http/
Succeeded: s|HEAD/index.html|HEAD/index.html inputmode proposal|
Succeeded: s/tak/talk/
Present: Olli-Smaug(remote) Grisha Winsen Johannes Chaals Gary Dave Changwan Yoichi Takayashi xiaoqian TravisL GlenGordon(Remote) AliceBoxhall DomenicMazzoni JaninaSajka Fuqiao JamesCraig Joanie MattKing(APA)
Found Scribe: chaals
Inferring ScribeNick: chaals
WARNING: No scribe lines found matching previous ScribeNick pattern: <xfq> ...
Found ScribeNick: xfq
ScribeNicks: xfq, chaals

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

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