guybedford
commented
1 month ago I would be interested in attending to discuss and seek feedback on https://github.com/whatwg/html/issues/10617.
Closed past closed 1 month ago
guybedford
commented
1 month ago I would be interested in attending to discuss and seek feedback on https://github.com/whatwg/html/issues/10617.
past
commented
1 month ago I would be interested in attending to discuss and seek feedback on #10617.
Thanks, I added it to the agenda.
noamr
commented
1 month ago Happy to continue TPAC discussion on whatwg/dom#1255, specifically around focusin/focusout/selectionchange behavior. CC @domfarolino
past
commented
1 month ago Tagged, thanks.
past
commented
1 month ago Thank you all for attending the meeting yesterday, and special thanks to Chris for the excellent (and unprompted) minuting! Here are the notes from this meeting (the next one is at https://github.com/whatwg/html/issues/10692):
Attendees: Joey Arhar, Panos Astithas, David Baron, Guy Bedford, Keith Cirkel, Dominic Farolino, Mason Freed, Siye Liu, Olli Pettay, Noam Rosenthal, Kagami Rosylight, Khushal Sagar, Fernando Serboncini, Anne van Kesteren, Chris Wilson, Di Zhang, Sanket Joshi, Ana Sollano Kim
Scribe: Chris Wilson
<select> elements.
<select> element
<input type=color> with alpha and colorspace=display-p3
Joey: Simon reviewed the PR three weeks ago, but isn't on the call.
Panos: Should we keep the action item? Or is this done?
Olli: I'll ping Simon about it.
Panos: next is noopener-allow, which was merged.
…no carryovers from last time, but plenty of new topics.
…First: Joey on customizable <select>
Joey: Looking to see if this is ready for stage three.
Olli: This is the first time we would move to stage 3. Timing is interesting, might want to wait until we know exactly what solution we want there.
Anne: the cloning into selected option seems least resolved.
Mason: same as the timing issue, yes?
Anne: yes
JoeyL: Last time I thought we were pretty resolved in asynchronous?
Anne: There were comments from Jake, and didn't' seem like resolution
Joey: The most recent discussion was Jake talking about keeping references from node and option element to refer to the clones copy in the select option. Might show up i nthe mutation records ro something.
Anne: Yes, very much observable. This is substantive input that hasn't really been resolved.
Mason: ok, we can take an action item to look at. Is that the only issue?
Anne: caveat that I haven't been able to review all PRs so far. Mostly looks fairly solid, but there are a lot of PRs and it's hard to keep them all straight.
Mason: Can we get to that review in the next couple of weeks?
Anne: Maybe, I'm traveling for the next two weeks.
Joey: The PRs can be merged separately; there's only a small overlap I could fix up. They're fairly independent although they're all needed to make the feature work.
Panos: to be clear, editorial issues are fine in stage 3.
Anne: yes. Typically I notice editorial stuff first.
Mason: Dom Farolino might be able to look at some of the editorial stuff first and we can focus on substance.
Anne: if more people can look at them that would be great.
Dom: Yeah, I can take a first pass. (Action item)
Joey: Link to PRs is in issue 9799, all at the top of the description.
Panos: next topic: enhancing input type color with alpha and color space display-P3
Anne: There are now two implementers who are supportive, so I think we're good. Only party I haven't heard from is Mozilla.
Olli: nothing negative to say about this when I asked around.
Panos: Next topic: HTML Integration with ESM Source Phase
Guy: Overall situation: with landing of webassembly module integration, we have support for source phase imports of webassembly modules. Source import is WA stage 3 proposal. We want to bring this to Javascript. Want feedback on the HTML side about whether this worker construction use case is a viable motivation. [presents deck]
… Lot of the spec will be on the HTML integration side for this; worker instantiation situation. A lot of the justifications for the source phase of webassembly applies here. Would solve a portability problem for workers, where build tools can more easily see what's being loaded, and static environments are able to analyze the code up front. Once we have this feature we want to work on module expressions built using the underlying primitive. We want to support dynamic import for these modules where even though it's a higher order module it can have a key in the registry. When it comes to worker instantiation, there are some semantics that we would like to transfer that would trickle down into HTML. It would also be nice if we had import maps on workers. Would be interesting to consider if something like import map inherit might be a sensible default. If we want to move forward, we need some kind of public positive signal from HTML that we can take back to TC39. Happy to dive more into semantics questions.
Fernando: Looks fun. First question: is there a technical reason why import map needs to be part of instantiation and not part of the module.
Guy: import map is a global object.
Fernando: Module should have import map, not the worker that has the module?
Guy: if we were transferring instances that were already linked. One of the problems with that is there are a lot of issues around instancing and is it really the same module. When we transfer a source, we're transferring no linkage info, just that one source text, and re-running all the resolution and instantiations. No guarantee it's the same instance.but transfer breaks a lot of assumptions.
Anne: TC39 side, is there implementer interest? Seems okay in general from the HTML side. But that's not the same as implementer interest. Second thing, I think defaulting type makes a lot of sense. On import maps, we're very close to adding mutable import maps, and I'm curious how that would translate here esp if you do inherit. I think we need to transfer. Do you mutate in the worker case?
Guy: I don't know if there's enough implementer interest. Following up with browser discussions would be good. I'd like at least a signal that there's no inherent resistance from HTML and we can move forward with the discussion.
Olli: Just looking at the examples, those seem like the loading of the actual file happens on the main thread and you pass the source to the worker. Am I interpreting that right?
Guy: You're only loading the main module for the main thread. The import does not import dependencies. When you pass that source into the worker, it will create an instance and rdo the linking and fetching and processing.
Olli: but the initial would we loaded on the main thread.
Guy: yes. Is that a network argument or computation argument?
Olli: network. Getting all the extra network effects out of android.
Guy: you would only have one fetch anything so it's almost an optimization of the worker. There's a dynamic import former as well. You could do something like this:
const modSource = await import.source('./foo.js);
const worker = new Worker(modSource);
Guy: We don't currently have a way to get access to the source. If a new worker does that fetch anyway, that would be very different than what would happen if you pass your world directly into the worker.
Anne: Might be different but might be something people can use to their advantage in some way. Would work with shared workers, though.
Guy: I would need to look into more.
Anne: should look at the same origin, modules might be cross-origin. Not just CSP - global will always be same-origin with the window global, and that's always instantiated from the same origin script currently. There might be some tricky aspects there.
Guy: effectively the host defines a slot on the module that gets kind of remapped. In representation all that matters is creating the equivalence relation between modules across context.
Anne: The general thing makes sense, and especially the inline. There are some tricky questions though.
Guy: a lot of the hard questions are around how these instantiations happen, once we work this out, module expressions should be much easier to specify as just an instantiation of these. Snapshotting is probably the best we can do.
Anne: maybe it should be called copy or something instead of inherit
… the other thing you're asking for, the signal, we haven't done that before. I think it's fine to go back and say we've discussed, and no negative signal.
Guy: OK, that should at least justify our continued investigation.
Anne: if someone wants a more official signal you should raise an issue on the meta repository and we can can define a process for doing that.
Olli: might want to talk to some more performance folks about the initial fetch for the initial module. With the current setup you don't need to go back to the main thread.
Guy: I'm wondering if this can be framed as a prefetch that could be a perf enhancement.
Fernando: I can't imagine how that would be an enhancement; the main thread is always in contention.
Panos: next up: Canvas Place Element
Kushal: presented this at TPAC, got some excellent feedback. Next step, we would like to move this to stage 1. Hoping to get concrete things to be able to proceed to that. Olli mentioned wanting a bit more detail on the explainer. There are issues on the repo for all the open design questions. Issues range from syntax to broader things.
Olli: your answers in issue 9 and the questions from Apple around memory use.
Khushal: I replied to comments but haven't reached a conclusion as such.
Anne: for my side, we're okay with stage one but not going beyond that until more details have been investigated.
Olli: I think it's fine to move to stage 1 also. But please incorporate feedback into the explainer.
Fernando: I'll reach out to Olli next week
Khushal: Seems Olli is a good PoC from Moz; is Simon the right person from Webkit?
Anne: yes; and copy me.
Panos: next: Consider throwing for showModal() and showPopover() in non-fully-active documents
Keith: We want to throw for showPopover and showModal when they are not connected. If they're in a document implementation or some other various ways, those methods should throw. I don't know if github is the biggest consumer of popover and dialogs.
Anne: We should go to the next topic.
Panos: next topic: Atomic move operation for element reparenting & reordering
Dom: we're mostly going to talk about focusin event basically just whether we should force layout and sync fire focus on the subtree that node is being atomically moved to or if async fire focus. Possible solution is fire only if there's a focus handler in the tree being moved to, so we don't always force layout during atomic move. Noah has this paged into his head more.
Olli: Why is focusin an interesting event here? Focusout and focusin are totally broken. Blur and focus are more interesting.
Dom: I don't know.
Keith: Do we move the focus with the move, if the element is focused.
<yes>
Keith: That's a little concerning.
Anne: Is this like an input element with the outer focus element? Why would this be automatically focused?
Dom: It's not out of focus. IF you have a focused control and you move it atomically…
Anne: why?
Keith: please raise an issue in the ARIA working group around this to discuss. That sounds like a very concerning thing for assistive technology users. [action item]
Dominic: Will do. We should discuss this at the next meeting with Noam. Hoping to shortly get to stage three. We'll be requesting editor review soon (but not yet)
Anne: haven't looked yet, since they're draft
Dom: yes, will flip when we're ready.
Panos: next topic: Prevent currentScript from being overridden on document via name=''
Anne: Someone is interested in fixing this process. Maintainer of emscripten was interested if browsers were willing to make currentScript in particular a non-overridable name, I'm kind of +0 on it, but wanted to raise it. They're curious if other implementations are interested.
Mason: Seems a reasonable thing to try, but concerned about webcompat.
Anne: if we just do currentScript there's not a lot of compat concern.
Mason: Capital S only, yes
Olli: I don't know of any inconsistencies but I could probably live with it.
Mason: I like Anne's +0. If there's another solution that would be great. I wonder if there are other things done on the platform.
Anne: yes. Somehow this hasn't been raised to critical for any security team.
Panos: we're at time. Continue next time.
What is the issue with the HTML Standard?
We canceled our last weekly triage call (https://github.com/whatwg/html/issues/10652), but we are having the next one on October 10, 9am PDT. Note that this is 1 week later in a Europe+Americas 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.