Meeting minutes
johannes: first, some background
somehow give JS devs the ability to create rich text editors that work cross browser
and come up with new specs that add new features
2nd goal related to standardizing existing features
… we are now marking items that we want to discuss...
<snianu> https://
travis: we meet every month on the 2nd thursday
we would welcome more participation
it's currently a small but regular group
if youlet us know if the time doesn't work well for you
various topics we cover:
cut copy paste
input events - eg: user input generate various rich editing tasks (like making text bold or italic)
contenteditable disabled
johannes: with contenteditable disabled, this allows devs to disable menus items that are not supported.
travis: next in list of what we cover: virtual keyboard api
control when the virtual keyboard is shown or hidden
and understand what part of the screen geometry is hidden by the virtual keyboard
Edit context API - new api to handle input before contenteditable. so you don't have to keep canceling everything you override. cleaner api.
Do we have any other specs in scope?
johanes: execCommand spec is in the archive.
warning that it's deprecated, but there's still interest to make some changes there
and some years (5-6) ago we started working on different types of contenteditable, but we haven't spent much time on that recently
that's currently waiting until input event is complete before revisiting.
Also on the agenda:
clipboard pickling
simon: can we add plaintext to the agenda
andreubotella: can we talk about IME event order and cancelablility
jgraham: also testing ime input in web browsers
plaintext only
<zcorpan> https://
<zcorpan> https://
simon: define contexteditable=plaintext-only
… implemented in webkit and chromium
… like contenteditable=true except some commands are disabled
… also affects the execCommand behavior (eg: bold does nothing)
… implemented as CSS properties (at least in chromium)
… would like to remove the CSS property, but concerns that it would cause issues
… CSS group doesn't want to standardize the user modify property
<zcorpan> https://
<annevk> Why does MDN talk about user-modify? Is there a semi-standardized version?
simon: working on WPTs for interop
… we have a draft spec for execcommand that covers the core behavior (at least as much as contenteditable=true)
johannes: last time we looked at this (many years ago)
… we thought that web editors could use this instead of contenteditable
… concern that browser could add new commands that you didn't intend to support.
… so maybe we could use =plaintext-only to address that.
… but some current usage have specific needs that don't overlap well with the needs of web editors
… so what is the goal of =plaintext
simon: idea is to get more interop between browsers
… to specify =plaintext so that a new browser impl has a reference
johanneswilm: that would be great if this could be adopted widely - we identified potential issues with this previously
simon: is part of the web platform (for better or worse) so we should spec it
… it might have odd behaviors
… but we should just bake it and then work to create something new/better
johanneswilm: that sounds reasonable, we need to be careful how we message it. Eg., do we tell web editors that they should use this
jgraham: not impl in gecko.
… some sites can break do this this. (we've had bugs reported)
… no real opinion on this but there are bugs reported about it
… not a high priority, but it is an issue
<jgraham> https://
travis: sounds like a reasonable thing: CSS doesn't like it; it causes some issues; ...
… what are the next steps simon?
simon: concerned about the status of the (deprecated) execCommand spec
… should we replace execCommand spec with another one?
… or something else?
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.
… hence recommendation of JS editors NOT to base it on execCommand
<snianu> 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.
johannes: many dev hours have been wasted on this
… having said this, there are some editing projects that make use of this, but they hit a wall when they need to make changes
… we don't expect execCommand to turn into a spec that gets published.
… there have been some discussions on whether or not we can standardize things more
… does it make sense to try to do so?
… but to fully standardize across all browsers is a big, difficult task
simon: I understand that it's a terrible API and hard to make it interop
… but still, it's part of the web platform
… and websites expect it to be there
… so we need a normative spec
… would be nice to see a spec that's not marked as "Archived"
johannes: if you look back on mailing list and github issues, this has been discussed A LOT.
… we've already spent a lot of time trying to fix things with execCommand
… it will probably require a lot more if we open this up again
… there is value in doing this, but be aware of the history
andreu: execCommand still needs to work even in the plaintext-only case
travis: we need a spec, we need to know what plaintext means, but it's going to get hairy
… because it currently is underspecified.
annevk: it would be good to some documentation and tests for this.
… I don't think we can completely ignore execCommand and pretend it doesn't exist
… ideally we could chip away at the issues and make progress
IME Input in WebDriver (James G)
<jgraham> Github: https://
jgraham: Observed a few problems with IME, breaking big things in tests.
… One of the problems: spec is difficult to handle. Part of Interop 2022 Project.
… Webdriver is what we have for testing. Choice of device. Time, how did the state of the device changed?
… How do we change something in that model?
… Proposal in webdriver # 1683
… ime is more of something in the middle.
… pressing a key event is not through the IME entirely.
… should be interecepted.
… last part: also a clauses .
… ranges of data to which IME “corresponds”.
… Other OS-apis say things differently.
garykac: critical for testing. A simpler version: we just can’t test keyboards.
<Travis> @polx, I will scribe you when you talk.
garykac: seems like only injecting the low-level key-events is the thing you can do in testing.
… trying to create a model of how IMEs work which sounds hard to grasp.
andreubotella: won’t it depend on too much environment (e.g. devices).
garykac: e.g. en-uk keyboard different than en-us keys.
jgraham: Goal is operating in the intermediate layer.
garykac: you will not get the details of the testing.
jgraham: you get information such as “IME is activated” etc… not necessarily very specific.
… it would not control such things “not doable on a french keyboard”.
Travis: I acknoledge it won’t be complete but helps a bit. This may help for the event garbled order.
… The context spec may be relevant.
<Travis> polx: When I was listening to IME things.. seemed close to a11y input systems.
<Travis> .. you probably considered these as special input already?
<Travis> .. would dictation, other a11y input be handled too?
<Travis> jgraham: yes, that's interesting to support
<Travis> .. e.g., handwriting API - like an input for pointer events.
<Travis> .. not sure if the model we're using is flexible to handle it, but we can imagine adding in others.
<Travis> polx: Liked your reference to french keyboard... lots of things that get confusing without low-level vision.
garykac: a keyboard layout change would help.
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.
… I don’t see that being the case.
… I think that this is useful to do.
… Risk of being biassed towards a particular implementation.
… If you look at the proposed spec, you can’t generate that sequence.
garykac: Also encode the differences between windows and mac?
jgraham: Sees an IME as a mapping Different platform events => DOM events.
garykac: A tester woudl test such scenarios as testing auto-completiion, even nested, of different suggestions?
jgraham: Looking at the spec will show it is incomplete.
<Zakim> annevk, you wanted to ask who reviewed this
annevk: Submited to masuyki?
jgraham: He will look at the proposal.
jgraham: some years ago, another proposal was ciruclated and made every fear.
annevk: will consider for macos
johanneswilm: Much feedback received that testing this is a missing feature.
… If it turns out, it does not correspond to a reality… what are the options?
jgraham: Compatibility has a different scope.
jgraham: If we have a problem early, then we can try changing stuffs.
annevk: Webdriver does not have much backward compatibility worries.
olli: Acknowledge the difficulty. Different orders would take care of differences between, say, Korean and Japanese IMEs?
jgraham: you’re not constraining what the IME does. Can you differ keyDown/keyUp? yes.
… can you differentiate the composite events? Not really.
Travis: different IME sources that would give different logic.
jgraham: Thanks for the feedback. It will evolve.
… remain to aim at 2022 for the consensus of a model.
snianu: Hi 'yall!
… I work on "web custom types" (not pickling any more)
… overview: were two different APIs in clipboard: datatransfer and async clipboard (which doesn't require an event to get to the clipboard.
… web custom type support only added to async clipboard
… (technically you can add custom types in datatransfer api)
… custom formats are added to the clipboard in specific ways.
… e.g., custom types get web- prefix.
e.g., html: text/html and from web "web text/html"
… standardized custom formats can be registered.
… limited to 100 on Windows.
… (not a limit on mime-types, but on OS clipboard formats--for security reasons)
… (see explainer for more details)
… custom types are unsanitized by default.
… if accessing an unsanitized web text/html, (but it's not in the clipboard) then you won't get access (no auto-conversion)
… one of the differences between the proposal and what's in chromium.
garykac: trying to catch up here...
… in an older proposal, there was only one giant blob with all the types. (Was there to work around the limit.)
… 100-limit is Windows-only?
snianu: in chromium, we are limiting all to 100 (it's also a limit on other platforms--Linux).
… It's a bad issue in Linux...when you exceed the Atom table size...
garykac: Is there an error type defined when you hit the limit?
snianu: yes, we throw an exception.
garykac: So Apple could not worry about throwing (with no limit).
… or do you want a cross-browser limit to apply?
snianu: I would like to see it standardized. We added it for Linux/Windows. Not sure about MacOS.
garykac: why "web " prefix?
annevk: It's *supposed* to not parse as a mime-type. By design.
garykac: Ok, makes sense. You want to opt-in to support.
annevk: in theory, a web- prefix might be confused with "web-something-something/else" ? How would you distinguish.
polx: First, would like to see how much desktop should be able to "do that"?
… for desktop, when you see "web " consider untrusted.
… In Windows you can invent any name anyways, so no problem.
… but on MacOS, the names aren't readable?
… Does the spec say how desktop native clipboard should go into which formats?
snianu: Yes, it's in a PR (not yet merged).
… It's up to the OS, of course.
… If the OS allows reading custom types...
… Doesn't need a standard. If an app wants to read/write that data, they can.
polx: My interest is in Math formulua (MathML)
… we put a media type format in the list.
… An fellow from Apple said we couldn't do that.
… (Back then 2010, there weren't rules, now there are)
… Important for desktop apps to use it.
snianu: (not reading) is by design. We want native apps to opt-in.
polx: How does the opt-in happening?
annevk: You write the code for it.
polx: What is the way to do that?
… I just want to be sure desktop apps can opt-in.
… was a demo yesterday about AVIF, and copy/paste seemed to work...
snianu: We could map to mathML types, but for custom types, we don't know how to create a sanitizer for it.
polx: This has been making it challenging for a while now...
annevk: But a native app should be able to get the correct name too.
smaug: So, the PR? If it's shipped, why isn't the PR landed?
polx: The release notes don't contain the new info yet.
garykac: where's the bug, and related discussion?
<smaug> https://
<snianu> Here is the PR: https://
<smaug> https://
travis: anyone else you'd like to have review while Bo is away?
snianu: It's been through various iterations. Now it finally has consensus.
polx: I want to review how this is to be done on the native apps side.
… not sure app impls are easy to write.
… Would like to know how to standardize predicting interop for this?
… Would there be some best-practices? Is it written in the spec.
snianu: Custom types don't need to be standardized.
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.
… The native app just has to do a map from custom types to what they expect.
polx: Doesn't seem hard; the apps just review the list and pull out.
… Tex standardized has a history.
… never had a clipboard type for it (laTex)
… I think media types are the right place to standardize
… I'm just suggesting we note "that" in the spec.
… if people try to do this in advance, it can help with interop.
johanneswilm: Is a bit of question about the spec.
… we're not stopping the standardization... just about not getting browser approval.
… what is @polx suggesting for the spec?
… a place to go ask for standardization of types.
polx: yes, I would like this.
johanneswilm: maybe non-normative note that says...
polx: "you can go to here/here which are good forums to standardized a media type"
annevk: Idea is these are not standardized, they are up to ad-hoc.
… I don't think this spec should document/say something about it.
<snianu> agreed with annevk
polx: if you want to merge web -> desktop... I'm thinking that having a single process.
… otherwise it's just peer-to-peer convention.
garykac: Tech question about registration limit.
… it's a sys-wide limit.
<dandclark> 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".
garykac: registration consumes an entry.
… How does the registration get cleaned up?
snianu: I don't think it's possible. Only cleaned up on restart. Ugg.
garykac: So a reboot would fix it.
snianu: one caveot. 100-custom format limit...
… they cannot write more than 100 formats to be written.
… then they get an exception.
… the 100 limit is not the max(mimetypes)...
… across different pages, you might have more mimetypes.
garykac: This is in the PR?
snianu: yes.
<Zakim> annevk, you wanted to ask about the limit (again, sorry)
annevk: the explainer says the limit is per "user session"
… how does that work?
snianu: I meant "OS session" (not browser session)
snianu: So 16K is the Os limit, but per origin is 100.
annevk: Again, to create a clipboard registration, do you need a user permission?
snianu: In chromium, yes. (permission is needed)
annevk: Pretty easy for a website to create various origins.
snianu: The same mimetypes will be reused as they are found.
annevk: There's a platform registry.
… first origin writes 100 custom formats
… it uses all the slots in the registry
… there's a mapping from mimetypes to registry slots.
… next origin writes 100... it overwrites the current registry slots with new content.
… Thanks for re-reviewing with me!
polx: What's next?
snianu: Approve the PR, and land the change!
polx: Implementation plans?
snianu: Already shipped in Chromium.
smaug: Waiting for it to land in the spec!
garykac: snianu do you own this going forward?
snianu: right now, yes.
polx: Is the "pickling" (the word) gone?
snianu: yes
<polx> @snianu: It would be cool if you had other literature references (e.g. at apple’s… there’s very little)
<snianu> unfortunately there is not an "official" documentation, but here is a blog from a Windows dev about the format limit: https://
🐔
<garykac> Travis's machine is done rebooting (and installing updates) now.
Andreu: IME order/cancelability
andreubotella: Project with Bloomboerg, editor with contenteditable.
… wanted to detect the input event and replace a typed input of an emoji with a picture emoji.
… They asked methods to do that. One of the suggestion was cancelling key events.
… but for composition this is different, beforeinput, input, then dom-update.
<andreubotella> https://
andreubotella: Issue 134 of input-events.
… reviewing https://
<andreubotella> https://
andreubotella: Showing a few positive voices, not all comments solvable.
… observing contradicting implementatons on https://
… At least desirable to have the cancelability doable.
… All in all quite some issues:
… #134: seems to be too hard.
If done, then it cancellation should be doable.
johanneswilm: History: input-events were made and were supposed to be cancellable. Just before shipping, info that on some Android IME-input-events were not cancellable.
… Chrome makes some input events not cancellable.
… spec needs to be split.
… Level 2 becomes nonetheless implemented.
… If we have editContext, then cancellability is kind of solved.
… With EditContext, javascript needs to update the DOM itself.
… About event owner: you are right, it should be there, seems to join the thought of the time.
garykac: the algorithm needs to be there unless you’re going to include the order in many many specs.
johanneswilm: suggesting to move parts of the spec.
<annevk> +1 to garykac; one user input algorithm to rule them all \o/
garikac: the event order needs to be hoisted.
garikac: We’re trying to specify the algorithm.
andreubottella: editContext without contentEditable?
travis: yes
johanneswilm: combinations can work.
johanneswilm: e.g. move-around gestures.
andreubotella: seems to be satisfied with the help of editContext.
ACTION: gary moves the event-ordering section from input-events to ui-events.
<Travis> https://
garykac: Section numbers may become confusing.
Topic end
Editing out of body (Johanneswilm)
johanneswilm: Part of the interop project: we should define how contentEditable outside of the body. A version of CKeditor 4 met a hindering bug to it.
<garykac> Input Events section 6: https://
johanneswilm: CKeditor’s people found ways around it.
… Maybe someone else uses it.
garykac: Usage scenario?
johanneswilm: e.g. to get clipboard.
Travis: It seems arbitrary.
andreubottella: head can contain contentEditable.
annevk: even several body elements work.
johanneswilm: We want to find out if there are useful use cases.
annevk: meeting these dark use cases to deduce importance.
johanneswilm: CKeditor old code: if in Firefox put it outside the body, if on Safari, put it inside.
… CKeditor 5 doesn’t use it anymore.
annevk: How do you define body?
andreubotella: some hacks I remmeber working.
annevk: some funky expriments
garykac: if it works in all browser, then maybe we should standardize it.
<johanneswilm> https://
johanneswilm: mayasuki was mentioning a compat issue.
johanneswilm: We may be spending time inappropriately.
garykac: If a new browser implementor came over, should they implement it?
<annevk_> https://
travis: will have to figure out where that goes in the processing model.
johanneswilm: Where would the eight principles go to?
travis: we might get to it at some point, but we don’t see the priority.
johanneswilm: Seems to be there on the interop-2023.
andreubottella: 2023 sounds too early.
… but many of this makes sense.
garykac: an experiment… brought all the content inside the page.
johanneswilm: got it to work with JavaScript
annevk: The parser would filter it out. That’s why one succeeds the other not.
travis: is there a 2022 interop bug ?
travis: leaving the duty to spec to the children of the children.
topic end
Discussion about the 17:00 meeting. Travis will ask the W3C staff to cancel the meeting.