17:59:13 RRSAgent has joined #editing 17:59:13 logging to https://www.w3.org/2022/09/15-editing-irc 17:59:17 Zakim has joined #editing 17:59:43 Zakim, this is Web Editing WG Meeting (TPAC Edition) 2022-09-15 17:59:43 got it, Travis 17:59:55 RRSAgent, make log public 18:00:04 johanneswilm has joined #editing 18:00:09 present+ 18:00:13 present+ 18:00:25 present+ 18:00:40 present+ 18:01:13 present+ 18:02:02 dhall has joined #editing 18:02:07 present+ 18:02:47 howard-e has joined #editing 18:03:07 jgraham has joined #editing 18:03:14 GameMaker has joined #editing 18:03:27 andreubotella has joined #editing 18:04:37 snianu has joined #editing 18:04:43 zcorpan has joined #editing 18:04:51 present+ 18:04:51 present+ 18:05:00 asully has joined #editing 18:05:02 polx has joined #editing 18:05:08 present+ 18:05:12 present+ 18:05:15 present+ 18:05:17 johannes: first, some background 18:05:21 present+ 18:05:35 somehow give JS devs the ability to create rich text editors that work cross browser 18:05:52 ScribeNick: garykac 18:05:57 and come up with new specs that add new features 18:06:12 RRSAgent: make minutes 18:06:12 I have made the request to generate https://www.w3.org/2022/09/15-editing-minutes.html jgraham 18:06:31 2nd goal related to standardizing existing features 18:06:39 RRSAgent: make logs public 18:07:22 meeting: Web Editing WG Meeting (TPAC Edition) 2022-09-15 18:07:31 chair: Travis, johanneswilm 18:07:43 ...we are now marking items that we want to discuss... 18:07:59 https://github.com/w3c/clipboard-apis/issues/165 18:08:16 akeerthi has joined #editing 18:08:29 travis: we meet every month on the 2nd thursday 18:08:32 akeerthi has left #editing 18:08:36 we would welcome more participation 18:08:43 it's currently a small but regular group 18:09:01 if youlet us know if the time doesn't work well for you 18:09:38 various topics we cover: 18:09:40 cut copy paste 18:10:33 input events - eg: user input generate various rich editing tasks (like making text bold or italic) 18:10:48 annevk has joined #editing 18:11:30 contenteditable disabled 18:12:08 RRSAgent, link? 18:12:08 I'm logging. Sorry, nothing found for 'link' 18:12:18 RRSAgent, draft minutes 18:12:18 I have made the request to generate https://www.w3.org/2022/09/15-editing-minutes.html annevk 18:12:21 johannes: with contenteditable disabled, this allows devs to disable menus items that are not supported. 18:12:48 travis: next in list of what we cover: virtual keyboard api 18:12:58 control when the virtual keyboard is shown or hidden 18:13:26 and understand what part of the screen geometry is hidden by the virtual keyboard 18:14:19 Edit context API - new api to handle input before contenteditable. so you don't have to keep canceling everything you override. cleaner api. 18:15:16 Do we have any other specs in scope? 18:15:31 johanes: execCommand spec is in the archive. 18:15:49 warning that it's deprecated, but there's still interest to make some changes there 18:16:18 and some years (5-6) ago we started working on different types of contenteditable, but we haven't spent much time on that recently 18:16:34 that's currently waiting until input event is complete before revisiting. 18:17:06 Also on the agenda: 18:17:13 clipboard pickling 18:17:14 rego_ has joined #editing 18:17:36 topic: clipboard pickling 18:17:59 simon: can we add plaintext to the agenda 18:18:01 alexk has joined #editing 18:18:59 andreubotella: can we talk about IME event order and cancelablility 18:19:52 jgraham: also testing ime input in web browsers 18:21:58 topic: plaintext only 18:22:21 s/topic: clipboard pickling// 18:22:25 https://github.com/w3c/editing/pull/407 18:22:34 https://github.com/whatwg/html/pull/8275 18:22:46 simon: define contexteditable=plaintext-only 18:22:54 ...implemented in webkit and chromium 18:23:14 ...like contenteditable=true except some commands are disabled 18:23:31 ...also affects the execCommand behavior (eg: bold does nothing) 18:24:30 ...implemented as CSS properties (at least in chromium) 18:25:22 +q 18:25:30 ...would like to remove the CSS property, but concerns that it would cause issues 18:25:40 ...CSS group doesn't want to standardize the user modify property 18:25:55 https://chromestatus.com/metrics/feature/popularity 18:26:23 ayui has joined #editing 18:26:50 Why does MDN talk about user-modify? Is there a semi-standardized version? 18:26:53 ...working on WPTs for interop 18:26:55 q? 18:26:57 q+ 18:27:42 ...we have a draft spec for execcommand that covers the core behavior (at least as much as contenteditable=true) 18:27:46 ack johanneswilm 18:27:54 johannes: last time we looked at this (many years ago) 18:28:13 ...we thought that web editors could use this instead of contenteditable 18:28:32 ...concern that browser could add new commands that you didn't intend to support. 18:28:49 ...so maybe we could use =plaintext-only to address that. 18:29:17 ...but some current usage have specific needs that don't overlap well with the needs of web editors 18:29:30 ...so what is the goal of =plaintext 18:29:44 simon: idea is to get more interop between browsers 18:30:23 ...to specify =plaintext so that a new browser impl has a reference 18:31:14 johanneswilm: that would be great if this could be adopted widely - we identified potential issues with this previously 18:31:30 simon: is part of the web platform (for better or worse) so we should spec it 18:31:35 ...it might have odd behaviors 18:31:51 ...but we should just bake it and then work to create something new/better 18:32:17 ack jgraham 18:32:23 johanneswilm: that sounds reasonable, we need to be careful how we message it. Eg., do we tell web editors that they should use this 18:32:34 jgraham: not impl in gecko. 18:32:53 ...some sites can break do this this. (we've had bugs reported) 18:33:09 ...no real opinion on this but there are bugs reported about it 18:33:16 q? 18:33:19 ...not a high priority, but it is an issue 18:33:28 https://bugzilla.mozilla.org/show_bug.cgi?id=1291467 is the gecko bug, which has links to the broken sites 18:33:40 q+ 18:33:56 travis: sounds like a reasonable thing: CSS doesn't like it; it causes some issues; ... 18:34:05 ...what are the next steps simon? 18:34:20 simon: concerned about the status of the (deprecated) execCommand spec 18:34:30 ...should we replace execCommand spec with another one? 18:34:37 ...or something else? 18:34:39 q? 18:35:40 johannes: execCommand, even if impl perfectly, cannot be used by JS editors because if they need to divert from it in any way, then immediatly they can't use it because they need to re-write a log. 18:35:54 ...hence recommendation of JS editors NOT to base it on execCommand 18:36:00 spec'ing execCommands would be interesting. All browsers have different behaviors and no one wants to change the behavior because sites might break due to the hacks they have in-place for all browsers. 18:36:05 ...many dev hours have been wasted on this 18:36:11 soloproc has joined #editing 18:36:32 ...having said this, there are some editing projects that make use of this, but they hit a wall when they need to make changes 18:36:44 ...we don't expect execCommand to turn into a spec that gets published. 18:37:02 ...there have been some discussions on whether or not we can standardize things more 18:37:08 ...does it make sense to try to do so? 18:37:24 ...but to fully standardize across all browsers is a big, difficult task 18:37:33 ack zcorpan 18:37:46 simon: I understand that it's a terrible API and hard to make it interop 18:37:56 ...but still, it's part of the web platform 18:38:01 ...and websites expect it to be there 18:38:10 ...so we need a normative spec 18:38:24 ...would be nice to see a spec that's not marked as "Archived" 18:38:39 q+ 18:38:47 johannes: if you look back on mailing list and github issues, this has been discussed A LOT. 18:39:07 ...we've already spent a lot of time trying to fix things with execCommand 18:39:30 ...it will probably require a lot more if we open this up again 18:39:48 ack andreubotella 18:39:50 ...there is value in doing this, but be aware of the history 18:40:32 andreu: execCommand still needs to work even in the plaintext-only case 18:40:48 travis: we need a spec, we need to know what plaintext means, but it's going to get hairy 18:40:56 ...because it currently is underspecified. 18:41:34 +q 18:41:43 annevk: it would be good to some documentation and tests for this. 18:41:57 ...I don't think we can completely ignore execCommand and pretend it doesn't exist 18:42:09 ...ideally we could chip away at the issues and make progress 18:46:37 topic: end 18:50:48 polx has joined #editing 18:52:20 Scribenick: polx 18:52:41 Topic: IME Input in WebDriver (James G) 18:52:58 Github: https://github.com/w3c/webdriver/issues/1683 18:53:27 andreubotella_ has joined #editing 18:53:35 jgraham: Observed a few problems with IME, breaking big things in tests. 18:54:14 … One of the problems: spec is difficult to handle. Part of Chrome 2022 Project. 18:54:29 s/Chrome/Intro/ 18:54:42 s/Intro/Interop/ 18:55:32 … Webdriver is what we have for testing. Choice of device. Time, how did the state of the device changed? 18:55:38 q+ 18:55:50 q- 18:56:01 … How do we change something in that model? 18:56:30 … Proposal in #1683 18:56:49 s/#1683/ webdriver # 1683/ 18:57:12 … ime is more of something in the middle. 18:57:54 … pressing a key event is not through the IME entirely. 18:58:08 … should be interecepted. 18:58:59 … last part: also a clauses . 18:59:41 … ranges of data to which IME “corresponds”. 18:59:43 q+ 19:00:19 … Other OS-apis say things differently. 19:00:58 q? 19:01:00 ack garykac 19:01:23 Gary: critical for testing. A simpler version: we just can’t test keyboards. 19:01:36 s/Gary/garykac/ 19:02:02 q+ 19:02:21 @polx, I will scribe you when you talk. 19:02:23 … seems like only injecting the low-level key-events is the thing you can do in testing. 19:03:13 … trying to create a model of how IMEs work which sounds hard to grasp. 19:04:13 Other guy: won’t it depend on too much environment (e.g. devices). 19:04:26 s/Other guy/andreubotella 19:04:49 garykac: e.g. en-uk keyboard different than en-us keys. 19:05:40 jgraham: Goal is operating in the intermediate layer. 19:06:46 garykac: you will not get the details of the testing. 19:07:10 jgraham: you get information such as “IME is activated” etc… not necessarily very specific. 19:07:53 … it would not control such things “not doable on a french keyboard”. 19:08:18 ack tilgovi 19:08:21 ack Travis 19:08:58 Travis: I acknoledge it won’t be complete but helps a bit. This may help for the event garbled order. 19:09:03 q+ 19:09:18 q+ to ask who reviewed this 19:09:22 … The context spec may be relevant. 19:09:30 ack polx 19:09:44 polx: When I was listening to IME things.. seemed close to a11y input systems. 19:09:53 .. you probably considered these as special input already? 19:10:11 .. would dictation, other a11y input be handled too? 19:10:21 ack polx 19:10:25 jgraham: yes, that's interesting to support 19:10:39 .. e.g., handwriting API - like an input for pointer events. 19:10:54 .. not sure if the model we're using is flexible to handle it, but we can imagine adding in others. 19:11:20 polx: Liked your reference to french keyboard... lots of things that get confusing without low-level vision. 19:11:44 garykac: a keyboard layout would help. 19:11:45 +q 19:12:08 s/layout/layout change/ 19:12:17 ack garykac 19:12:52 garykac: I have the impression it fills a gap but the expectations may come too high, giving an ideal model of what an IME can do. 19:13:09 … I don’t see that being the case. 19:13:34 … I think that this is useful to do. 19:13:51 q+ 19:13:58 … Risk of being biassed towards a particular implementation. 19:15:08 … If you look at the proposed spec, you can’t generate that sequence. 19:16:09 garykac: Also encode the differences between windows and mac? 19:16:54 jgraham: Sees an IME as a mapping Different platform events => DOM events. 19:17:49 garykac: A tester woudl test such scenarios as testing auto-completiion, even nested, of different suggestions. 19:18:00 s/suggestions./suggestions?/ 19:18:19 jgraham: Looking at the spec will show it is incomplete. 19:18:22 ack annevk 19:18:22 annevk, you wanted to ask who reviewed this 19:18:23 ack garykac 19:18:54 annevk: Submited to xxx? 19:19:13 jgraham: He will look at the proposal. 19:19:27 s/xxx/masuyki/ 19:20:09 jgraham: some years ago, another proposal was ciruclated and made every fear. 19:20:19 annevk: will consider for macos 19:20:22 ack johanneswilm 19:21:08 johanneswilm: Much feedback received that testing this is a missing feature. 19:22:10 … If it turns out, it does not correspond to a reality… what are the options? 19:22:48 jgraham: Compatibility has a different scope. 19:23:19 jgraham: If we have a problem early, then we can try changing stuffs. 19:23:43 annevk: Webdriver does not have much backward compatibility worries. 19:23:54 ack smaug 19:24:54 olli: Acknowledge the difficulty. Different orders would take care of differences between, say, Korean and Japanese IMEs? 19:26:01 jgraham: you’re not constraining what the IME does. Can you differ keyDown/keyUp? yes. 19:26:22 … can you differentiate the composite events? Not really. 19:26:55 Travis: different IME sources that would give different logic. 19:27:00 q? 19:27:01 whsieh has joined #editing 19:27:40 jgraham: Thanks for the feedback. It will evolve. 19:27:51 howard-e has joined #editing 19:28:15 … remain to aim at 2022 for the consensus of a model. 19:29:29 topic, close 19:29:33 topic, end 19:29:38 RRSAgent, make minutes 19:29:38 I have made the request to generate https://www.w3.org/2022/09/15-editing-minutes.html xiaoqian 19:51:12 howard-e has joined #editing 20:08:43 howard-e has joined #editing 20:19:35 present+ 20:19:48 polx has joined #editing 20:21:53 ayui has joined #editing 20:22:16 scribe: Travis 20:22:42 snianu: Hi 'yall! 20:22:59 .. I work on "web custom types" (not pickling any more) 20:23:22 asully has joined #editing 20:23:48 .. overview: were two different APIs in clipboard: datatransfer and async clipboard (which doesn't require an event to get to the clipboard. 20:24:02 .. web custom type support only added to async clipboard 20:24:16 .. (technically you can add custom types in datatransfer api) 20:24:41 .. custom formats are added to the clipboard in specific ways. 20:24:54 .. e.g., custom types get web- prefix. 20:25:17 e.g., html: text/html and from web "web text/html" 20:25:23 annevk has joined #editing 20:25:31 q+ 20:25:45 .. standardized custom formats can be registered. 20:25:52 .. limited to 100 on Windows. 20:26:05 q+ 20:26:11 .. (not a limit on mime-types, but on OS clipboard formats--for security reasons) 20:26:18 .. (see explainer for more details) 20:26:30 .. custom types are unsanitized by default. 20:27:11 .. if accessing an unsanitized web text/html, (but it's not in the clipboard) then you won't get access (no auto-conversion) 20:27:29 howard-e has joined #editing 20:27:29 .. one of the differences between the proposal and what's in chromium. 20:27:31 q? 20:27:35 ack garykac 20:27:42 garykac: trying to catch up here... 20:28:03 .. in an older proposal, there was only one giant blob with all the types. (Was there to work around the limit.) 20:28:11 .. 100-limit is Windows-only? 20:28:51 snianu: in chromium, we are limiting all to 100 (it's also a limit on other platforms--Linux). 20:29:12 .. It's a bad issue in Linux...when you exceed the Atom table size... 20:29:24 q+ 20:29:26 garykac: Is there an error type defined when you hit the limit? 20:29:32 snianu: yes, we throw an exception. 20:29:50 garykac: So Apple could not worry about throwing (with no limit). 20:30:06 .. or do you want a cross-browser limit to apply? 20:30:26 snianu: I would like to see it standardized. We added it for Linux/Windows. Not sure about MacOS. 20:30:55 garykac: why "web " prefix? 20:31:10 annevk: It's *supposed* to not parse as a mime-type. By design. 20:31:30 garykac: Ok, makes sense. You want to opt-in to support. 20:32:02 annevk: in theory, a web- prefix might be confused with "web-something-something/else" ? How would you distinguish. 20:32:05 ack polx 20:32:22 polx: First, would like to see how much desktop should be able to "do that"? 20:32:33 .. for desktop, when you see "web " consider untrusted. 20:32:43 .. In Windows you can invent any name anyways, so no problem. 20:32:53 .. but on MacOS, the names aren't readable? 20:33:02 andreubotella has joined #editing 20:33:14 .. Does the spec say how desktop native clipboard should go into which formats? 20:33:22 snianu: Yes, it's in a PR (not yet merged). 20:33:30 .. It's up to the OS, of course. 20:33:40 .. If the OS allows reading custom types... 20:33:57 .. Doesn't need a standard. If an app wants to read/write that data, they can. 20:34:02 q? 20:34:11 polx: My interest is in Math formulua (MathML) 20:34:18 .. we put a media type format in the list. 20:34:30 .. An fellow from Apple said we couldn't do that. 20:34:45 .. (Back then 2010, there weren't rules, not there are) 20:34:49 s/not/now 20:35:03 .. Important for desktop apps to use it. 20:35:24 snianu: (not reading) is by design. We want native apps to opt-in. 20:35:32 polx: How does the opt-in happening? 20:35:40 annevk: You write the code for it. 20:35:56 polx: What is the way to do that? 20:36:15 .. I just want to be sure desktop apps can opt-in. 20:36:43 .. was a demo yesterday about AVIF, and copy/paste seemed to work... 20:37:10 snianu: We could map to mathML types, but for custom types, we don't know how to create a sanitizer for it. 20:37:23 polx: This has been making it challenging for a while now... 20:37:40 annevk: But a native app should be able to get the correct name too. 20:37:43 q? 20:37:51 ack smaug 20:38:09 smaug: So, the PR? If it's shipped, why isn't the PR landed? 20:38:29 polx: The release notes don't contain the new info yet. 20:38:39 garykac: where's the bug, and related discussion? 20:38:46 https://github.com/w3c/clipboard-apis/pull/175 20:39:07 Here is the PR: https://github.com/w3c/clipboard-apis/pull/175 20:39:23 https://github.com/w3c/clipboard-apis/issues/165 20:40:25 travis: anyone else you'd like to have review while Bo is away? 20:40:32 q+ 20:40:52 snianu: It's been through various iterations. Now it finally has consensus. 20:41:05 polx: I want to review how this is to be done on the native apps side. 20:41:13 .. not sure app impls are easy to write. 20:41:13 ack polx 20:41:29 .. Would like to know how to standardize predicting interop for this? 20:41:41 .. Would there be some best-practices? Is it written in the spec. 20:42:03 snianu: Custom types don't need to be standardized. 20:42:33 +q 20:42:53 snianu: In the OS, when a native app tries to read a format, it just won't work, since they have to write code for how to get the custom type out. 20:43:26 .. The native app just has to do a map from custom types to what they expect. 20:43:44 polx: Doesn't seem hard; the apps just review the list and pull out. 20:44:05 .. Tex standardized has a history. 20:44:15 .. never had a clipboard type for it (laTex) 20:44:36 .. I think media types are the right place to standardize 20:44:49 .. I'm just suggesting we note "that" in the spec. 20:45:20 .. if people try to do this in advance, it can help with interop. 20:45:21 q? 20:45:32 ack johanneswilm 20:45:41 johanneswilm: Is a bit of question about the spec. 20:45:57 .. we're not stopping the standardization... just about not getting browser approval. 20:46:08 .. what is @polx suggesting for the spec? 20:46:20 .. a place to go ask for standardization of types. 20:46:29 polx: yes, I would like this. 20:46:42 johanneswilm: maybe non-normative note that says... 20:47:11 polx: "you can go to here/here which are good forums to standardized a media type" 20:47:30 annevk: Idea is these are not standardized, they are up to ad-hoc. 20:47:48 .. I don't think this spec should document/say something about it. 20:48:03 agreed with annevk 20:48:16 polx: if you want to merge web -> desktop... I'm thinking that having a single process. 20:48:25 q+ 20:48:44 q+ 20:48:53 .. otherwise it's just peer-to-peer convention. 20:48:57 ack tilgovi 20:49:00 q+ to ask about the limit (again, sorry) 20:49:37 ack Travis 20:49:53 garykac: Tech question about registration limit. 20:50:01 .. it's a sys-wide limit. 20:50:03 ack garykac 20:50:06 Travis: I like the idea of redirecting readers that land in the spec to a place to go for a normal MIME type. "This isn't the spec you're looking for, if you want the standard MIME type exchange for Office then go to x". 20:50:14 .. registration consumes an entry. 20:50:24 .. How does the registration get cleaned up? 20:50:40 snianu: I don't think it's possible. Only cleaned up on restart. Ugg. 20:50:50 garykac: So a reboot would fix it. 20:51:00 snianu: one caveot. 100-custom format limit... 20:51:25 .. they cannot write more than 100 formats to be written. 20:51:34 .. then they get an exception. 20:52:02 .. the 100 limit is not the max(mimetypes)... 20:53:01 .. across different pages, you might have more mimetypes. 20:53:11 garykac: This is in the PR? 20:53:13 snianu: yes. 20:53:14 q? 20:53:18 ack annevk 20:53:18 annevk, you wanted to ask about the limit (again, sorry) 20:53:36 annevk: the explainer says the limit is per "user session" 20:53:39 .. how does that work? 20:53:59 snianu: I meant "OS session" (not browser session) 20:54:18 snianu: So 16K is the Os limit, but per origin is 100. 20:54:37 annevk: Again, to create a clipboard registration, do you need a user permission? 20:54:50 snianu: In chromium, yes. (permission is needed) 20:55:09 annevk: Pretty easy for a website to create various origins. 20:55:26 snianu: The same mimetypes will be reused as they are found. 20:55:48 q? 20:55:51 q+ 20:56:16 ack Travis 20:56:25 annevk: There's a platform registry. 20:56:34 .. first origin writes 100 custom formats 20:56:42 .. it uses all the slots in the registry 20:56:59 .. there's a mapping from mimetypes to registry slots. 20:57:23 .. next origin writes 100... it overwrites the current registry slots with new content. 20:57:44 .. Thanks for re-reviewing with me! 20:58:03 polx: What's next? 20:58:13 snianu: Approve the PR, and land the change! 20:59:02 polx: Implementation plans? 20:59:10 snianu: Already shipped in Chromium. 20:59:46 smaug: Waiting for it to land in the spec! 21:00:52