[Minutes] Editing WG - 2026-02-12

08:01 <whsieh> issue: https://github.com/w3c/editing/issues/527
08:03 <whsieh> johanneswilm: reconnect over email with Rakesh
08:03 <dandclark> present+
08:03 <comandeer> present+
08:03 <whsieh> johanneswilm: see Dominic's comments in https://github.com/w3c/strategy/issues/522#issuecomment-3851619317
08:04 <whsieh> Rakesh: don't have opinion as of today, would just want to go through and look through current status of VK API (in what state it is today)
08:05 <whsieh> johanneswilm: could you make sure someone answers in the strategy issue? (https://github.com/w3c/strategy/issues/522)
08:05 <whsieh> johanneswilm: (blocks rechartering)
08:05 <whsieh> Rakesh: is anyone actively looking to making any changes in the spec immediately?
08:05 <whsieh> johanneswilm: this is about chartering
08:05 <whsieh> johanneswilm: (every 2 years)
08:06 <whsieh> johanneswilm: so, this is mainly informative. would be good to get response in next 2 weeks
08:06 <whsieh> issue: https://github.com/w3c/editing/issues/523
08:07 <whsieh> michael_aufreiter: issue here is that if you use down arrow keys, absolutely positioned elements are skipped
08:07 <whsieh> michael_aufreiter: masayuki called out https://bugzilla.mozilla.org/show_bug.cgi?id=1877425
08:08 <whsieh> michael_aufreiter: should this be specified?
08:08 <whsieh> johanneswilm: this seems like something that seems like a good candidate for the new caret movement spec
08:09 <whsieh> michael_aufreiter: down arrow movement seems like a bug in FF because behavior is inconsistent with other arrow keys
08:09 <whsieh> michael_aufreiter: should left/right arrow keys address visually? or in document order..
08:09 <whsieh> smaug: yep, sounds like browser bug
08:10 <Rakesh> I don't seem to have access to add agenda+ label, I wanted to add to the queue today: https://github.com/w3c/clipboard-apis/issues/244
08:10 <whsieh> (..that masayuki filed)
08:11 <whsieh> next issue: https://github.com/w3c/editing/issues/516
08:11 <whsieh> WK bugs have been filed
08:11 <whsieh> michael_aufreiter: would be good to have an idea of progress..
08:11 <whsieh> q+
08:12 <whsieh> whsieh: what should we prioritize?
08:12 <whsieh> michael_aufreiter: we'll help prioritize
08:12 <whsieh> johanneswilm: okay, no need to go through all of these
08:14 <whsieh> johanneswilm: let's make a tag for the caret movement issue
08:14 <whsieh> johanneswilm: would be good to connect these bugs/issues to the spec issue
08:15 <whsieh> johanneswilm: would help explain/demonstrate the purpose of the caret movement spec
08:15 <whsieh> johanneswilm: PrivacyWG — wondering if we work on collaborative editors
08:16 <whsieh> johanneswilm: spec relates to collaborative editing, but nothing in the spec expressly for it
08:16 <whsieh> johanneswilm: (communication protocols for the "collaboration" part are outside the scope of the editing spec)
08:16 <whsieh> smaug: it's a bit confusing, because if we aren't dealing with it then why is it mentioned in the spec
08:17 <whsieh> johanneswilm: it's sort of related because it's one common application of editors on the web. but yes, we don't deal with communication protocols
08:18 <whsieh> johanneswilm: path of least resistance seems to be putting the words "collaborative editor" somewhere in there
08:18 <whsieh> issue: https://github.com/w3c/clipboard-apis/issues/242
 <https://github.com/w3c/clipboard-apis/issues/242>08:19 <whsieh> Rakesh: the issue is that MIME types should not have spaces
08:19 <whsieh> Rakesh: but the spec requires a space due to "web …"
08:20 <whsieh> Rakesh: we should not allow spaces in MIME types, unless it's a custom MIME type on the web ("web ")
08:21 <whsieh> Rakesh: browser engines would need to throw an error in the ClipboardItem ctor
08:21 <whsieh> smaug: this is a question of web compat
08:21 <whsieh> smaug: probably okay? but there is compat implication
08:21 <whsieh> smaug: the spec already has the exception for the "web" prefix
08:22 <whsieh> dandclark: maybe we need to look at the data? (use data)
08:22 <whsieh> dandclark: collect data and see how common this is
08:22 <whsieh> johanneswilm: so what are the next steps? spec doesn't need changes, just align implementations
08:23 <whsieh> dandclark: proposal: add use counter in Chromium side to estimate compat impact
08:23 <whsieh> dandclark: if we find this is common on the web maybe we should revisit this
08:23 <whsieh> Rakesh: we are silently failing today in those cases
08:23 <whsieh> rohan: the ctor would run fine, but the actual write() call would fail
08:24 <whsieh> Rakesh: was trying to understand adding telemetry — we are already silently failing, so is there a real compat concern?
08:25 <whsieh> rohan: can't think of any scenario where developer would be relying on a mime type with a space
08:25 <whsieh> rohan: the unfortunate bit is that the spec tests are passing right now when they shouldn't, according to spec
08:25 <whsieh> rohan: maybe we can at least fix WPT?
08:25 <whsieh> smaug: IDK, websites do weird things
08:26 <whsieh> smaug: adding telemetry/use counter would be a good next step
08:26 <whsieh> Rakesh: seems fine to me
08:27 <whsieh> whsieh: makes sense to me too
08:27 <whsieh> johanneswilm: telemetry in Chromium, then we will discuss later with data
08:27 <whsieh> issue: https://github.com/w3c/clipboard-apis/issues/244
08:28 <whsieh> Rakesh: should we standardize the source URL?
08:29 <whsieh> whsieh: is this in the scope of a spec? or just platform behavior
08:29 <whsieh> Rakesh: standardization means all browsers know they need to care about this
08:29 *** rohan (~rohan@b6520e17.publics.cloak) has quit (rohan)
08:31 <whsieh> whsieh: MIME type as a clipboard data type isn't a thing on Cocoa platforms
08:32 <whsieh> q+
08:34 <whsieh> whsieh: can we say something like, "use platform APIs to specify source URL, otherwise fall back to a common UTI on Cocoa platforms, or MIME type on Linux/Windows"
08:34 <whsieh> Rakesh: we'll agenda+ again once we have draft
08:35 <whsieh> issue: https://github.com/w3c/clipboard-apis/issues/240
08:36 <whsieh> rohan: second approach (engine reads lazily) is more favorable since all websites would get the benefit
08:36 <whsieh> rohan: however, I wanted to raise concern from API perspective
08:37 <whsieh> rohan: right now ClipboardItem ctor acts as "frozen bag of data"
08:37 <whsieh> rohan: however, once you do a read() you no longer get "frozen data", but a live reference to OS state
08:37 <whsieh> rohan: might create confusion for web devs
08:38 <whsieh> rohan: ...since clipboard items obtained via read behave differently than items created when writing
08:39 <whsieh> smaug: I think it still makes sense (the lazy item read() behavior)
08:39 <whsieh> smaug: it's kinda just how the clipboard works
08:39 <edgar> q+
08:40 <whsieh> Rakesh: seems like a fair tradeoff?
08:40 <whsieh> smaug: not really a tradeoff, just makes sense
08:40 <whsieh> edgar: there's also a proposal about the clipboard change event
08:40 <whsieh> edgar: we know the clipboard changed at a specific time, so developers who really need to handle this item change case can respond accordingly
08:42 <whsieh> rohan: the question is, should the browser invalidate the clipboard item when its content changes
08:43 <Rakesh> q+  want to take opinions on returning no data(failing silently) vs throwing exception
08:43 <whsieh> johanneswilm: is the concern with JS authors that keep items around
08:44 <whsieh> rohan: yes
08:44 <whsieh> smaug: I thought we'd be taking WK's current behavior?
08:44 <whsieh> (yes)
08:44 <Rakesh> yes
08:45 <whsieh> johanneswilm: WK has this behavior of invalidating already, so if there have not been issues with it then probably it's fine
08:45 <whsieh> Rakesh: wanted to discuss — returning no data(failing silently) vs throwing exception
08:46 <whsieh> Rakesh: would it help to fail silently?
08:46 <whsieh> johanneswilm: but this means they might not discover the bug
08:46 <whsieh> johanneswilm: (whereas with exception if someone were depending on it, they'd know)
08:47 <whsieh> smaug: the end user wouldn't want the stale data to persist in this case
08:48 <whsieh> Rakesh: how would developer distinguish between clipboard having *no* data vs. clipboard item being stale
08:48 <whsieh> smaug: clipboard change event
08:48 <whsieh> dandclark: can I write the empty string today?
08:48 <whsieh> shweta: it's actually valid to write empty string
08:49 <whsieh> dandclark: can't tell between actual empty string vs. empty string due to staleness
08:49 <whsieh> dandclark: rather they'd need to use clipboard change event to do sio
08:49 <whsieh> dandclark: so it seems better to throw here vs. fail silently
08:49 <whsieh> (to make distinction b/t the two cases)
08:50 <whsieh> whsieh: I think we throw rn
08:50 <whsieh> (in WK)
08:50 <whsieh> dandclark: would be good to double check behavior
08:51 <whsieh> shweta: the error in Safari currently doesn't say "clipboard changed", just a generic "not allowed"
08:51 <whsieh> dandclark: maybe this should be implement ion-defined?
08:52 <whsieh> whsieh: we could probably provide a more descriptive error in WK
08:53 <whsieh> johanneswilm: if JS is depending on it, then there's probably something wrong with their code anyways...
08:53 <whsieh> johanneswilm: would be more practical to explain what's wrong
08:54 <whsieh> dandclark: exception type should be consistent, the error detail can be more specific
08:54 <whsieh> johanneswilm: where would this be specified?
08:54 <whsieh> rohan: should be in getType()
08:55 <whsieh> johanneswilm: explanatory note would be helpful there
08:55 <whsieh> dandclark: I think we also need normative text for this
08:56 <whsieh> johanneswilm: so: (1) normative spec change, (2) explanatory note, (3) change in Chromium/Gecko to align
08:56 <whsieh> issue: https://github.com/w3c/input-events/issues/177
08:57 <whsieh> johanneswilm: rfc from Rakesh in https://github.com/w3c/input-events/issues/177#issuecomment-3891642650
08:57 <whsieh> Rakesh: I'll provide an update for next month
08:57 <whsieh> issue: https://github.com/w3c/input-events/issues/176
08:58 <whsieh> johanneswilm: need input from Mozilla
08:58 <whsieh> smaug: probably need to ping masayuki
08:59 <whsieh> smaug: what's the exact q?
08:59 <michael_aufreiter> whsieh I selected 3 issues to prioritize for the webkit team to work on next (the ones that have the Agenda+ label now): https://github.com/w3c/editing/issues?q=is%3Aissue%20label%3Abug-reports-filed%20label%3AAgenda%2B
08:59 <whsieh> johanneswilm: in FF you have an extra beforeinput event that's not according to spec, but makes sense to Masayuki
08:59 <whsieh> michael_aufreiter: ty!
09:00 <whsieh> johanneswilm: will add needs feedback from MS