16:03:07 <RRSAgent> RRSAgent has joined #webdriver
16:03:12 <RRSAgent> logging to https://www.w3.org/2026/05/13-webdriver-irc
16:03:12 <jimevans> jimevans has joined #webdriver
16:03:12 <odejesush999485> odejesush999485 has joined #webdriver
16:03:12 <JohnJansen> JohnJansen has joined #webdriver
16:03:12 <alice> alice has joined #webdriver
16:03:12 <cb> cb has joined #webdriver
16:03:17 <Zakim> Zakim has joined #webdriver
16:03:45 <tidoust> RRSAgent, make logs public
16:04:01 <orkon> present+
16:04:12 <tidoust> present+
16:04:20 <jgraham> Meeting: WebDriver
16:04:43 <whimboo> present+
16:04:55 <jgraham> Agenda: https://www.w3.org/wiki/WebDriver/2026-05-BiDi#Agenda
16:05:13 <jimevans> jimevans has joined #webdriver
16:05:13 <odejesush999485> odejesush999485 has joined #webdriver
16:05:13 <JohnJansen> JohnJansen has joined #webdriver
16:05:13 <alice> alice has joined #webdriver
16:05:13 <cb> cb has joined #webdriver
16:05:27 <sasha> present+
16:05:31 <tidoust> scribe+
16:05:36 <jgraham> ScribeNick: tidoust
16:05:37 <jdescottes> present+
16:05:44 <jgraham> present+
16:06:05 <lauromoura> present+
16:06:08 <mradbourne> mradbourne has joined #webdriver
16:06:10 <jgraham> Topic: Screencasting API spec without JS primitives
16:06:30 <jgraham> github: https://github.com/w3c/webdriver-bidi/pull/1113
16:06:56 <jimevans> jimevans has joined #webdriver
16:06:56 <odejesush999485> odejesush999485 has joined #webdriver
16:06:56 <JohnJansen> JohnJansen has joined #webdriver
16:06:56 <alice> alice has joined #webdriver
16:06:56 <cb> cb has joined #webdriver
16:06:56 <AutomatedTester> AutomatedTester has joined #webdriver
16:07:04 <jgraham> present+
16:07:35 <tidoust> sasha: Wanted to update the group. During the screencast review, we found out that specifying it with using the JavaScript primitives from the MediaCapture spec is quite difficult for the moment.
16:07:50 <tidoust> ... We decided to put up a proposal without leveraging them.
16:07:54 <AutomatedTester> present+
16:08:09 <tidoust> ... That makes the proposal a bit more vague. To be revisited when we work on the streaming version of it.
16:08:26 <jgraham> q?
16:08:39 <tidoust> ... Feedback welcome on the PR.
16:09:06 <Euclid> Euclid has joined #webdriver
16:09:09 <jgraham> Topic: Add download ID field to download events
16:09:23 <jgraham> github: https://github.com/w3c/webdriver-bidi/pull/1117
16:09:58 <jgraham> RRSAgent: make logs public
16:10:11 <tidoust> sasha: The load event only has navigation ID, which is fine for most cases. In the case when it's not present, it makes it impossible to link start/end loading events.
16:10:34 <tidoust> s/load/download
16:10:55 <tidoust> ... I created a PR for that which shouldn't be controversial. Comments welcome.
16:11:09 <orkon> q+
16:11:15 <Euclid> present+
16:11:18 <jgraham> ack next
16:11:19 <tidoust> ack orkon
16:11:39 <tidoust> orkon: I think it looks fine and that we should have a download ID. I'll take another look next week.
16:12:34 <jgraham> Topic: Get Element Tag Name case inconsistencies
16:12:48 <jgraham> github: https://github.com/w3c/webdriver/issues/1956
16:12:57 <tidoust> jdescottes: A WebDriver classic topic.
16:13:48 <tidoust> ... We have Get Element Tag Name that's supposed to return upper case, but some implementations have returned lowercase, while others have returned uppercase.
16:14:17 <Euclid> q+
16:14:18 <tidoust> ... Should we rather try to change the spec to return lowercase? Or should we make it a bit more vague and say it can be fine to return either?
16:14:29 <whimboo> q+
16:14:31 <jgraham> ack next
16:14:52 <tidoust> Euclid: First time here!
16:15:19 <tidoust> ... I was wondering why Servo wasn't passing this test. Only Safari is doing it correctly. Is that what we're discussing here?
16:15:21 <tidoust> [yes]
16:15:41 <jgraham> ack next
16:16:14 <tidoust> whimboo: Would be good to get feedback from Apple.
16:16:21 <tidoust> ... Hopefully, they'll get back to us.
16:16:50 <tidoust> ... Regarding Servo, it shouldn't be a problem. Chrome and Firefox have been returning lowercase for years.
16:17:13 <tidoust> ... I don't know if tag names can mix lowercase and uppercase characters.
16:17:34 <jdescottes> q+
16:17:41 <jgraham> ack next
16:18:22 <tidoust> jdescottes: Whether it's JS APIs or DOM, it's always exposed as uppercase.
16:18:32 <orkon> q+
16:18:38 <jgraham> ack next
16:19:45 <AutomatedTester> q+
16:19:46 <tidoust> orkon: Trying to check why we return lowercase. To me, we should align with Web APIs, and find a way to roll this out. Do we know any client that specifically rely on this behavior and that we would break?
16:19:47 <jgraham> q+
16:19:55 <jgraham> ack next
16:19:59 <tidoust> ack AutomatedTester
16:21:03 <tidoust> AutomatedTester: A lot of it is historical. We had to normalize it and decided to normalize it to lowercase. If we go from lowercase to uppercase, most projects probably handle that on the client side so end users would not notice the difference.
16:21:08 <jgraham> ack next
16:21:45 <tidoust> jgraham: DOM does not seem to do case folding for non-HTML elements.
16:22:10 <tidoust> ... I think it's absolutely certain that someone is doing a test somewhere that expects the behavior.
16:22:39 <tidoust> ... The question is really about what the Webkit people think, as it seems difficult to change.
16:22:46 <tidoust> ... Hopefully, they are willing to change it.
16:22:53 <orkon> q+
16:22:58 <jgraham> ack next
16:23:45 <tidoust> orkon: If there is inconsistency between implementations and products are already dealing with this, do we need to worry about it?
16:23:54 <jgraham> q+
16:23:55 <tidoust> ... Maybe we could leave it as-is.
16:23:57 <jdescottes> q+
16:24:01 <jgraham> ack next
16:24:15 <tidoust> jgraham: I don't love leaving it as-is.
16:24:24 <tidoust> ... At the moment, the spec says that Chrome and Firefox are wrong.
16:24:39 <tidoust> ... And for new implementers like Servo, it would be good if the spec told them what to do.
16:25:24 <tidoust> ... We absolutely could change the spec to a SHOULD level requirement, and note historical implementations to explain the differences.
16:25:40 <jgraham> ack next
16:25:43 <tidoust> ... It's accurate, although not ideal. But if nobody is willing to change, that might be the best we can get.
16:26:24 <orkon> q+
16:26:32 <tidoust> jdescottes: Back to examples of things that break. We had one regression entry, I believe. But just an internal test relying on this API and expecting lowercase.
16:26:48 <jgraham> q+
16:26:52 <jgraham> ack next
16:27:01 <tidoust> ... I would also assume that, since Safari has always returned uppercase, any client that works cross-browsers should already handle the inconsistency.
16:28:02 <tidoust> orkon: I would follow the HTML spec, and ship with a flag so that people can update at their leisure. And then after a year, we can remove the flag, or rollback the change.
16:28:06 <jgraham> ack next
16:28:32 <tidoust> jgraham: My concern is not broken clients, but individual tests broken.
16:28:59 <tidoust> ... We could try doing it behind a flag. It's very hard to get people to notice that there will be a breaking change in the future.
16:29:19 <tidoust> ... We could try to do something here. I'm skeptical of our abilities to making the change stick.
16:29:41 <jgraham> q?
16:30:03 <tidoust> jgraham: Next step is to get feedback from the Webkit people.
16:30:07 <jgraham> Topic: Export EmptyResult dfn for cross-spec referencing
16:30:22 <jgraham> github: https://github.com/w3c/webdriver-bidi/pull/1116
16:31:29 <tidoust> orkon: exporting EmptyResult is kind of separated from the CDDL. Should we accept this PR or is there something we may do for the CDDL.
16:31:36 <tidoust> q+
16:31:37 <jgraham> ScribeNick: jgraham
16:31:42 <jgraham> ack next
16:33:37 <jgraham> tidoust: Right now the CDDL definitions aren't exported by default because in theory there could be mutliple specs defining different bits of CDDL. There are already some that define CDDL and they aren't in common and shouldn't be in the same namespace. Totally fine to export one. `EmptyResult` is a very generic name so another spec might have a
16:33:37 <jgraham> slightly different version with the same name. What's missing is a way to export the definition for a specific set of specifications. One way that might work is to namespace the definitions. I think it's fine.
16:34:26 <jgraham> jgraham: Seems like we could accept the PR, but look for a more generic solution in the future.
16:35:14 <jgraham> Topic: Rechartering of the Browser Testing and Tools WG
16:35:30 <jgraham> Rechartering of the Browser Testing and Tools WG
16:37:14 <AutomatedTester> q+
16:37:29 <jgraham> tidoust: Charter will expire soon. Expect that the group wants to continue. Need to agree on new charter for review by AC. Drafted a new one that's like the current one but refreshed to match the latest template. Sent an email to the group with a changelog. Would like input on a background and motivations section. I've tried to write that as best
16:37:30 <jgraham> as I could, but WG members have been doing this for longer than me, so I'm interested in feedback. But it's informative. Also interested in whether there are new deliverables the group wants to work on or things that should be dropped. Or if people don't want to recharter.
16:37:47 <jgraham> ack AutomatedTester
16:39:16 <jgraham> AutomatedTester: I want keep the group going. Output is amazing. Apologies for not replying sooner, the general story looks right. The only part that's questionable is the ATDriver part; I'll reach out to Bocoup and see if they're still working on that. Might be more appropriate for a CG.
16:39:25 <tidoust> q+
16:39:29 <jgraham> q+
16:39:32 <jgraham> ack next
16:40:12 <tidoust> jgraham: Interested in keeping the group going. What David says seems right.
16:40:20 <tidoust> ... We may re-assess AT-Driver.
16:40:23 <jgraham> q-
16:42:05 <orkon> q+
16:42:55 <jgraham> tidoust: I'm not expecting negative feedback on rechartering of the group as a whole. Questions we will probably get are first how come WebDriver BiDi is not in CR yet; I need to do some work there but shouldn't be a blocker. Second is that ATDriver hasn't bene published, but it's in the charter. If not working on it it should be dropped. Seems
16:42:55 <jgraham> like it's being worked on in the ATDriver CG. We've never discussed it in the context of the WG. Want to understand the level of support. If there's support we should publish a FPWD. Seems to be a good-looking spec otherwise. If there's no support we should drop the deliverable from the WG or make it tentative.
16:43:02 <jgraham> ack next
16:43:37 <jgraham> orkon: We also plan to continue working on WebDriver+BiDi. We don't have plans to work on ATDriver. Need to discuss if anyone in the group will continue working on ATDriver.
16:44:07 <jgraham> AutomatedTester: I will take an action to chase up ATDriver folks to see where they are
16:44:22 <jgraham> ACTION: AutomatedTester to talk to ATDriver CG
16:45:14 <jgraham> tidoust: I will initiate reviews of the draft charter in parallel to save time. But you're welcome to suggest changes. Background motivation is the easiest part, then look at normative parts.
16:45:20 <jgraham> q?
16:47:32 <orkon> present-
16:47:36 <jgraham> RRSAgent: make minues
16:47:36 <RRSAgent> I'm logging. I don't understand 'make minues', jgraham.  Try /msg RRSAgent help
16:47:39 <jgraham> RRSAgent: make minutes
16:47:40 <RRSAgent> I have made the request to generate https://www.w3.org/2026/05/13-webdriver-minutes.html jgraham
16:48:12 <jgraham> Zakim, bye
16:48:12 <Zakim> leaving.  As of this point the attendees have been orkon, tidoust, whimboo, sasha, jdescottes, jgraham, lauromoura, AutomatedTester, Euclid
16:48:12 <Zakim> Zakim has left #webdriver
16:48:17 <jgraham> RRSAgent: bye
16:48:17 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2026/05/13-webdriver-actions.rdf :
16:48:17 <RRSAgent> ACTION: AutomatedTester to talk to ATDriver CG [1]
16:48:17 <RRSAgent>   recorded in https://www.w3.org/2026/05/13-webdriver-irc#T16-44-22