Meeting minutes
Screencasting API spec without JS primitives
<jgraham> github: w3c/
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.
… We decided to put up a proposal without leveraging them.
… That makes the proposal a bit more vague. To be revisited when we work on the streaming version of it.
… Feedback welcome on the PR.
Add download ID field to download events
<jgraham> github: w3c/
<jgraham> RRSAgent: make logs public
sasha: The download 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.
… I created a PR for that which shouldn't be controversial. Comments welcome.
orkon: I think it looks fine and that we should have a download ID. I'll take another look next week.
Get Element Tag Name case inconsistencies
<jgraham> github: w3c/
jdescottes: A WebDriver classic topic.
… We have Get Element Tag Name that's supposed to return upper case, but some implementations have returned lowercase, while others have returned uppercase.
… 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?
Euclid: First time here!
… I was wondering why Servo wasn't passing this test. Only Safari is doing it correctly. Is that what we're discussing here?
[yes]
whimboo: Would be good to get feedback from Apple.
… Hopefully, they'll get back to us.
… Regarding Servo, it shouldn't be a problem. Chrome and Firefox have been returning lowercase for years.
… I don't know if tag names can mix lowercase and uppercase characters.
jdescottes: Whether it's JS APIs or DOM, it's always exposed as uppercase.
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?
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.
jgraham: DOM does not seem to do case folding for non-HTML elements.
… I think it's absolutely certain that someone is doing a test somewhere that expects the behavior.
… The question is really about what the Webkit people think, as it seems difficult to change.
… Hopefully, they are willing to change it.
orkon: If there is inconsistency between implementations and products are already dealing with this, do we need to worry about it?
… Maybe we could leave it as-is.
jgraham: I don't love leaving it as-is.
… At the moment, the spec says that Chrome and Firefox are wrong.
… And for new implementers like Servo, it would be good if the spec told them what to do.
… We absolutely could change the spec to a SHOULD level requirement, and note historical implementations to explain the differences.
… It's accurate, although not ideal. But if nobody is willing to change, that might be the best we can get.
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.
… I would also assume that, since Safari has always returned uppercase, any client that works cross-browsers should already handle the inconsistency.
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.
jgraham: My concern is not broken clients, but individual tests broken.
… 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.
… We could try to do something here. I'm skeptical of our abilities to making the change stick.
jgraham: Next step is to get feedback from the Webkit people.
Export EmptyResult dfn for cross-spec referencing
<jgraham> github: w3c/
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.
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
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.
jgraham: Seems like we could accept the PR, but look for a more generic solution in the future.
Rechartering of the Browser Testing and Tools WG
Rechartering of the Browser Testing and Tools WG
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
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.
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.
<tidoust> jgraham: Interested in keeping the group going. What David says seems right.
<tidoust> ... We may re-assess AT-Driver.
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
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.
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.
AutomatedTester: I will take an action to chase up ATDriver folks to see where they are
ACTION: AutomatedTester to talk to ATDriver CG
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.
RRSAgent: make minues
RRSAgent: make minutes