Meeting minutes
Support retrieval of content quads for elements with CSS transformations
<jgraham> github: w3c/
henrik: Discussed a while group. Ongoing PR to update a CSS spec. Changes have now landed.
… Browsers can implement this feature. Firefox already has it.
… The question is: how does it look like for Chrome? Feature should be ready there as well.
… Do we need a specific API?
… Or do we require the client to evaluate or call a function to get the values?
… If there's nothing specific, script evaluation will work for now, and we can get back to it later if that seems needed.
… E.g., because more complex usage scenarios arise.
orkon: For this one, I would slightly prefer to have a dedicated API in WebDriver.
… Do we want exactly to have what's on the Web API?
jimevans: I understand the desire to want a dedicated API. It feels like an odd fit for WebDriver, because we've generally shied away from wrapping pure script available APIs in the BiDi spec.
… If Chromium does expose this via script, I don't know that we need a dedicated API.
… General policy of letting the user run scripts if it's available in script would seems like a better approach.
… But I don't feel strongly about it.
… This is not an opposition to adding a dedicated API to the WebDriver BiDi spec.
jgraham: The question of what it is relative to is a good one. Once the CSS spec is implemented, we can assess whether that's enough.
… If it turns out that there are some cases when the script provides different answers, then we would need a dedicated API.
… I'm also not fan of creating dedicated API if we don't provide value on top of what's available through script.
orkon: The major use case for this API has not much to do with DOM but more with input.
… Clicking on the center of the element is the default, but sometimes that's not the part you should click. This dedicated API would allow you to click on a reliable part of an element.
… Even the CDP API is not directly usable, because relative to the top-level frame. You need to compute the offset from the other frames.
jgraham: You can specify an offset when you simulate a click.
… That's not a guarantee that it will work, but it allows you to move away from the default.
orkon: The use case I have in mind is precisely the case where you don't know the offset.
… And cannot compute it programmatically.
jgraham: It sounds like we should experiment with just the DOM API for now and see whether that's enough to address most of the use cases.
… And revisit as needed.
WebDriver BiDi web-feature definition
<jgraham> github: web-platform-dx/
jgraham: This is a request for review. Web-features is an attempt to define a list of features that exist on the web platform for things like MDN and Can I Use.
… WebDriver BiDi is part of the platform, and at some point, it would be useful for people to know which bits are supported where.
… There was a generic WebDriver BiDi feature that was "all of BiDi".
… This PR is an attempt to be more specific about what it means to implement the core of WebDriver BiDi.
… Additional modules may be specified as extensions to the base feature afterwards.
… Please review the PR and check that it matches what you believe would be a useful definition for the core of WebDriver BiDi.
Missing page load events for "browsingContext.traverseHistory" for pages coming from BFCache
<jgraham> github: w3c/
jgraham: If you have a page that is in the BFCache and move back to it, then there is no "load" event.
… It is difficult to tell that this navigation is completed.
… Two possible approaches: 1. You should always get a "load" event in BiDi, regardless of what HTML says.
… 2. Attach to the pagehide/pageshow events with a flag that explains that the page comes from the BFCache.
orkon: I think we should avoid generating a "load" event. The other approach looks good.
… Now, you have different sets of events, like fragmentnavigated or something like that.
… I would prefer to have something dedicated to the BFCache.
… But pagehide/pageshow may cover more use cases.
jdescottes: I slightly prefer to have a single event emitted for all navigations.
… When you're writing generic tooling, it makes things easier.
… If it's a limited set of events, applications need to handle the logic, and the possible different lifecycles attached to them.
orkon: pagehide events would need to have references to navigation.
… otherwise you may have difficulty understanding whether the events are part of the same traversal.
… If an event handles types of navigations, it would be good to have a reference to more specific events for specific types of navigation.
jgraham: I agree that these two options are better than overloading the "load" event.
… It seems that drafting a spec update would be useful to evaluate whether it will be easy/difficult to cover all cases.
… Does that sound reasonable?
<orkon> sgtm
"in-view center point" is broken when an inline element contains block-level elements
<jgraham> github: w3c/
jdescottes: This is a request for review and feedback.
… A problem we detected by running some tests internally at Mozilla.
… The algorithm to interact with some element can end up clicking on the first rect of the element which may be of size 0. The interact fails in that case.
… The proposal is to define a better behavior, with a fallback on the first rect.
… The situations under which you may end up with a 0-size rect are not clearly defined, but this approach would still seem preferable.
orkon: I think it's reasonable, and perhaps related to the previous discussion about clicking on the center of the element.
Get Element Tag Name case inconsistencies
<jgraham> github: w3c/
jdescottes: The spec for GetElementTagName clearly explains that we should return the element's tag name, which is uppercase in HTML. But implementations return lower case versions.
… Some discussions that it's not a good approach for SVG. The suggestion is instead to return the qualified name, which happens to be what Chromium and Firefox do for HTML elements, so no regression for tests we have.
… There's a PR for review. There will also be a PR to update the test.
orkon: There has been some back and forth in this discussion.
jdescottes: We would return what the spec says for qualified names, but not for tag names.
<jdescottes> elem.prefix === null ? elem.localName : `${elem.prefix}:${elem.localName}`
orkon: Do we still have concerns that this would be a breaking change?
jdescottes: It's also a breaking change by Safari, but they suggested the fix.
… and a breaking change for SVG/MathML elements.
jgraham: I suspect that the assumption is that it's ok because they are less widely used.
orkon: The proposed change sounds fine to me.
TPAC
<jgraham> https://
jgraham: Meeting scheduled for TPAC. WG meeting planned on Thursday and Friday.
… 29/30 October in Dublin.
… I encourage everyone to join.