Upcoming WHATNOT meeting on 2024-11-21

[past]

What is the issue with the HTML Standard?

Today we held our weekly triage call (#10750) and I will post the meeting notes there in a bit. The next one is scheduled for November 21, 9am PST. Note that this is 1 week later in an Americas+Europe friendly time.

People interested in attending the next call please respond here or reach out privately to @past, @cwilso or the spec editors. We will be tagging issues for the next call again using the agenda+ label in all WHATWG repos and we would like to invite anyone that can contribute to said issues to join us.

[past]

Hey @whatwg/triage, the agenda is pretty sparse for this meeting. Do you have any other topics to add?

[schenney-chromium]

Where do we see the agenda? I'd like to be added to meetings please. If Issue #10677 isn't being discussed yet, could we cover that?

[past]

I added it to the agenda (which includes PRs and issues tagged with agenda+). I also sent you a calendar invite.

[schenney-chromium]

Thanks very much.

[past]

Thank you all for attending the meeting today and a special thank you to Joey for taking meeting notes! Here are the notes from this meeting (the next one is at #10789):

Agenda

Attendees: Joey Arhar, Panos Astithas, Stephen Chenney, Emilio Cobos Álvarez, Dominic Farolino, Mason Freed, Alex N. Jose, Olli Pettay, Noam Rosenthal, Kagami Rosylight, Anne van Kesteren, Chris Wilson, Di Zhang
Scribe: Joey Arhar

1. Review past action items
   1. Panos will file a meta issue to clarify what stage 3 means. Domenic will add some examples of how he imagines this should work.
      1. Done.
   2. Di will add a comment with the current consensus to Discussing how to focus navigate absolute position elements that are focusable in CSS reading-flow.
      1. Done. PR review feedback would be appreciated as well as vendor position statements. Anne & Dom will take a look next week.
   3. Domenic will add some thoughts to Deferring (same-origin) navigation commit.
      1. More feedback is welcome.
2. Carryovers from last time
   1. Olli and Anne will review Alex's latest comment in Add expect-no-linked-resources Document-Policy to Speculative parsing.
      1. Olli commented.
3. New topics
   1. [Stephen] Canvas TextMetrics additions for editing and text styling
      1. Stephen will look into consistency with the intl.Segmenter API and update the explainer.
   2. [Dom] Atomic move stage 3
      1. Existing comments have been addressed. Do we agree on the processing model enough to bump to stage 3? Olli will review the PR this week.

Action Items

1. @annevk & @domfarolino will take a look at Discussing how to focus navigate absolute position elements that are focusable in CSS reading-flow.
2. @smaug---- will review the Atomic move PR this week.

Minutes

topic: what stage 3 means
panos: filed an issue, domenic added thoughts, please add your thoughts if you have them. idk if folks have thoughts now, but i assume some async discussion will continue. any immediate reactions to that issue?
olli: i think it looked mostly reasonable. i was thinking stage 3 would be quite short and the specs should be pretty much ready at that point and then we just do editorial tweaks.
panos: close to what domenic described
olli: yes
anne: yeah when i skimmed domenic's response that's also how i viewed it. that's also different from how some people on the chrome team see it.
panos: hence the need for qualifying the phrasing
mason: I'm glad we're clarifying what it means. I like that it frames the debate. good by me.

topic: focus navigate absolute position elements
panos: action item was for di to leave a comment, which was done right?
di: yes. I added a summary of the current impl, since we have more people here I'm also happy to discuss it further as necessary.
panos: did folks get a chance to read that? any questions on that one yet? especially non-chromium folks?
mason: the current spec pr has that resolution in it. you can read the comment or the pr if you want.
di: i would appreciate some review feedback on that pr.
anne: probably its ok to handle position absolute out of flow. I have seen position absolute things, but not sure if they do it within flex that are focusable as well.
di: i would also think it's uncommon
mason: from our point of view, our focus was making sure that the elements are all focusable at some point. it was unclear in this case where this should go in the focus order just to make sure the user doesn't have something that they can't get to.
anne: does it get iterated at the end? Is there a bucket at the end? or is it per this individual container that we talked about through which tabindex is also scoped?
di: if its a direct child of the reading flow container. It will be visited after the in flow children.
anne: ok so it does stay within the container
di: yes
anne: that sounds fine. its hard to imagine something better except for visually doing some magic but thats hard. i think elika left comments on the pr, she was concerned about relying directly on css properties, but i think we do that in other places too. where we can do abstractions that's probably better.
di: i rewrote the pr to remove things that are layout heavy. I used stuff in the published reading flow spec.
anne: makes sense
di: id appreciate it if i could get more review from those who are familiar with focus navigation traversal and get positions resolved
anne: probably have more time for that next week. Did you end up adding examples to the pr?
di: yes

topic: deferring navigation commit
panos: i don't think the action item has happened. There was another long comment there. Any feedback on this one? noam do you have any questions?
noam: i put it in the agenda as a fyi to look at this issue. it's a problem we're tackling. happy to get early feedback. There's also related things we are planning to do around the navigation api. wanted to start a conversation about it. no action item at this moment.
panos: has anyone else read the thread yet?
noam: i can present it in short, it's not that complicated. a lot of stuff I'm working on is a balance between fast navigation and soft navigation. People who build that need tools to help with that balance. Sometimes when there's a same origin navigation they want to do some navigation or indication in the old page like loading, something that has a timeline that creates a smooth interaction for this. For same document this is pretty easy because you control everything with js. for cross document, you don't know when the commit or activation is going to happen. at the moment that it happens, your js and context is gone. If you choose something that has a timeline you can't finish it. the new page might not be ready for render. might be moving from a half finished animation to a page that's not ready to render, which is not good for anybody. The feature request was to defer all the document until the animation is done or the new document is ready or something at some point in time that the author defines. This is possible today by intercepting the old navigation and making it a same document navigation, which will abort the fetch. When the animation is done, start a cross document navigation. that's slow because you have to abort and restart the fetch, and its not ergonomic. what we've proposed here is something that looks like waitUntil in service workers where you can defer the same origin cross document navigation until you're ready basically. That's about it. there was a concern from anne on the issue about bfcache. we don't have to enable it for a traversal, this is about direct navigation for ones that go through the ???. This is more about regular navigations at this point.
olli: but user doesn't know which one is from bfcache or regular navigation
noam: not a back forward. like if you click on a link. the user doesn't know if its a traverse if it will change their history that way. it's usually a user initiated back or forward, or some button that says back.
olli: well pages do use history api quite a bit. that would be a bit inconsistent if it would apply to non history navigations. if it applies to history navigations then it makes bfccache slow. I understand the use case.
noam: traversal that comes from browser ui. those are, you can't really intercept with the navigation api.
anne: I think you can. i thought you could intercept the first back button press
noam: there are ways to do that. as long as there is a way to intercept a navigation, there is a way to slow it down because you can cancel it and start it as a cross document navigation. so use case wise its less important. for consistency, wherever you can intercept you can delay activation and have smooth things. it ties back to conversation about render blocking. it will be a nice tool for people who have a long render blocking. Instead of moving to the new page and waiting, you can still show something to the user in the old page. you could show a skeleton, something that's alive for at least a little bit.
olli: browsers have that behavior forever, that you can still paint the old page while the new one is being loaded. but of course these days because ??? has changed a bit.
noam: So this is for same origin anyway. just want early feedback
panos: i encourage you all to leave a comment once you've had a moment to digest. Any other thoughts on this one?

topic: expect-no-linked-resources
panos: i see olli commented. any updates?
alex: i didn't understand the last part of that with the performance would be bad
olli: I started to think about this. So you have an element to actually preload stuff. you would use this header, those preloads would start later because they would start once you actually parse the page. in gecko we start this already with speculative loading. with this you kind of want to let the page control what gets loaded and when. you want to disable speculative loading. but it might give a wrong idea to the dev that you can still use preload to do things fast. combining these two with preload would still be slower with gecko. without this header we could start the preloads sooner
alex: i took preload as a dev hinting to the ua that something has to be done differently. What I saw in the origin trial is that the best performance is for a page that first this header is the http preload combined with speculative scanner turned off. preload was not delayed, and the page was in control of what to preload. This is a niche optimization. i don't think people would conflict the scanner with the preload. for gecko i think that combination would have the best performance. if you were to take one of the early hint preload and you just have the stylesheet to preload. ??? which the speculative scanner of gecko and chrome will spend a lot of time on. that page will do best with the header so you're not spending any time on speculative parsing and you control what gets preloaded
olli: it would not help gecko. maybe the header, one should be able to control more about what does or doesn't get speculatively loaded. so that the browser would still speculatively if needed do preloading for example based on the elements. it could use preloading for them but not images. Maybe we need more so it's not controlling everything. Right now it's like let's do nothing or do everything.
alex: I think we have the flexibility given that we have 3 or 4 types of preloading available. early hints, h2 header preload, or link preload. very good amount of control. but there is no control available if the page knows there are no resources being packers. this brings additional control. it does have material benefit on the pages that are affected by it. gecko is sort of in a different situation where it has a single pass scanner, but it is also not sure gecko would also benefit by controlling the header preload even though it's not spending time in speculative parsing.
olli: yeah header based. I was thinking element.
alex: element i took as a case where this is against the priority of constituencies. this is not the first time where ??
anne: i would like to see more on whether this is a perf bug in webkit/chrome or is it an actual thing that we need to - if it's not a problem in firefox then it's just something that we need to optimize by the way we do scanning. I'm concerned about features that benefit less than 1% of websites. For this you need to have a big performance team to use this signal correctly. That also concerns me. we're adding these very specific tweaks and you need a lot of knowledge. if you copy past it could end up hurting or not being beneficial.
alex: I would put everything of preload into this bucket. you should probably assume you know what you're doing before you use any of those, this is no different
anne: im not defending the status quo, just dont want to make it worse.
alex: chromium and webkit should evaluate the two pass preload scanner. that hypothesis is not experimented on. we dont know whether a single pass approach is going to be faster, and thats what domenic was pointing two.
anne: adding new api surface is a more significant change because it will be with us for longer than any impl strategy.
olli: im worried that if we add this then we will add other hints that could affect perf. Maybe we want to add a hint for animation callback timing during page load because that affects react sites. Maybe we want to add other hints because the scheduler might be different from safari and firefox/chrome. maybe those wouldn't apply to safari. that's the worry that were still
alex: I don't see hints as a bad thing. if a hint is redundant, then probably the hint is not valuable and ua should do the work to actually find that information. In all these cases where a hint is actually benefiting the user, we should probably not be worried about adding more hints. that piece of information is not derivable from the ua on its own. there's no way for the browser to know if there's a resource that needs to be preloaded. Another example is a third party classification. all the uas are trying to figure out ?? who can actually provide that information is the first party. theres no standard for it. the browsers way of defining what's a third party is origin based. that changes per response. each party could become first or third depending on context. again, we don't have anything like that, but is a good place where we could use a hint from the first party
anne: i'm not sure. in these cases the first party is an adversary from a privacy perspective. i don't think we should let them define what a first party is, they could say advertisers are first party
alex: if it's for cookie i agree with you, but for figuring out the engineering control for prioritization that could be better. esl serves to that better but its a static piece of information. i don't want to risk derailing the other topic. hints are not necessarily a bad thing.
anne: i'm not convinced of that either. they have a cost. they increase processing on the page. if were thinking of adding hints for all the things. if the page has 100 hints then it increases processing time and the amount of options and flags a ua has to maintain, and it increases the size of documentation for these thing which makes it more difficult to create web pages. there's a real cost to any new api surface thing. we try to standardize things. we try to do things for the 80% and not the 1% of use cases. i haven't seen stackoverflow threads where people are begging us to disable the scanner
alex: i dont think its 80 or 1%. it's somewhere in the middle. majority of page loads are probably benefiting from the scanner. this is from a class of pages that have external resources. i don't know what portion of the web has this problem.
panos: since webkit could benefit from this, is there any measurement that you think alex could get that would convince you that this is beneficial?
anne: if it's beneficial to firefox i would consider. still concerned that is a niche use case that is hard to deploy.
panos: so those are the concerns? not how much the benefit is?
anne: i think that if we wanted to have that optimization we would probably rather attempt to adopt firefox architecture rather than introduce a new platform api. were not convinced of adding a bunch of compiler hints on the js side. we'd rather figure out ways to optimize our engine better.
alex: I think everyone in the room understands what this is, and that is resolved now.

topic: canvas textmetrics
stephen: these are additions to the canvas textmetrics api intended to support improved editing, selection know where in a string you are. improved ability to animate text, particularly when that text contains grapheme clusters. mapping from string glyph positions to actual characters rendered is not one to one. the explainer is linked from the issue. 10677. At this point we have all of these implemented in chromium behind a flag. There are examples of the artistic text. were looking to move forward on finalizing the names and apis and then getting it into the spec. Has anyone taken a look at it or have thoughts? assuming not then, i request people take a look at it. there are two questions: is the api for getting graphemes out f the string the right api in the right place with the right data? another is naming bikeshed situation of what do we call the canvas text equivalent of document carrotpositionfrompoint. it gives you a position and a node and a position within the text within that node. it just gives you a position. it just takes an offset within the string. open question about whether we should match the name or we should have a different name.
anne: they should probably have a different name.
stephen: ill make the change to that then.
anne: if it deals in grapheme clusters, is it done in a way that's consistent with the text segmentation api? i don't think i got the name correct but theres a text segmenter or something. intel.segmenter
stephen: yes it does seem very related to that. i was not aware, ill have to take a look and comment in the issue about how they relate.
anne: similar chrome proposal for text in canvas. i just looked and the relevant people are not here, but i'm curious what their thinking is. maybe they want to do both or they didn't see this.
stephen: im representing igalia but we're working with chrome folks on this. there's the html and canvas proposal in the wicg. the decision was to break this out of that proposal because in some sense we feel that it is less controversial and likely able to move faster. basically get through the spec process faster. It was about how to proceed with the approval process that broke it up. These additions do not require canvas authors to buy in to all the restrictions with putting dom content in the canvas. no security, privacy or tainting. authors building any editing in particular constructs in canvas will be able to use this directly to replace js libraries that do selection in canvas. make it way easier than before. improve ability to reproduce logos, text around circles, more internationalizable.
anne: one thing with grapheme clusters is don't they depend on the locale?
stephen: So if you want a specific rendering you might have to fix the locale? that's a good point too. i'll bring that back to the
anne: doesn't expose hyphenation. but that depends on locale.
stephen: not exposing hyphenation or line breaking. no dictionary information. ill update explainer and come back when it's ready

topic: atomic move stage 3
noam: we resolved all the pending comments on the issue. we support disconnected to disconnected without throwing. we add a test for that. were not doing anything with ranges and keeping it as it is. not preserved at this point. we only preserve things that are element specific rather than the whole tree. we don't have any pending big issues. still spec review. wondering what's left for stage 3?
anne: what if the range is entirely contained within the element that is being moved? none of the change conditions would be triggered?
noam: right, i think olli you wanted to be a bit more conservative about this?
olli: yeah behave as if the element was removed and added back, which means that the range gets propagated upwards. idk if this pr does that but this is the easiest way.
noam: yeah treats the range as if it was a regular remove insertion. we prefer to find a solution for it but would be able to add it later in a non breaking way. it's only going to be a pleasant surprise for people.
olli: the issue is that there are so many special cases with ranges. if you're moving from light dom to shadowdom or vice versa, we need to be very careful with that
anne: One comment on the pr looking at it now.
olli: assertions would have fired in gecko with ranges. could i implement this now? and it wasn't implementable 2 weeks ago.
noam: from our side we are ready to answer anything that comes up. we have nothing on our queue.
olli: yeah just need to go through it again since there were major issues 2 weeks ago
panos: review this with stage 3 in mind.
olli: I will review as if i can implement this now.
panos: not moving to stage 3, waiting for olli's review, maybe anne's as well.
noam: i'm thinking about movebefore as preserving state having to do with the element. could do move transition on old document if there is a need and desire for that. to be a bit more constrained about this