- From: Johannes Wilm <mail@johanneswilm.org>
- Date: Thu, 11 Dec 2025 16:16:23 +0100
- To: public-editing-tf@w3.org
- Message-ID: <CABkgm-SYwb1ZKofi1ge9ZEW9MEzz4AhgO4-PXRY2BAPfv5DSkA@mail.gmail.com>
# Web Editing WG TPAC 2025 Meeting \- Thursday 13 November
# Participants
* Ashish Kumar
* [Olli Pettay](mailto:opettay@mozilla.com)
* Megan Gardner
* Tomasz Jakut
* Johannes Wilm
* Xiaoqian Wu (W3C)
* [Zgroza (Luke) Klimek](mailto:zgroza@google.com)
* Euclid Ye (Observer)
# Chair
* Johannes Wilm
# Scribes
* Megan Gardner
* and others
# Logistics
Location: Floor 3 \- 305
Remote: [
https://www.w3.org/events/meetings/88e0ec80-d710-4584-a15c-eb305b37e28e/](https://www.w3.org/events/meetings/88e0ec80-d710-4584-a15c-eb305b37e28e/)
# Agenda
[
https://github.com/w3c/editing/issues/487](https://github.com/w3c/editing/issues/487)
# Minutes
### Topic: Welcome everyone\!
### Topic: UI Events
* #### How do we continue?
* The person who was going to speak about this isn’t here yet
* Mike \- Also Sideshow Barker
* Work for the W3C
* For the WebApps working group
* We don’t have a proliferation for a lot of working groups
* This stuff runs in WebApps
* We have a lot of specifications, and a lot that aren’t being actively
worked on
* Sometimes that’s fine, because there’s no pain
* Other times there’s specification in a bad state that needs work
* There’s different ways where we can measure problems
* The most effective way to determine that is to see if there’s pain
* Pain that’s caused by having things not clearly specified
* We have things that are working in a messy corner or chunk of the
platform
* When we try and figure out what kind of pain this is causing
* The best thing we can do it try to not cause pain for end users
* The next is pain for web developers
* This is harder to measure, you can get conflicting responses about
things.
* What kind of pain is this causing for implementers?
* I found that UIEvents were less pleasant to implement than other spects
* This is causing pain that I can feel directly myself
* The next question is how to we assess what we need to do
* Can we take a look at the Open Issue List?
* Johannes
* The background here is there is not long term maintainer, the last ones
disappeared
* Mike
* Even when the spec had a formally dedicated editor, it still wasn’t
being edited
* One of the issues here is for windows vs window proxy
* This seems to be like there’s some low hanging fruit
* There’s 200 issue that need to be gone through
* Another problem that we have is when we find this is that we need an
editor
* And we block on that until we find an editor.
* We meet a couple times a month and see if we can go through the open
issues.
* Some parts of UIEvents need to be moved it, but that won’t fix all of
these issues.
* The mundane work of resolving these open issues merits some time and
attention to make this work.
* We call this editing, but what really needs to happen is to look at the
open issues.
* The LadyBird project is actively implementing things and is needed help
resolving these issues.
* Smaug
* From the Pointer Events point of view, we may be able to take some of
that
* And as you said we can move some other things to some other places like
HTML
* But there’s still a lot of issues.
* Mike
* To make this concrete \- why can’t we just make this change?
* My question is there some confusion on if this is the right kind of
change to make?
* Is this testable? Is there a way to make a test?
* There’s that kind of level of work that needs to be done
* Johannes
* Some of the history is that Gary was very active here and he wanted to
move some of the UIEvents into another area. He felt that this should all
be in once place.
* Later on, the idea was that the input event spec would not have an
order that would be on UIEvents. But now that the UIEvents Spec should have
that.
* It seems like we should move the Input Events part in UIEvents back
into the Input Events spec.
* Mike
* It sounds like things are split up and we should put them back.
* Johannes
* Gary stopped showing up, but it is difficult to get the work done.
* There are keyboard events and something that are important for editing.
* Low intensity workfare.
* Xq
* For clarification, would you like to keep a single spec for Input
Events?
* Johannes
* Parts at in UIEvents, but that is very large, so I would like to move
parts back out to Input Events to make it easier to follow and easier for
us to maintain that as an editing group.
* Also to participate in this low intensity workfare. There are things
like keyboard events that are important for editing
* Mike
* There’s a lot of that I don’t understand.
* It’s a separate document.
* For logistics on this, what we talked about.
* Once I get it set up, I’ll send out some information.
* Xq
* What time is the editing group meeting?
* Johannes
* Around midnight in Japan.
* To Mike \- Do you want to meet?
* Mike
* I don’t need another meeting
* Johannes
* It sounds like timewise that we will need to find a time that works for
Europe and Japan, and also the US West Coast.
* Mike
* I can call in at Midnight or 1am.
* If we can meet a little earlier, that would work better for me.
* Johannes
* We can find an acceptable time for all.
* Mike
* Rather than optimizing for the best time for me personally, I would
rather have the people that care about this the most.
* Xq
* If we
* Smaug
* We don’t know quite what UIEvent will look like. Maybe we need to
rename this.
* Mike
* This will probably stay in UIEvents in WebApps.
* Smaug
* We don’t even know what this spec will look like.
* Johannes
* It was that way when we were part of WebApps for a while, we didn’t
bring it with us when we became our own working group.
* Mike
* It’s always great when we come to TPAC and everyone’s really exciting
about it, and then there’s stuff like this.
* I appreciate that this isn’t super appealing, but sometimes we gotta do
what we got to do.
* I’ll do that next week.
* Xq
* Mike and I are both working on this.
* Mike
* Thank you for giving us time to talk about this and volunteering.
Topic: Brent from the Advisory Board
- Soliciting feedback about the process
- Scribed by Brent
### Topic: Clipboard APIs
* #### [w3c/clipboard-apis\#239](
https://github.com/w3c/clipboard-apis/pull/239) Add comprehensive
clipboardchange event specification with ClipboardChangeEventInit dictionary
* Rohan \- proposed this API sometime last year
* Multiple discussions around this, find out if there any more blockers
* There’s an active issue around parameters
* This issue that Anne raised was that two different origins shouldn’t
see the same change ID
* Two different origins should see two different change ID
* Hash the change ID with the storage key
* Have a normative section in the spec around this
* Anne was ok with this approach
* Waiting for formal approval in the comment section
* We would like to know if there’s anything else blocking this
* Johannes
* Who agreed to things in the corridor conversation
* Anne, Rohan, and Luke were a part of this conversation
* Smaug
* Could you explain the permission model
* Rohan
* What is the sticky activation check
* In browsers who have a permission model it doesn’t make sense to
request the activation check
* If the browser doesn’t have the permission model
* Johannes
* But does that work for Safari
* This should probably be reworded
* Rohan
* I might need to reword this
* Luke
* If it does not have this and it does not have this
* All
* Determine that the wording is correct
* More discussion about if it’s correct way to word it
* Johannes
* Can we have a resolution to adopt this?
* You can retract within two weeks
* Smaug
* It’s fine, I can read it later
* Johannes
* Resolution is to include the feedback from Anne
* And adopt the resolution
* #### [w3c/clipboard-apis\#242](
https://github.com/w3c/clipboard-apis/issues/242) ClipboardItem: clarify
mime parsing
* #### [w3c/clipboard-apis\#243](
https://github.com/w3c/clipboard-apis/issues/243) changeId interaction
between clipboard.write and clipboardchange
* Rohan
* Once they write any custom data to clipboard to have a custom MIME type
* If the unique identifier matches the one that they wrote then they know
that the clipboard change event was the one that they had and they will
know to ignore it
* We will confirm with the original person if this is ok, and we will
believe this has been addressed, so we will ask instead of just closing it.
* #### [w3c/clipboard-apis\#240](
https://github.com/w3c/clipboard-apis/issues/240) Selective Clipboard
Format Read
* Rohan
* I hope everyone is aware of this proposal to optimize MIME type reading
* We want to optimize where the web author can request specific MIME
types
* We have two options, one was to specifically ask for a set of MIME
types
* The second option can cause certain backward compatibility challenges
* This changes the behaviour of the clipboard item as well
* With this change, this will give you the latest data every time it is
called
* We were concerned that some website were replying on the clipboard
* To have a persistent state
* Say a clipboard timeline application
* So there was a backward compatibility list
* To move forward we have added this in chromium
* There are a few more concern around this
* The backward compatibility issue
* The user permission part
* So if we are moving the read to the get type, do we want to move the
* Permission to getType.
* The other scenario is that you do the permission first.
* Since the permission is refused.
* Smaug
* The permission model is where this is difficult
* They were not expecting and error from getType
* Rohan
* If the clipboard changes between then it throws an error
* But there are some backward compatibility issues that we want to see if
there are actually issues here
* Johannes
* What are the backwards compatibility issues here
* Smaug
* If you give the permission once, then it has that access forever?
* Rohan
* Yes, but you can manually deny that permission in settings
* So if the use denies the permission then it
* Smaug
* This seems a very unlikely scenario
* Rohan
* What if the clipboard never changes and the clipboard item and they
might just what to read it later
* Johannes
* You are collecting telemetry data on this?
* What exactly are you collecting
* Rohan
* We are, and checking to see if this permission changes
* Johannes
* This is only an issue if we have old clipboard items around
* Rohan
* This only matters if they have a cache
* Johannes
* They could read it later and that’s when there’s an issue later
* If this is an issue, it’s only for Chromium
* If the telemetry data shows that this isn’t really being done, so that
would show that it’s not really an issue
* Get back to us when we have the telemetry data?
* #### [clipboard-apis/issues/244](
https://github.com/w3c/clipboard-apis/issues/244) Standardize Clipboard
Source url
* Rohan
* The proposal is to have a new MIME type whenever a site copies data to
the clipboard
* This origin information will help antivirus software
* If the application is not trusted, if the app is not trusted, then it
can help try and block malicious data that would have been transferred.
* Antivirus software rely on these MIME types
* The proposal is to standardize this URL to make it easier for this
software to work.
* Rakesh
* What was the question?
* I wanted to add a couple of thoughts
* Standardizing this is also proposed by Firefox:
[
https://bugzilla.mozilla.org/show\_bug.cgi?id=1965323](https://bugzilla.mozilla.org/show_bug.cgi?id=1965323)
* Antivirus and antimalware software are using these
* Chromium is writing to a different MIME type
* I’m not sure if Safari is writing it or not
* The motivation is to standardize this that way we are doing
* This in general should help these applications
* ClickFix attacks blog: [
https://textslashplain.com/2025/04/15/vibe-coding-for-security/](https://textslashplain.com/2025/04/15/vibe-coding-for-security/)
* Johannes
* The negative of this is that browsers would change this and then the
antivirus software wouldn’t know about the new work
* Smaug
* This seems like we added this to firefox many years ago and not touched
since.
* Johannes
* Is this a particular pain that there are different ones.
* Rohan
* Yes we were contacted by these software developers
* Smaug
* We need to standardize what this actually means, source origin
* Where is that said and what the value actually is.
* Johannes
* Where should this land? What is actually proposed here.
* Rohan
* Probably in the editing spec somewhere
* Smaug
* In Firefox this is about the exec command would we need to support that
case as well?
* Johannes
* So something in the exec command document and something in the async.
* Does this have to go several places?
* Smaug
* Can it just be in once place?
* This can be talking about a generic place to
* Rohan
* Even if you copy from the address bar, not just the content.
* If you right click or control-c
* Smaug
* I think defining this is the clipboard spec, maybe that’s enough.
* Rakesh
* I think maybe we are ok with that.
* Johannes
* So general support from Firefox.
* We don’t know what Safari is doing.
* So we need a little bit more research on that, but not direct
opposition so far.
* And then we take this up on the next call
* Rohan
* And then we will come up with a new spec PR.
* Xq
* We need to nominate a new editor.
* Johannes
* Reads the current editors of the specs.
* I got a message that Dan will be an editor for Edit Context, but also
Requish.
Action: Rohan to submit a PR and update the editor’s list, add new editors
and move names to former editor list
* #### [w3c/clipboard-apis\#242](
https://github.com/w3c/clipboard-apis/issues/242) ClipboardItem: clarify
mime parsing
* Rohan
* Spaces in MIME types are alright, but not according to the spec. Amend
the spec maybe?
* Use case in Chromium: web custom types
* Johannes
* Browsers support it, we should either change the browsers or the spec
* Are we sure this is happening for all browsers, who filed the spec?
* Megan
* Someone from Servo probably is trying to implement it
* Smaug
* Did the spec change after the implementation?
* Rohan
* No reason to *not* have the space
* Johannes
* Reasons to generally be restrictive. But given that they are currently
allowed and there is some argument to use them, maybe they should be
allowed.
* Smaug
* What is the use case of the constructor? From JS.
* Rohan
* `write()` uses this
* Smaug
* The easiest way to follow the spec
* Megan
* If no one follows the spec, we don’t know what will break
* Johannes
* Should we investigate between now and December
* All
* Yes, okay
* Megan
* It’s a bad situation overall, we don’t want this to be a blocker for
implementing new web engines.
* #### [w3c/clipboard-apis\#237](
https://github.com/w3c/clipboard-apis/issues/237) Questions about
implementing clipboard.write
* Rohan
* I don’t know who filed this
* Megan
* Probably a Ladybird contributor
* #### Thoughts on API support for reading the available types on clipboard
*
####
### \[10:30 – 11:00: ☕ Break\]
### Topic: EditContext
* #### [w3c/edit-context\#111](
https://github.com/w3c/edit-context/issues/111) / [w3c/edit-context\#115](
https://github.com/w3c/edit-context/pull/115) Maintain selection and
composition during updateText()
* Ashish
* Demonstration of the issue
* To propose the solution, make changes in \#115
* The proposed solution is likely not backwards compatible
* We collected telemetry and impact will not be big, but not trivial also
* Johannes
* EditContext has been requested by a number of libraries, but no
investment enough to make it work.
* One tried it and found a big issue
* Change is not backwards compatible, but the current behavior is not
what one would expect
* You want to experiment this, do you want to add this to the spec?
* Ashish
* Yes
* Johannes
* What do you mean experimental? Behind a flag?
* Ashish
* Yes
* Smaug
* The spec change is a draft, do you want a review?
* Johannes
* Experimentation, behind a flag \-\> review \-\> testing, if successful
then we’ll go to merging the spec change.
* Firefox not against, what about Apple?
* Megan
* It should be fine.
* Johannes
* When do you need this?
* Today no one is objecting, please continue.
* #### [w3c/edit-context\#107](
https://github.com/w3c/edit-context/issues/107) EditContext.text can be
problematic from performance point of view
* Ashish
* `.text` attribute might be problematic from the performance point of
view.
* Smaug
* Implementation doesn’t have to have this as a big chunk of memory
* Did you test this?
* Rohan
* Is the concern that the text might occupy memory?
* Smaug
* Reallocation-based problems
* Johannes
* `.text` vs the accessor methods
* Rohan
* Let’s have both `.text` and `.set/get` methods
* Johannes
* It would be good
* Smaug
* (agrees)
* Johannes
* So, the proposal from Dan is to add those two methods
* The proposal in the room now is to add them *in addition* to the
current `.text` so that we do not break anything
* Megan
* No problem with that
* Ashish
* We have to explore that
* Johannes
* Resolutions here may be withdrawn within 2 weeks, tell if you encounter
problems
* We have a resolution: add this in addition to the current thing
* #### [w3c/edit-context\#104](
https://github.com/w3c/edit-context/issues/104) EditContext.text should not
extend by default
* Ashish
* Memory usage for edit context for apps which are not using the text
property, for scenarios where text is not needed
* 3 possible cases where text being used
* Canvas element
* Composition element
* Text prediction
* Impl and spec same as current
* Use updateText method being used to clear the text if text not needed
* 3rd option \- have optional argument “should extend” and use that to
check if text needs to be extended
* Are we missing anything or any other scenarios ?
* Rohan
* By extend do we mean populating the memory only on access of attribute
* Johannes
* Smaug
* Chromium keeps this in memory all the time
* With the new methods get/setText, we can keep the memory in chunks
* Implementation detail
* Request is not clear
* Johannes
* Maybe the request is to not update the text
* Might not be viable path
* Don’t use the text property, so they wipe it
* We could have 2 versions, 1 update the text , 1 that does not update
the text
* Rakesh
* Where there are other options, there is a decent developer driven work
around, not changing anything and clears text
- Johannes
- Is this really a workaround, fix is the JS side which is not optimized.
- Updating to empty also takes memory and has impact
- Smaug
- Length is small in that case so not that big impact
- Johannes
- Is this a real issue ? is this a JS dev just being savvy ? or is it a
test case which is failing
- Smaug
- The API is error prone
- Johannes
- Browser wants to update the text
- Should we ask the author
- Smaug
- Similar to previous memory performance issue
- Johannes
- Option of having 2 modes, might work
- Do we ask for stats ?
- Smaug
- We should ask for more feedback ? have you though about IMEs
- I will ask them
- Johannes
- You can say we need that to move forward
- Smaug
- Regarding \- [
https://github.com/mozilla/standards-positions/issues/199\#issuecomment-3226968951](https://github.com/mozilla/standards-positions/issues/199#issuecomment-3226968951)
- Requesting to read from accessibility point of view
- Johannes
- Canvas was meant for google docs / word online
- DOM based one was meant for opens source lib \- it used DOM based
approach
- The use case for the canvas is for google docs / wordonline
### Topic: New Editing spec
* #### support for Bidirectional(presence of both ltr and rtl) text:
Selection and cursor navigation – where should we start?
- Rakesh
- We dont have github issue or proposal for bidirectional support. Still
in ideation phase
- Concept of proposal \- today a common practice for people to use LTR
and RTL text in same sentence in same world.
- In chromium based browsers, in selection part, it has both combination.
We want to improve UX to support such combinations
- We plan to have a proposal, don’t have much as of now. Just wanted to
pitch the idea
- Johannes
- We already spoke about making new spec, not much about directions
- Caret movement in general is oe of things, close to selection but not
the same
- There are other questions \- editor inside editor does it go around it
? should go in editing spec
- Given another issue about caret movement all should go into new spec \-
with a specific section
- We solved it 10 years ago \- caret wouldn’t go certain places. It was
less of a need. But a spec would be good with new browsers coming along.
- Are you proposing a new spec, can we have another section with carent
move around svgs, images and other problematic elements
- Rakesh
- Would be good idea
- Johannes
- Need a name for spec. \- Caret movement spec
- Smaug
- Sounds reasonable
- Rakesh:
- Sounds good
- Johannes
- Resolution \- have new spec “Caret movement”. Rakesh will be the
editor. I can share more issues around the caret movement. Looking forward
for some proposals
[
https://github.com/w3c/clipboard-apis/issues/237](https://github.com/w3c/clipboard-apis/issues/237)
- Smaug
- There seem to be a proposal
- Rohan
- The proposal in the issue looks good. Can we come to a resolution
- Smaug
- The proposal looks fine. Needs PR
- Johannes
- Are there any opposition to the proposal
- There is an agreement.
### \[12:30 – 13:45: 🍽️ Lunch Break\]
### Topic: Input events
* #### What is stopping developers from creating editors based only on
input events?
Note: with Michael Aufreiter, JS Editor developer
[
https://github.com/michael/web-editing](https://github.com/michael/web-editing)
[
https://github.com/michael/web-editing?tab=readme-ov-file\#top-4-requests](https://github.com/michael/web-editing?tab=readme-ov-file#top-4-requests)
“Ability to rollback DOM changes of a composition at oncompositionend
stage”
Johannes: known issue for long time, need to get one thing
[
https://github.com/w3c/input-events/issues/34](https://github.com/w3c/input-events/issues/34)
Isolate composition. We cannot stop IME: instead, after compositionend
everythign will be rolled back, and rolled back in, as single “input
event”. Wasn’t possible on Android at that time.
Michael is proposing something a bit different, so there shouldn’t be
performance issue, since it is explicit method call. execCommand(“undo”),
seems to work as a workaround. Working mostly in all the browsers.
Michael: pretending that nothing happened and then do incrementatl
re-rendering
Ashish:EditContext let’s web dev to have control over updates
Michael: not option right now, since not supported everywhere.
Michael: I do like that I don’t need to do anything special here with
contentEditable.
Johannes: so there is solution using execCommand, but it is not spec’ed
anywhere atm. Could we spec this somewhere?
Smaug: need to have at least a note somewhere.
Rohan: how would undo deal with other dom mutations?
Johannes: in theory execCommand should deal with its own undo stack
Smaug: is the issue 4 related to 1
Michael: I think they are separate. In 1 the main thing is the composition
rollup handling
Johannes: For 1\. Issue. Let’s document existing behavior. And add another
method which doesn’t rely on execCommand.
Mike: would there be other web visible events firing from resetDom? Would
there be other web visible things there?
Smaug: you’d get mutation observer records
Mike: what if there are multiple event listeners?
Johannes: we don’t care too much about multiple listeners. We could define
it that only first call matters. JS editor will fail if there are multiple
listeners. All the editors expect only one listeners.
Mike: ok, it would be a bug in the site
Michael: alternative way would be to have a flag “reset DOM after
composition”
Rohan: browser implementation could do diffing. Compositionstart could have
a flag, which would then prevent side effects.
Smaug: I’m not convinced preventing creating mutation records.
Issue [
https://github.com/michael/web-editing?tab=readme-ov-file\#ability-to-capture-eventgettargetranges-at-oncompositionstart-stage](https://github.com/michael/web-editing?tab=readme-ov-file#ability-to-capture-eventgettargetranges-at-oncompositionstart-stage)
Johannes: why is this an issue?
Michael: as soon as event is composing
It would be more convenient to get it in composistionstart. And on
Android/Samsung, there are events missing after compositionstart.
Smaug: is this Android only issue?
Michael: not sure it is Android only. It is more about that it is indirect.
I can handle all the cases now, but it isn’t trivial.
Johannes: we’ll investigate
[
https://github.com/michael/web-editing?tab=readme-ov-file\#ability-to-cancel-composition-events-at-the-very-beginning](https://github.com/michael/web-editing?tab=readme-ov-file#ability-to-cancel-composition-events-at-the-very-beginning)
Michael: why I can’t cancel the very first event.
Rohan: what is the use case?
Johannes: to prevent some inputs, still let caret movement
Michael: want to prevent deletion of the selection underneath in some cases
Johannes: we’ll discuss also about this issue. Need to document that
composition stops happening
Micheal: I’ll transfer the issues to w3c repository
[
https://github.com/michael/web-editing?tab=readme-ov-file\#ability-create-and-handle-custom-history-events](https://github.com/michael/web-editing?tab=readme-ov-file#ability-create-and-handle-custom-history-events)
Johannes: on desktop, buttons for undo/redo are disabled, but using
execCommand hack can enable them.
Megan: no talk since 2019 about UndoManager
Michael: good news that this has been discussed before
Michael: not a deal breaker, but would be good.
Micheal: desktop isn’t usually problem, but mobile is.
Johannes: touchbar had undo/redo, so the issue was discussed in 2019\.
Elsewhere the buttons aren’t so visible on desktop.
### \[15:00 – 15:30: ☕ Break\]
### Topic: Input events (continued)
* #### [w3c/input-events\#176](
https://github.com/w3c/input-events/issues/176) insertCompositionText (and
isComposing) cannot tell the input event accompanied by compositionEnd from
the other WIP IME input events
Johannes: Same as Michael’s issue \#1. Linked to original solution for
containing composition (issue 34). But in last comment of Masayuki, Firefox
seems to be doing something that isn’t according to spec but is working.
Ollie: why is issue \#34 still open?
Johannes: Different cultures on how to use Github issues. I would normally
close, but others don’t like that.
Ollie: I need until next meeting to figure out what is going on and why
Firefox is not following spec.
### Topic: execCommand
* #### [\#490](https://github.com/w3c/editing/issues/490) Nested editing
hosts do not need to be wrapped in insertParagraph
Ollie: Postpone due to editor being in other meeting.
### Topic: Other
* #### Updated regarding updates on the state of text editing inside Shadow
DOM
Tomasz: We want to know what the status of this is at this stage. We get
selection.getComposedRanges(). Is that all?
Ollie: That might be all. It’s super complicated. I expect browsers to
still have tons of bugs in composed ranges if you cross boundaries, slots,
etc. It’s complicated. Does Chromium have getComposedRanges?
Rohan: Not sure.
Ollie: Webkit had it first. \[...\] Yes, Chromium has it now as well, and
Gecko
Tomasz: Thanks for the information.
* #### Thoughts and updates on spec for content editable.
Rohan: someone from my team may want t talk about.
Rakesh: Where are contenteditable-relevant issues?
Johannes: it depends on which part of contenteditable. Caret Selection will
has a new spec. We used to have a contenteditable but we retired it. Is
there something specific you are looking for?
Rakesh: will collect issues.
Johannes: please collect them, then we will see if it can get to one of the
current specs. If it’s execCommand then it’s already there. We did not
specify a lot of editing behavior because it was getting too complex.
Ollie: This might become a problem for new browser engines like Servo and
Ladybird.
Rohan: Can we have OS specific specs?
Johannes: in the past, if it’s platform convention, then we don’t specify
it. Maybe it’s possible to create OS specific specs (Windows/Mac/Linux).
Ollie: Maybe we can have in a spec different options within the same spec
documents.
… but how do we test these kinds of behaviours? I have looked at the HTML
spec. It doesn’t specify when OSes differ.
[
https://html.spec.whatwg.org/\#sequentially-focusable](https://html.spec.whatwg.org/#sequentially-focusable)
as an example
Rohan: If we try to follow OS behavior, write a note about that in the
specific section where this is relevant.
* #### Spec support for bugs, example: selection and search for CSS
generated content.
Rakesh: same category as previous. \[...\] we should follow behavior as it
is expected on a specific platform.
Johannes: please file issues at [
https://github.com/w3c/editing/issues/](https://github.com/w3c/editing/issues/)
* #### Thoughts on spec guidance for HTML generation to be written to HTML
MIME type on clipboard for any given selection.
Rakesh: whenever we copy we put it into the HTML. I think there is no spec
guidance on how to serialize. Do we keep the styles or do we remove them,
etc. . For example Firefox doesn’t copy the style whereas Chrome does.
Ollie: Clipboard API does talk about sanitization. Safari is trying to
remove some styles, etc. (smaug: I *think*) Firefox does a little bit.
Johannes: Not so helpful if browsers remove information that show that the
content comes from Google Docs. More helpful that they remove hidden
elements that may contain sensitive information.
Ollie: Yeah, but it’s privacy. But what about the new sanitizer. [
https://wicg.github.io/sanitizer-api/](https://wicg.github.io/sanitizer-api/)
Johannes: I’d not be against a really good spec for sanitizer, this means I
don’t have different importers to depend on. The problem is, this is not a
priority for browsers, so most likely I am getting imperfect input.
Rohan: where should be specified
Ollie: I don’t tink it is specified anywhere.
Johannes: Why can you not standardize
Ollie: some of the code is very old.
Ollie: We first need some tests. How do they differ? Then we can determine
whether it is possible to standardize anything.
…
Clipboard: Thoughts on API support for reading the available types on
clipboard.
Rohan User wants to show different buttons for all the types of mimetypes
available on the clipboard
Ollie: I think the existing APi works fine.
Rohan: Not enough because it is dependent on the selective clipboard read
API signature being standardized according to the latest alternative
discussed where the read API signature is not changed. ……
Ollie: That is true. We can do that. We need telemetry data for selective
clipboard reading.
--
Johannes Wilm, PhD
tel +46766922220
https://www.johanneswilm.org
Received on Thursday, 11 December 2025 15:16:43 UTC