minutes, June 2024

[17:01] <comandeer> present+
[17:01] <dandclark> scribe: dandclark
[17:01] <dandclark> topic: Write UTF-8 data to the clipboard.
[17:01] <dandclark> github: https://github.com/w3c/clipboard-apis/issues/217
[17:01] * github-bot OK, I'll post this discussion to
https://github.com/w3c/clipboard-apis/issues/217 (Write UTF-8 data to the
clipboard.).
[17:02] <sanketj_> present+
[17:02] <johanneswilm> present+
[17:02] <dandclark> snianu: Recently we found in Chromium that when we copy
svg (chromium supports img/svg), we switch encoding from utf-8 to utf-16
[17:02] <dandclark> ...: When we paste in native apps like Word, the image
doesn't render
[17:02] <dandclark> ...: It's because the native apps expect utf-8
[17:03] <dandclark> ...: We investigated, found in the spec that when we
write blobs to system clipboard, spec says use utf-8 decoder, write scalar
values to system clipboard
[17:03] <dandclark> ...: Trying to get feedback on whether to change the
spec
[17:03] <dandclark> ...: Or are there corner cases we're missing like for
PNG
[17:04] <dandclark> smaug: I think what Anne noticed is a clear bug
[17:04] <-- comandeer (~comandeer@e2f177d0.publics.cloak) has left this
server (public-irc.w3.org public-ircs.w3.org).
[17:04] <-- whsieh (~whsieh@e2f177d0.publics.cloak) has left this server (
public-irc.w3.org public-ircs.w3.org).
[17:04] <-- christinesm (~christinesm@e2f177d0.publics.cloak) has left this
server (public-irc.w3.org public-ircs.w3.org).
[17:04] <-- github-bot (~dbaron-gh-bot@e2f177d0.publics.cloak) has left
this server (public-irc.w3.org public-ircs.w3.org).
[17:04] <-- tilgovi (~sid22172@e2f177d0.publics.cloak) has left this server
(public-irc.w3.org public-ircs.w3.org).
[17:04] <dandclark> snianu: Is there a specific encoding rule that FF or
Safari follow when writing formats? Or is it whatever encoding is in the
blob type?
[17:04] --> comandeer (~comandeer@e2f177d0.publics.cloak) has joined this
channel.
[17:04] --> whsieh (~whsieh@e2f177d0.publics.cloak) has joined this channel.
[17:04] --> christinesm (~christinesm@e2f177d0.publics.cloak) has joined
this channel.
[17:04] --> github-bot (~dbaron-gh-bot@e2f177d0.publics.cloak) has joined
this channel.
[17:04] --> tilgovi (~sid22172@e2f177d0.publics.cloak) has joined this
channel.
[17:04] <dandclark> smaug: I can't recall
[17:04] <-- tilgovi (~sid22172@e2f177d0.publics.cloak) has left this server
(public-irc.w3.org public-ircs.w3.org).
[17:04] <-- github-bot (~dbaron-gh-bot@e2f177d0.publics.cloak) has left
this server (public-irc.w3.org public-ircs.w3.org).
[17:04] <-- christinesm (~christinesm@e2f177d0.publics.cloak) has left this
server (public-irc.w3.org public-ircs.w3.org).
[17:04] <-- whsieh (~whsieh@e2f177d0.publics.cloak) has left this server (
public-irc.w3.org public-ircs.w3.org).
[17:04] <-- comandeer (~comandeer@e2f177d0.publics.cloak) has left this
server (public-irc.w3.org public-ircs.w3.org).
[17:05] <dandclark> ...: I'll take a look
[17:05] <dandclark> anne: I think there may be sanitization taking place
but don't think we can apply any text encoding because format can be
arbitrary
[17:05] <dandclark> ...: Those need to be byte strings
[17:05] <dandclark> s/strings/streams
[17:05] <dandclark> ...: The one thing we might want to do is sanitization
based on the type
[17:05] <dandclark> ...: Can be OS-specific mapping but spec doesn't have
to cover that
[17:06] --> comandeer (~comandeer@e2f177d0.publics.cloak) has joined this
channel.
[17:06] --> whsieh (~whsieh@e2f177d0.publics.cloak) has joined this channel.
[17:06] --> github-bot (~dbaron-gh-bot@e2f177d0.publics.cloak) has joined
this channel.
[17:06] --> tilgovi (~sid22172@e2f177d0.publics.cloak) has joined this
channel.
[17:06] <dandclark> ...: E.g. if your OS has image-specific backing store
you do some additional transformation
[17:06] <dandclark> snianu: Agree. I read in Apple documentation it's
default UTF-16 but can use others
[17:06] <dandclark> ...: Agree for images it doesn't make sense , for other
MIME types like svg and HTML, does it make sense to write UTF-8?
[17:07] <dandclark> ...: Windows has separate APIs for UTF and ASCII
characters
[17:07] <dandclark> ...: I think there's lots of different cases and
encoding schemes
[17:07] <dandclark> ...: Don't know if makes sense to standardize it
[17:07] <dandclark> ...: Because it's also platform specific
[17:07] <dandclark> anne: The one thing you could maybe do is abstract
between text and byte sequence types
[17:08] <dandclark> ...: For text sequence types, always do UTF pass so you
always get scalar values
[17:08] <dandclark> ...: Is interesting question what platforms currently
do. If you put zero-bytes in text stream, do you get zero-bytes or
replacement chars?
[17:08] <dandclark> snianu: For the existing spec text, do we all agree
it's not valid and we should remove it?
[17:09] <dandclark> ...: And may be do investigation to see what can be
added to the spec, maybe as a note?
[17:09] <dandclark> anne: Reasonable to remove UTF-8 step and then
investigate
[17:09] <dandclark> smaug: Might be useful to see why we have the UTF-8
thing in the spec
[17:09] <dandclark> anne: Good to do blame analysis, I didn't yet
[17:09] <dandclark> smaug: It's very specific, might be something
interesting mentioned in spec issue somewhere
[17:10] <dandclark> johanneswilm: Is there agreement?
[17:10] <dandclark> johanneswilm: It's always either bytes or UTF-8? Any
risk of other older encodings?
[17:11] <-- whsieh (~whsieh@e2f177d0.publics.cloak) has left this server.
[17:12] <dandclark> anne: It's another interesting question. It's why I
think bytes are the answer and we need to investigate further.
[17:12] <dandclark> johanneswilm: Who will  file follow up issue?
[17:12] <dandclark> snianu: I can
[17:13] <dandclark> RESOLVED: Remove the bullet about UTF-8 encoding.
Anupam to file follow up issue to investigate what happens when you try to
send invalid UTF chars though.
[17:13] <dandclark> topic: getTargetRanges of beforeinput differ between
browsers (should not happen in EditContext)
[17:13] * github-bot Successfully commented on
https://github.com/w3c/clipboard-apis/issues/217 and UNABLE TO REMOVE LABEL
"Agenda+" due to error: HttpError { status: 403, headers: {"server":
"GitHub.com", "date": "Thu, 13 Jun 2024 15:13:30 GMT", "content-type":
"application/json; charset=utf-8", "content-length": "160",
"x-oauth-scopes": "public_repo", "x-accepted-oauth-scopes": "",
"x-github-media-type": "github.v3; format=json", "x-github-api-[CUT]
[17:13] * github-bot elected": "2022-11-28", "x-ratelimit-limit": "5000",
"x-ratelimit-remaining": "4997", "x-ratelimit-reset": "1718294509",
"x-ratelimit-used": "3", "x-ratelimit-resource": "core",
"access-control-expose-headers": "ETag, Link, Location, Retry-After,
X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used,
X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes,
X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-[CUT]
[17:13] * github-bot e, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation,
Sunset", "access-control-allow-origin": "*", "strict-transport-security":
"max-age=31536000; includeSubdomains; preload", "x-frame-options": "deny",
"x-content-type-options": "nosniff", "x-xss-protection": "0",
"referrer-policy": "origin-when-cross-origin,
strict-origin-when-cross-origin", "content-security-policy": "default-src
'none'", "vary": "Accept-Encoding, Accept, X-Re[CUT]
[17:13] * github-bot ith", "x-github-request-id":
"E22E:6E080:190D0B9:2EF12DF:666B0C9A"}, error: "{\"message\":\"Must have
admin rights to Repository.\",\"documentation_url\":\"
https://docs.github.com/rest/issues/labels#remove-a-label-from-an-issue\",\"status\":\"403\"}"
}
[17:13] <dandclark> github: https://github.com/w3c/input-events/issues/146
[17:13] * 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)).
[17:13] <dandclark> smaug: I think Masayuki is more positive on having
getTargetRanges
[17:14] <dandclark> smaug: He's happy to expose the differences because
platforms have different behaviors. That's how I interpret his statement on
this. I will confirm.
[17:14] <dandclark> ...: Should I file new issue to add getTargetRanges?
[17:15] --> snianu (~snianu@e2f177d0.publics.cloak) has joined this channel.
[17:15] <snianu> present+
[17:15] <dandclark> I to confirm with masayuki and reply
[17:16] <dandclark> topic: normative spec changes do not always end up as
issues filed with browsers
[17:16] * github-bot Successfully commented on
https://github.com/w3c/input-events/issues/146
[17:16] <dandclark> github: https://github.com/w3c/editing/issues/463
[17:16] * github-bot OK, I'll post this discussion to
https://github.com/w3c/editing/issues/463 (normative spec changes do not
always end up as issues filed with browsers).
[17:16] <dandclark> johanneswilm: There was a change in input-events we
agreed on, but it didn't end up in Apple's bug tracker
[17:17] <dandclark> ...: To fix this Marcos proposed PR template
[17:17] <dandclark> ...: Discussion is longer than just what's in this issue
[17:17] <dandclark> ...: Question is should we have a template, or change
how we work on these specs?
[17:18] <dandclark> sanketj_: Whenever we make normative changes, should we
file implementation bug? I think that's reasonable
[17:18] <dandclark> sanketj_: Could resolve on that.
[17:19] <dandclark> johanneswilm: For those specifications which are
implemented in browsers to a reasonable extend, we add such a template to
ensure for each change there are bugs filed.
[17:19] <dandclark> ...: What we should not do is add this to more
experimental specs where it's not clear if they will be implemented. Maybe
on the way but not implemented yet.
[17:19] <dandclark> ...: Or may never be.
[17:19] <dandclark> sanketj_: That's fair. Do you mean selection API spec
specifically?
[17:20] <dandclark> johanneswilm: As I understand it we should have a
distinction. execCommand spec you can't rely on it being implemented.
[17:20] <dandclark> ...: Many things would need to change for it to reflect
actual implementations
[17:21] <dandclark> ...: We can go spec by spec. For selection API, ryosuke
is editor. Communication so far is it's not where there is consensus on
every change.
[17:22] <dandclark> johanneswilm: We should not tie Ryosuke or Simon's
hands when it's not clear spec is implemented. When they get to stage where
want consensus, two implementations, then we can have template
[17:22] <dandclark> smaug: Who owns that spec
[17:22] <dandclark> johanneswilm: Spec says webapps, our charter says we
own it. So I assume it is here.
[17:23] <dandclark> smaug: That one has been implemented in all browsers,
so we should be filing bugs. That would have caught this recent issue.
[17:23] <dandclark> sanketj_: +1 to what Olli is saying
[17:23] <dandclark> sanketj_: Chromium will be working on that in the near
future. Important to get impl bugs filed.
[17:23] <dandclark> ...: And it will be useful to discuss in this WG
[17:24] <dandclark> smaug: getComposedRange is broken, needs massive changes
[17:24] <dandclark> johanneswilm: If that's the state it's at we should
have those discussions here.
[17:24] <dandclark> Wenson: Has there been movement on this spec?
[17:24] <dandclark> smaug: It was just changed
[17:25] <dandclark> anne: We'll take it back to Ryosuke
[17:25] <smaug> https://github.com/w3c/selection-api/issues/170 was a
recent change
[17:25] * 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: ...").
[17:25] <dandclark> johanneswilm: Can we agree on the principle of making
distinction between specs that are ready that should have template, and
potentially others like execCommand that are not there?
[17:25] <dandclark> ...: Cannot force on all specs that all changes are
implementable
[17:26] <dandclark> anne: Having a whatwg style template is a good idea
[17:26] <dandclark> ...: Want bugs and tests, potentially more things
[17:27] <dandclark> sanketj_: Can always file bugs, even if they don't
implement the spec
[17:28] <dandclark> johanneswilm: But say with EditContext, only
implemented in Chromium. What does the template include? A link to specific
issue for Chromium, then a link to general issue for both Webkit, Gecko
saying "implement EditContext"?
[17:28] <dandclark> sanketj_: Yeah
[17:28] <dandclark> sanketj_: At some point the other browsers will start
implementing
[17:29] <dandclark> sanketj_: Once one engine ships, it's much harder to
make changes
[17:29] <dandclark> ...: There's higher risk of breaking changes. E.g. with
getComposedRanges
[17:29] <dandclark> ...: if we wait for 2 implementers, might be too late
[17:29] <dandclark> smaug: So need at least 2 implementers for any change
[17:30] <dandclark> ...: Would like have no objections also, though I know
that's not in charter
[17:30] <dandclark> johanneswilm: I agree it makese sense for EditContext
to have that now, but for several years it was microsoft internal thing
[17:31] <dandclark> ...: Wanted to start getting more consensus as it
started to ship.
[17:31] <dandclark> ...: But to need that consensus from the start, may not
be helpful.
[17:32] <dandclark> smaug: Have proposal for the new specific case, any
changes to the proposal need to get approval. Exactly the model EditContext
has now
[17:32] <dandclark> johanneswilm: Should we say we can add such a template
to all repos that are implemented in various browsers? can take them one by
one.
[17:33] <dandclark> sanketj_: At what point do we start filing
implementation bugs?
[17:33] <dandclark> johanneswilm: There's a w3c procedure.
[17:33] <dandclark> ...: There's incentive to start getting consenus, we
all want these things to be implemented everywhere
[17:34] <dandclark> ...: We can make this more formal with template
[17:34] <dandclark> smaug: Even more important that impl bugs, is to have
template saying these implementers are OK with this.
[17:35] <dandclark> johanneswilm: And this is at the stage where things are
no longer experimental?
[17:35] <dandclark> smaug: EditContext isn't now
[17:36] <dandclark> johanneswilm: But we can continue to have ideas that
don't end up being real specification or aren't implemented
[17:36] <dandclark> smaug: Yeah
[17:37] <dandclark> sanketj_: So when an explainer gets accepted by WG,
that's the starting point. Once one implementer has shipped, should start
filing impl bugs. One master bug for implementing, and specific bugs for
specific bugs on browsers that have implemented.
[17:38] <dandclark> smaug: Need interest from two implementers, no
objections
[17:38] <dandclark> sanketj_: No objection has been a problem in the past.
Can be reasons browser can't implement spec.
[17:39] <dandclark> johanneswilm: Explainer was filed at very beginning.
Another case, the UndoManager proposal explainer. Filed years ago. If they
put resources on it, makes no sense for them to need consensus on every
little PR.
[17:39] <dandclark> ...: There are no code examples, need to go much
further for it to be something to work with.
[17:40] <dandclark> ...: The explainer stage is too early
[17:40] <dandclark> smaug: I would expect explainer to be something you
could roughly implement
[17:41] <dandclark> johanneswilm: Explainers for UndoManager, EditContext
were years away from being implementable
[17:42] <dandclark> johanneswilm: For EditContext there was a big gap
between the explainer and a more concrete spec and implementation. All of
that first phase, it would have been too complex to have gone through this
process every time.
[17:43] <dandclark> johanneswilm: Can we just go through the specs now and
decide? Don't need to make a principled decision about when to add for new
proposals.
[17:44] <dandclark> Wenson: Sounds to me like if there's intent to actually
ship, that's the difference
[17:44] <dandclark> sanketj_: Sounds reasonable
[17:45] <dandclark> johanneswilm: Should our action be - file an issue with
each of our repos to add such a template if appropriate. If not
appropriate, maintainer of spec can say so.
[17:46] <dandclark> sanketj_: What's the content of the template?
[17:46] <dandclark> sanketj_: Someone tried to add one, is that what we
should use?
[17:46] <dandclark> ...: It was "at least 2 implementers, none object"
[17:46] <dandclark> johanneswilm: Can't say that, have to follow charter.
[17:49] <smaug> https://github.com/w3c/clipboard-apis/pull/215 is the one
for clipboard
[17:49] * 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: ...").
[17:49] <-- comandeer (~comandeer@e2f177d0.publics.cloak) has left this
server.
[17:49] <-- snianu (~snianu@e2f177d0.publics.cloak) has left this server.
[17:52] <smaug> Just some random example from WhatWG
https://github.com/whatwg/html/pull/7934
[17:52] * 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: ...").
[17:54] <dandclark> Proposed resolution: File issues on each repo to add a
PR template if appropriate. For specs where it's not clear, ask the
Editors. Contents of template don't include "at least 2 implementers, none
object", but do include links to implementation bugs, and checkbox that
there has been consensus in WG for the change. Start with a PR on
EditContext spec, where all members of the group get a chance to review.
Issues on other specs can
[17:54] <dandclark> reference that template.
[17:55] <dandclark> Proposed resolution: File issues on each repo to add a
PR template if appropriate. For specs where it's not clear, ask the
Editors. Contents of template include a checkbox for 2 implementers are
interested, links to implementation bugs, and checkbox that there has been
consensus in WG for the change. Start with a PR on EditContext spec, where
all members of the group get a chance to review. Issues on other specs can
reference that
[17:55] <dandclark> template.
[17:55] <dandclark> RESOLVED: File issues on each repo to add a PR template
if appropriate. For specs where it's not clear, ask the Editors. Contents
of template include a checkbox for 2 implementers are interested, links to
implementation bugs, and checkbox that there has been consensus in WG for
the change. Start with a PR on EditContext spec, where all members of the
group get a chance to review. Issues on other specs can reference that
template.
[17:56] <dandclark> Sanket or Dan to add the PR on the EditContext spec.

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