[Minutes] Editing WG - 2023-12-14

Editing WG

present (this list is missing names): smaug, whsieh, edgar, dandclark, sanketj_, johanneswilm, saschanaz, snianu

6:03 PM scribe: smaug
6:03 PM https://github.com/w3c/input-events/issues/146
6:04 PM getTargetRanges have always been different in browsers in contenteditable
6:04 PM should it work the same way in editcontext
<smaug> smaug: I think we should aim for compatibility whenever possible
<smaug> johanneswilm: counter argument is that one should be able to write platform specific editor
<smaug> johanneswilm: for now, should getTargetRanges work as with contenteditable or empty ranges
<smaug> johanneswilm: I'd prefer the the model getTargetRanges have
6:09 PM whsieh: last time we discussed about accent character characters - so I don't think it makes sense to have the same behavior everywhere. But 
what it the means in context of EditContext I'm less sure about.
<smaug> dandclark:  initially I  was thinking empty array would be ok, but since then I've learned more about the platform conventions
6:11 PM dandclark: let's fix the easy inconsistencies, but other than that, give authors the power to do what they want.
6:13 PM johannes: that wouldn't mean we never change the behavior
<smaug> smaug: if we ship something, it will be hard to fix later
<smaug> dandclark: I don't think we're making it too much harder by having the same behavior with editcontext and contentediable
6:16 PM johanneswilm: empty array would be also confusing for the author
6:16 PM smaug: it could be null value if needed
6:17 PM johanneswilm: target ranges can handle accents, but selection API can't
<smaug> whsieh: it is more about if browser deletes accent or such, that could be standardized, less about os differences
6:23 PM dandclark:  currently in the implementation target ranges is empty for deletion
6:23 PM I'd like to go for non-empty
6:27 PM https://github.com/w3c/clipboard-apis/issues/206
6:27 PM snianu: sanitization behavior is different in browsers
6:28 PM unsanitized would let authors to opt-out
6:29 PM dandclark: since the behavior varies already so much, seems reasonable
6:30 PM snianu: we've been asked to have unsanitized option
6:31 PM snianu: would like to have something in the spec which would be compatible with all the browsers
<smaug> edgar: Gecko probably won't implement that, since we want the align with the old API
6:32 PM but with enhanced privacy mode we could sanitize
<whsieh> FWIW, WebKit has the same stance as FF — same behavior as DT (which sanitizes in WK), so we won't support this optional property
<smaug> snianu: we'd like to have flexibility in browser implementations
6:35 PM whsieh: we want to align with our legacy API.
6:36 PM whsieh: this sounds reasonable, but we don't need option to let authors to know if sanitization is supported
— •dandclark "pleaseUnsanitizeIfYouWant"
<smaug> smaug: It is confusing if the property name hints about unsanitization  and that doesn't happen
<smaug> edgar: problem is the inconsistency with the legacy API
<smaug> whsieh: author shouldn't ever expect certain markup
6:43 PM snianu: want to make sure all the behaviors are documented
6:44 PM snianu: we can add non-normative note
6:45 PM johanneswilm: ...so that you cover web authors who are not on mac/safari
6:46 PM smaug: we're ok with this
6:46 PM whsieh: we as well
6:47 PM https://github.com/w3c/clipboard-apis/issues/207
<smaug> saschanaz: pr landed to spec without consensus
<smaug> saschanaz: we need to ensure pr has consensus from 2 different implementations
6:52 PM edgar: and standards positions aren't resolved
6:53 PM smaug: right now we can fix the issue by doing what we agreed on 206
6:54 PM pr 197 was merged without consensus and that will be fixed in issue 206
6:54 PM smaug: we should avoid landing PRs without consensus
6:55 PM sanketj_: point taken
6:56 PM https://github.com/w3c/editing/issues/423
6:56 PM snianu: documented in the latest comment various API shapes
6:59 PM smaug: could we let one to use streams
7:01 PM with stream we could avoid quite a memory overhead
7:01 PM snianu: can we get resolution on having callback
7:02 PM resolution to have callback
7:02 PM johanneswilm: will try to have another meeting next week, same time
7:03 PM focus on the target ranges issue

Received on Friday, 15 December 2023 20:51:09 UTC