meeting notes 2024-03-14

[16:03] <dandclark> scribenick:dandclark
[16:03] <dandclark> topic: https://github.com/w3c/clipboard-apis/issues/191
[16:03] * github-bot Because I don't want to spam github issues
unnecessarily, I won't comment in that github issue unless you write
"Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
[16:04] <dandclark> github: https://github.com/w3c/clipboard-apis/issues/191
[16:04] * github-bot OK, I'll post this discussion to
https://github.com/w3c/clipboard-apis/issues/191 (Read Blob data for the
supported formats on-demand during getType.).
[16:04] <dandclark> snianu: We're still investigating and discussing what
the right approach is
[16:04] <dandclark> johanneswilm: Let's discuss another time
[16:05] <whsieh> https://github.com/w3c/clipboard-apis/issues/137
[16:05] * github-bot Because I don't want to spam github issues
unnecessarily, I won't comment in that github issue unless you write
"Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
[16:05] <whsieh> present+
[16:05] <dandclark> topic: https://github.com/w3c/clipboard-apis/issues/137
[16:05] * github-bot Because I don't want to spam github issues
unnecessarily, I won't comment in that github issue unless you write
"Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
[16:05] <johanneswilm> present+
[16:05] * github-bot Successfully commented on
https://github.com/w3c/clipboard-apis/issues/191
[16:05] <dandclark> github: https://github.com/w3c/clipboard-apis/issues/137
[16:05] * github-bot OK, I'll post this discussion to
https://github.com/w3c/clipboard-apis/issues/137 (Specify order of flavors
exported to macOS's pasteboard).
[16:05] <dandclark> snianu: All 3 browsers have different behaviors
[16:05] <dandclark> ...: Want to standardize the order that formats get
written to clipboard
[16:06] <dandclark> ...: Clients tend to read topmost format, expect that
to have highest fidelity
[16:06] <whsieh> q+
[16:06] <dandclark> ...: Chromium has fixed order, I think FF order is
fixed but it seems to be wrong
[16:06] <dandclark> ...: Custom formats seem to get on the top, image
formats come after HTML
[16:06] <dandclark> ...: Safari I haven't tested personally, someone said
it preserves formats of web author
[16:06] <dandclark> whsieh: We do preserve order, that's intentional
[16:07] <dandclark> ...: Article you pointed out is old. Modern APIs use
NSItemProvider where order does matter. Same as Windows, highest fidelity
are on the top. Devs are expected to go through types in order of fideliety
[16:07] <dandclark> ...: Idea is that richest supported format is the one
they should consume
[16:08] <dandclark> ...: In Safari we preserve order for that purpose
[16:08] <dandclark> snianu: If the web authors write img after text/plain,
and the user pastes in native app, does the it get reordered?
[16:08] <dandclark> whsieh: We preserve order in that case
[16:09] <dandclark> snianu: I wanted to discuss that; I don't know if web
authors are aware that order is important. Would be good to standardize it.
Should we define fixed order?
[16:09] <dandclark> ...: Or leave it up to web authors?
[16:10] <dandclark> smaug: Should leave it up to the webpage authors,
following what Safari's doing. Don't know why Firefox is doing something
else, it's some legacy behavior
[16:10] <dandclark> snianu: FF had some surprising results
[16:10] <dandclark> smaug: chromium's order is also strange
[16:11] <dandclark> ...: We should follow Safari's model here
[16:11] <dandclark> snianu: If we do that, does it affect DataTRansfer APIs?
[16:11] --> sanketj_ (~uid392014@c080ddbb.public.cloak) has joined this
channel.
[16:11] <dandclark> ...: In Chromium we have fixed order for those, would
be hard to have different order based on APIs being used by web authors
[16:12] <dandclark> ...: In browser process where we interact with sys
clipboard, can't know if we should preserve order or the legacy behavior
[16:12] <dandclark> ...: So that could cause breakage if we change it
[16:12] <dandclark> ...: Original issue was opened because of image pasting
issues in Pages and Keynote.
[16:13] <dandclark> ...: I only heard reports of Pages failures with
Firefox. Has anyone investigated why it's failing?
[16:13] <dandclark> ...: Someone commented on issue that order is the
reason the paste failed. But my experience testing Office and Windows
stuff, order matters when pasting images and plaintext.
[16:14] <dandclark> ...: I don't see issues with paste, svg is still pasted
in native app
[16:14] <dandclark> smaug: I wonder if in Windows apps just do different
things vs MacOS
[16:14] <dandclark> smaug: On Windows it's worked the same since Win32
[16:15] <dandclark> (That last comment was snianu, not smaug)
[16:15] <dandclark> smaug: We should investigate if we can follow Safari's
model elsewhere, see what breaks. Hard to know otherwise.
[16:16] <dandclark> snianu: Proposal is to make changes in nightly build in
both APIs? Worried about changing DataTransfer. I'm sure there will be
breakage in Office.
[16:16] <dandclark> smaug: What's the behavior in Safari for DataTransfer?
[16:16] <dandclark> whsieh: Not sure, I think we respect order, if we don't
we should.
[16:16] <dandclark> ...: as we try to align DataTransfer to more modern
async clipboard
[16:16] <dandclark> johanneswilm: Are we proposing spec changes?
[16:17] <dandclark> snianu: Spec says order is specified by web author.
[16:17] <dandclark> ...: but spec is iterating clipboard item, doesn't
define any order there.
[16:17] <dandclark> ...: This order is more from system/OS perspective, if
you mess that up then native app reads lower fidelity format
[16:18] <dandclark> johanneswilm: So that's what we're sticking with, FF
will try this out
[16:18] <dandclark> smaug: It can't be just us
[16:18] <dandclark> ...: Needs to be all browsers on Windows. Also don't
know about Linux
[16:18] <dandclark> snianu: Couldn't find Linux guidance
[16:18] <dandclark> ...: MacOS & Windows, there are specific guidelines
that richest format goes on top
[16:18] <dandclark> smaug: Could be tricky to change if apps rely on
specific behavior on Win
[16:19] <dandclark> sanketj_: Is it defined about which formats are the
most important?
[16:19] <dandclark> smaug: I don't know which is more important. Would
expect maybe HTML because it has more semantic info vs image
[16:19] <dandclark> whsieh: But if you're copying single image...It's
context dependent.
[16:20] <dandclark> johanneswilm: What are we expecting from this meeting?
[16:20] <dandclark> snianu: Was wondering if there's real issue here. If no
then we're hesitant to change anything since this is very fragile.
[16:20] <dandclark> ...: If we break copy/paste with old office apps, very
hard to fix
[16:21] <dandclark> ...: I initially proposed to keep Safari's behavior,
because that's how the spec is written, but thought deeply about how to
make the change in Chromium, ran into this issue that we can't figure what
order the author chose
[16:22] <dandclark> ...: From my own experience here it's very hard to
change.
[16:23] <dandclark> Christine Hollingsworth: Don't have a formal opinion,
would be nice to standardize but only if reasonably possible
[16:23] <dandclark> smaug: Can keep issue open but not be very active
[16:24] <dandclark> sanketj_: If we mark it as closed, say we'll never do
it. Leaving it open says we might do it in future. What new data would be
needed such that we might do it ?
[16:24] <dandclark> smaug: More testing, trying Safari's behaivor on Windows
[16:24] <dandclark> sanketj_: Seems like it was a FF bug, pasting into
Pages. Are you fixing that bug?
[16:25] <dandclark> smaug: That was fixed years ago, looking at what was
changed. Looks like the order was changed
[16:26] <dandclark> ...: But it's not a generic solution, not following
Safari's model. Order is still fixed.
[16:26] <dandclark> sanketj_: You take image to be highest pri?
[16:26] <dandclark> smaug: At least on mac
[16:26] <dandclark> sanketj_: Can you confirm what's your order on
different platforms? We could get inventory on different orders browsers
have today on different platforms
[16:26] <dandclark> ...: Based on that we could figure out what we need to
change to all be spec compliant
[16:27] <dandclark> smaug: Sounds good
[16:27] <dandclark> ...: snianu , smaug , whsieh to document these in the
issue for their respective browsers
[16:27] <dandclark> topic: getTargetRanges of beforeinput differ between
browsers (should not happen in EditContext) #146
[16:27] * github-bot Successfully commented on
https://github.com/w3c/clipboard-apis/issues/137
[16:28] <dandclark> github: https://github.com/w3c/input-events/issues/146
[16:28] * github-bot OK, I'll post this discussion to
https://github.com/w3c/input-events/issues/146 (getTargetRanges of
`beforeinput` differ between browsers (should not happen in EditContext)).
[16:28] <dandclark> johanneswilm: Masayuki thinks EditContext should work
the same for all browsers. Other browser makers say we should be able to
follow conventions on specific platforms.
[16:28] <dandclark> ...: Spec currently says the second, should make it
possible to follow conventions. Chomium implementation has removed target
ranges and not yet put them back, going against the spec.
[16:29] <dandclark> smaug: getTargetRanges says that representing text that
event will modify if event is cancelled. It's only about the text. It's
unclear what target ranges represent if you press delete/backspace and
there is no text
[16:29] <dandclark> johanneswilm: Why is it unclear?
[16:29] <dandclark> smaug: In the input events spec, getTargetRanges talks
about just text, not nodes
[16:30] <dandclark> johanneswilm: yeah, text doesn't seem right, should it
be the content?
[16:30] <dandclark> smaug: But there's no content if selection is collapsed
[16:30] <dandclark> ...: So it's a bit unclear now
[16:31] <dandclark> johanneswilm: What's the part that's not clear? It's
not the selection, it's the part being affected
[16:31] <dandclark> ...: There's no problem of understanding in the
implementations, no implementation has made it work only for text. But I
agree the word 'text' there is not the best
[16:31] <dandclark> ...: Are we moving closer to anything?
[16:31] <dandclark> ...: Masayuki has different view vs Apple
[16:32] <dandclark> ...: Can't have both, either it's working the same
across all browsers or it's making it possible to follow conventions
[16:32] <dandclark> smaug: have you heard feedback in Edge/Chromium
[16:32] <dandclark> johanneswilm: getTargetRanges is important, need to
know which part of grapheme range to delete
[16:34] <dandclark> johanneswilm: Open source projects I know of are
waiting until this has been resolved to build on this
[16:34] <dandclark> dandclark: I haven't heard feedback that pushes us in
one way or another
[16:35] <dandclark> sanketj_: Will we realistically get interop here?
[16:35] <dandclark> johanneswilm: If all browsers return the same yes, but
then we're removing this feature.
[16:36] <dandclark> ...: Won't return same target ranges across all browsers
[16:36] <dandclark> smaug: Interop should always be the goal in some way
[16:36] <dandclark> ...: But I understand there is this platform specific
behavior.
[16:37] <dandclark> sanketj_: Does every browser do exactly what the OS
wants on a given OS?
[16:38] <dandclark> johanneswilm: If I recall, whsieh said there's code in
webkit that behaves differently in Windows, not supported anymore but in
theory it's there. Question is whether Chromium does that.
[16:39] <dandclark> snianu: I made some changes in Chromium for word
deletion for Windows. Behavior was not the same as other native apps like
Word, Notepad. Did change some behavior that was Windows only
[16:39] <dandclark> johanneswilm: So we can say there's some level of that?
[16:39] <whsieh> Looks like Chromium still has this?
https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/core/editing/editing_behavior.h
[16:39] <dandclark> ...: If there's some of that, then we will never get
the same behavior
[16:39] <dandclark> sanketj_: Seems that way to me
[16:39] <whsieh> (the editing behavior is what I had in mind when I
mentioned Safari/windows behavior before)
[16:40] <dandclark> sanketj_: Is the answer do nothing? Agree we can't
standardize that part?
[16:40] <dandclark> johanneswilm: If we can't, then what's the consequence?
I think we should follow the spec as is (re-add target ranges to Chromium)
[16:41] <dandclark> smaug: What's the minimum viable API that editors need?
Can we achieve that in some other way?
[16:41] <dandclark> johanneswilm: Is proposal to only have target ranges
for text certain changes. But the only thing we achieve is some editors
need to have both contenteditable and EditContext around
[16:42] <dandclark> johanneswilm: This would make sense if we could
eventually achieve interop. But otherwise seems we are cutting hole in
feature unnecessarily.
[16:42] <dandclark> johanneswilm: Could we write something in spec so
Firefox doesn't have to implement that part?
[16:42] <dandclark> smaug: That's immediately an interop issue
[16:44] <dandclark> johanneswilm: If you get target ranges you can funnel
the platform conventions without knowing them
[16:50] <dandclark> smaug: On <canvas> target ranges won't work anyway
[16:53] <dandclark> johanneswilm:  Can we get target ranges back, and then
also have a list of the interop differences that we can track and knock
down? Masayuki has done this in the past, let's do more. Some may be
platform issues, some may be bugs.
[16:53] <dandclark> smaug: I will talk to Masayuki
[16:53] <dandclark> smaug: For <canvas> case they presumably already have
code handling this
[16:54] <dandclark> johanneswilm: On <canvas> your document model doesn't
need to follow logic of HTML document
[16:55] <dandclark> johanneswilm: So resolution is smaug  will speak to
Masayuki?
[16:56] <dandclark> sanketj_: Proposal is to keep target ranges in spec,
let Chromium put them back, then Masayuki enumerates specific interop
differences?
[16:56] <dandclark> johanneswilm: Yes, and we can't promise resources but
will try to get browser makers to fix these where possible
[16:56] <dandclark> dandclark: SGTM

-- 
Johannes Wilm, PhD
tel +46766922220
https://www.johanneswilm.org