Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TPAC 2024 meeting #326

Closed
past opened this issue Aug 15, 2024 · 31 comments
Closed

TPAC 2024 meeting #326

past opened this issue Aug 15, 2024 · 31 comments

Comments

@past
Copy link

past commented Aug 15, 2024

TPAC 2024 WHATUP meeting agenda

The WHATWG (Web Hypertext Application Technology Working Group) community will meet at the Technical Plenary (TPAC) 2024 in Anaheim, CA USA the week of 23 September 2024. We call this the "Web HyperText Application Technology Unconference Plenary" or WHATUP for short. See the overall meeting page for conference, hotel, and travel logistics. Registration is required.

Remote participation is available via Zoom. People who can are encouraged to attend as the face to face opportunity is valuable for the work, but W3C expects many people to be unable to attend and plans to provide quality remote participation support. Note that registration is required for remote participants.

The purpose of this meeting is to make progress on the current open tasks in a high-bandwidth medium that an in-person meeting provides. Additionally it will be an excellent opportunity to strengthen the relationships between all participants by spending some time together after a long time. There is a draft agenda below, but it will become more concrete closer to TPAC, when it becomes clear what issues have been resolved and what new topics have come up.

Please suggest topics in the comments below and I will incorporate them in the agenda.

Schedule

Monday

14:00-16:00 Joint meeting with the CSS Working Group

Tuesday

9:00-12:30 Joint meeting with the CSS Working Group and the OpenUI Community Group
16:30-18:00 Regular WHATWG triage

Thursday

11:00-12:30 Joint meeting with the Accessible Platform Architectures Working Group

Friday

14:00-16:00 Joint meeting with the Web Performance Working Group
16:30-18:00 Joint meeting with the Internationalization Working Group

Agenda

Topics for the joint session with the CSSWG

Topics for the joint session with the OpenUI & CSS WGs

Topics for the WHATWG session

Topics for the joint session with the Accessible Platform Architectures WG

  • ARIA attribute reflection
  • Symbols - we would like to address present technical questions/blocks regarding authoring considerations.
  • Well-known destinations - we would like your views on the best way to proceed with this spec: we currently have two potential routes to implementation.

Topics for the joint session with the Web Performance WG

Topics for the joint session with the Internationalization WG

@mfreed7
Copy link

mfreed7 commented Aug 21, 2024

I'd like to discuss the general concept of "tooltips" in the joint OpenUI & CSS WGs session, please. Some related links include:

@past
Copy link
Author

past commented Aug 21, 2024

Added, thanks.

@mfreed7
Copy link

mfreed7 commented Aug 21, 2024

"tooltips"

I'd like to actually expand this to "tooltips, hover-menus, and other hover-triggered popovers". Same links work.

@past
Copy link
Author

past commented Aug 21, 2024

Got it, updated.

@sanketj
Copy link
Member

sanketj commented Sep 11, 2024

@past We'd like to discuss the following topics at TPAC. Would you be able to add them to the agenda?

Joint session with OpenUI & CSS WG: openui/open-ui#1088 cc: @alexkeng
WHATWG session: whatwg/html#10614 cc: @siliu1

@past
Copy link
Author

past commented Sep 12, 2024

Sure thing, done.

@keithamus
Copy link
Contributor

@past I'd love to get openui/open-ui#1090 on the agenda with the joint OpenUI & CSSWG task force. This is a proposal document on expanding input & textarea elements to include richer styling & interactivity.

@jeremyroman
Copy link

I'd like the opportunity to mention companion windows during the WHATWG solo session (tentative explainer, should be slightly better formatted as a GitHub repository by next week) so that folks who are interested can share brief comments and follow up with us afterward.

@past
Copy link
Author

past commented Sep 16, 2024

Added both of these. Jeremy, let me know when the explainer repo is up so that I can link to it.

@yoavweiss
Copy link

Can we add scheduling API updates to the WebPerfWG joint session?

@past
Copy link
Author

past commented Sep 17, 2024

Added both Yoav's and Joey's topics.

@jeremyroman
Copy link

Jeremy, let me know when the explainer repo is up so that I can link to it.

https://github.com/explainers-by-googlers/companion-windows

@matatk
Copy link

matatk commented Sep 19, 2024

Hi WHATWG; we (the Accessible Platform Architectures WG) are looking forward to meeting you next week! I updated the calendar entry with our proposed agenda but I think you are using this issue as the point of truth so, for convenience, here is our proposed agenda:


We have two main topics to discuss, both regarding WAI-Adapt TF's work...

  • Symbols - we would like to address present technical questions/blocks regarding authoring considerations.

  • Well-known destinations - we would like your views on the best way to proceed with this spec: we currently have two potential routes to implementation.


Please let us know if you have anything you'd like us to address for you.

I put down our APA IRC chat room as the chat link; hope that's OK.

@past
Copy link
Author

past commented Sep 19, 2024

Thank you Matthew, I updated the agenda with these topics.

@sanketj
Copy link
Member

sanketj commented Sep 20, 2024

@past Would it be possible to also include w3c/webappsec-permissions-policy#273 (PR: whatwg/html#4585) in the agenda for the WHATWG only session? cc: @siliu1

@past
Copy link
Author

past commented Sep 20, 2024

Thanks Sanket, added.

@ricea
Copy link

ricea commented Sep 23, 2024

I'd like to discuss Compression Streams, either with the WebPerf group or separately.
Main agenda items:

  • zstd and brotli. Is it acceptable to add support only for decompression?
  • Design of the options bag

@past
Copy link
Author

past commented Sep 24, 2024

Thanks Adam, added to the joint session with WebPerf as the WHATWG-only session is overflowing now.

@past
Copy link
Author

past commented Sep 26, 2024

Notes from the WHATWG-only session:

Attendees:

  • Chris Wilson (Google)
  • Panos Asthitas (Google)
  • Simon Pieters (Mozilla)
  • Jeremy Roman (Google)
  • Vladimir Levin (Google)
  • Anne van Kesteren (Apple)
  • Sanket Joshi (Microsoft)
  • Siye Liu (Microsoft)
  • Daniel Clark (Microsoft)
  • Kurt Catti-Schmidt (Microsoft)
  • Noam Rosenthal (Google)
  • Dominic Farolino (Google)
  • Domenic Denicola (Google)
  • Olli Pettay (Mozilla)
  • Benjamin Lesh (Invited Expert)
  • Khushal Sagar (Google)
  • Fernando Serboncini (Google)
  • Ryosuke Niwa (Apple)
  • Mason Freed (Google)
  • Michael Smith (W3C)
  • Chris Harrelson (Google)
  • Rob Flack (Google)
  • Joey Arhar (Google)
  • Ethan Jimenez (Microsoft)
  • Kagami Rosylight (Mozilla)
  • Di Zhang (Google)
  • Lea Verou (Invited Expert)
  • Many people potentially not logged here

Scribe: Jeremy Roman

Atomic move

whatwg/dom#1255
Prepared topics doc

dom: Noam and I have been working on this API in the DOM standard and Chromium impl
… allows you to move elements around the document without resetting state, most notably iframes without unloading
… also applies to CSS anim, text selections, and other state (we have a list)
… we have a prototype & spec PR
… TAG had feedback
… "instead of creating a new API (moveBefore), experiment with changing how other APIs work on the DOM to support these semantics"
… if we designed these from scratch, we might have landed there
… sounds reasonable but hard to measure the compat impact
… it was also proposed we could scope this to some of these (like the newer before() API)
… this opens a can of worms – what if some nodes you're trying to move are across documents (so can't be state preserved), or otherwise don't meet the conditions for atomic moving
… do we move only some? throw an error?

Noam: we also found it a bit weird that some existing APIs would have different behaviors from one another
… for some APIs, like replaceChildren, this would be very complicated because some elements are moved and some added in the same call
… there is some simplicity in restricting this behavior to a new API which only works on one element at a time

dom: if we needed another API that accepted NodeList, we could do that later
… the way we've approached it, moveBefore, seems simplest, though we're open to experimenting with other options – but there's a lot of complexity there
… we want your opinions

Mason: ideally we would go back in time
… in the current world, though, I think it would be really surprising if some APIs did this and some didn't
… so if you went down that road, you'd have to do all of them – and you mentioned some are hard, like replaceChildren
… but the bigger hurdle is compat

dom: appendChild especially is used in many places and might have a large compat risk

Mason: two roads: replace all APIs, new moveBefore API

dom: third path is only some

Mason: that's weird

dom: append() moving and appendChild() not does seem weird

lea: we suggested new APIs as a compromise in case we can't retrofit all the old APIs

Mason: but "only if it can" seems hard

lea: that seems entirely reasonable

dom: what if only some can be moved? do you throw errors?

mason: can't throw errors

anne: and if you ever wanted to move across documents…

Noam: if you ever wanted to run script during a move, the whole thing doesn't work anymore
… we'd need to reorder the whole thing – it's a very big change to any API that moves more than one node

dom: we just can't run script within a move of a single node, but could potentially between nodes

Mason: this is primarily an API for frameworks, I think, and you've been talking to them; what do they think?

dom: new API has been received well; we haven't asked about retrofitting
… I suspect we'd get vague compat worries from them
… are we being selfish as implementers by pursuing a new API because it's simpler for us?

Lea: what I was proposing earlier around cross-document use case: I wasn't saying some elements should be left behind, but if some moves can be done atomically then they should be; if they cannot, they are moved as they are today

dom: that was the original behavior of moveBefore – falling back
… feedback we got was to throw an error, but we can't do that if we retrofit
… it feels slightly magical if it's not predictable whether your iframe is going to unload or not, if it's just best effort

Domenic: +1 for predictability; DOM APIs are already full of dragons

Anne: DOM has long had two primitives: insertBefore, remove
… these have been reflected in mutation records, and operations bottom out at these two operations
… they end up working across trees, across documents
… this is fundamentally new
… those operations also have side effects for various elements
… this new operation is only supported within a document, and will have its own mutation record (or several)
… it's a very different thing from everything we have today
… trying to squint that they look the same will be confusing for web developers, and you'll have a lot of issues – not necessarily a model anyone likes
… what people want from these low-level APIs is that they're predictable and not too complicated
… then we can slowly start building on that if other operations want to

dom: pretty satisfied with the developer predictability argument

Kurt: have we considered adding a new parameter?

dom: frameworks think that a dictionary in such a hot operation may be slow

Kurt: a bool?

anne: you want to overload all the existing APIs, but still have them behave quite differently?
… starting to throw seems weird

Domenic: I tend to think this should be a different method

Lea: my main concern is that this preserves an existing footgun
… developers expect atomic reparenting
… authors using DOM methods is way more than developers that know it isn't atomically – it took me years to learn how they work
… many authors would go even longer not realizing this
… it's more predictable to fix existing methods because that is what authors expect – there is no reason for iframes etc to reload
… I'm concerned about introducing new methods every time we want to fix something and assuming there is compat risk, without actually doing the analysis
… we've done compat analysis for more minor things

Anne: it's not really about the compat – having wildly diverging behavior across documents is not great behavior

dom: other side effects, like mutation records, are significantly different

Anne: you get a really weird API

Domenic: we're not going to suddenly make sites better if we retrofit – just make the web more complicated

Anne: I'm sure it would break things because sites aren't prepared for new kinds of mutation records
… don't need to do compat analysis to see that coming

smaug: we should have the same mutation records

Lea: how would they change?

dom: another issue: moveBefore should throw an exception if it can't – any objections?
[none]

dom: there is a document linked to the agenda doc with more info
… smaug suggested we insert removal and insertion records with some flag, rather than a new kind
… do we need oldNextSibling, previousNextSibling, oldTarget, newTarget, etc?

Anne: I could live with what Olli wants

dom: is it too cumbersome to expect developers to do their own manual filtering to realize that these two records are a move?
… or a new option to MutationObserver?

Anne: context for MutationObserver: people already have to do some coalescing of the records

dom: I initially didn't think that was a strong enough case, but I've come around to Olli's recommendation

Anne: simplifies it a lot

smaug: MutationObserver was designed to provide very low level records

dom: almost resolved? can follow up on the GitHub PR

Observable API

dom: here with Ben from RxJs
… one big question: hot observables observe an underlying, already active resource that might already be able to produce values – observing it has no side effects. GitHub issue.
… the clicks could be coming in any time before or after, just tapping into the stream but there are no side effects
… cold observables, which is what the current ctor exposes
… takes a callback (producer), which is run every time you subscribe
… the idea is that the producer gets created for every single consumer, in a 1:1 relationship
… unlike promises, which are always "hot" (run producer immediately on construction, can then call .then as many times as you wish)
… the only web platform vended observable is EventTarget.when, which is a hot observable
… Anne asked Elliott Sprehn to formalize his feedback in the form of an issue (link?)
… cold observables are a footgun in that they might have some side effect or cost which isn't obvious just by asking for a value
… you might expect it to be like Promise.then
… very large Angular apps do this all the time
… he asked if we can make observables hot by default, like promises
… such an observable's callback would be invoked once, on construction
… any number of consumers would then observe this
… this seems like reasonable feedback, but nothing else in the observable community behaves like this (e.g. RxJs doesn't)
… maybe this would be an improvement, but it's different from prior art
… Ben is very opposed to this idea

Ben: people would stop using them if they were always problematic
… fundamentally, observable is an inverted iterable
… it is made to push instead of pull, and because of that, you can do sync things, async things
… that's why observables are cold
… Eric Meyer (sp?) wrote the first whitepaper years ago
… with a cold observable, you can make any observable hot by closing over it
… e.g. clearly a button already exists when you call when() on it
… Angular has a thing where they subscribe without you calling subscribe()
… binding it to an Angular template causes one subscription each time
… "omg, why did this fetch four times"
… because whoever implemented the HTTP client made it cold; it could have wrapped an in-progress fetch
… if we ship an always-hot observable, the things that are possible with observables will be diminished
… there will be edge cases around when we tear down, can we produce on first subscription and then ref count, how do we handle that?

dom: I think those questions are answerable
… ref count producer, tear it down when all subscriptions die?
… those are answerable API questions, but the big one is: do people feel that the behavior difference between observables and promises is big enough to try and course correct in that direction?
… possibly we just need to consult with more web developers; haven't heard this from many people, but Elliott's feedback comes from a massive Angular app with these issues

chrishtr: would it be possible to change the default to hot, but still allow cold?

Ben: I think that is plausible
… the biggest concern I have with always-hot is the lack of prior art and the fact that I know there are different footguns with that type

dom: or we could have different types for hot and cold observables

Domenic: I am extremely cautious about diverting from precedent
… but it would be nice if promises and observables behaved similarly
… I particularly like the model of hot observables; it's always seemed weird to me that obtaining the resource and subscribing were one operation
… promises separate these
… what would be convincing to me that hot is a terrible idea, is if you could point to some concrete difference between observables and promises to justify why this doesn't make sense
… the resource destruction/refcount thing doesn't apply to promises; I left a comment on the related issue

Ben: one of the biggest advantages of observables is the guarantee that if the producer errors or completes, or the consumer unsubscribes, it always tears down if it was set up as a cold observable
… that's not true of hot observables
… a large team at Netflix had a gnarly RxJs codebase; they decided to move to callbacks and demonstrated that they're executing less code
… memory leaks started appearing because they lacked teardown guarantees
… RxJs does ship some hot observable APIs
… someone will make a hot observable that is ref counted, e.g. containing a WebSocket
… synchronously someone closes it, then ???
… is there a way that we can delay what happens when there is a ref count; had to provide an API for that
… there's a bunch of subscribers; someone forgets to unsubscribe and then they see the thing that's leaking but they don't know why and have to find the site that forgot to unsubscribe
… you could of course solve these, but it's not devoid of footguns

Domenic: in addition to introducing a better model of event, they're also introducing a different way of doing resource management
… that's a very crowded space: AbortController, TC39 disposable, …
… very scary

dom: only does so using an AbortController

Domenic: I think I see what you're saying. With hot observables, you'd do so manually like today. With cold observables, it would be abstracted away so it automatically does the AbortController stuff for you (when you unsubscribe)?

Ben: the only way to unsubscribe is with an AbortController

dom: whenever you unsubscribe, it aborts the fetch

Noam: doesn't remind of promises, but does remind me of streams
… have to have a buffer on the other side which receives what you're going to get
… it seems more like that than an operation; stream doesn't continue if there's no recv buffer

sideshowbarker: maybe we should try to do outreach
… we often want to know what developers think – I'm willing to help with that

Ben: RxJs folks are of course used to cold observables
… but the RxJs core team plans to make sure that RxJs conforms and encourages people to migrate at scale, which could happen pretty rapidly
… RxJs is effectively on pause while this is going on
… if we do ship hot-only, it will be very hard to move because it's built on the idea of cold observables

API for visible caret position in textarea/input

Siye: briefly mentioned in joint meeting with CSSWG
… there is no way to get selection bounds if the current selection is inside the textarea
… solution today is to clone the textarea into a

and copy its computed styles, and then create a Range from that and use that to get its bounding client rect
… proposed solution: add a new API (getSelectionBoundingRect?) along with other APIs on textarea, like selectionStart etc
… want feedback

Anne: don't we already have ways to get start and end?

Siye: just the bounding rect API is new

Anne: sounds reasonable

Domenic: do you want to be more ambitious, like Keith's proposal to choose any offset start/end and not just the current selection

Siye: there is already caretPositionFromPoint, which reports the location

Anne: that doesn't give bounds
… instead of taking no params, function takes arbitrary start/end
… which means you can also use it for other kinds of ranges

fserb: isn't that on Range?

Anne: this would be on HTMLTextAreaElement/HTMLInputElement

Domenic: ranges don't go inside textarea and input

Anne: they have only offsets

Lea: could even default to selectionStart/selectionEnd

Domenic: support and maybe more than you wanted?

Siye: caret position already has a method to get bounding rect of current caret position

Anne: does that work for textarea?

Siye: yes
… it takes x/y coordinates; you need to know the coordinates of the word

Lea: one concern is this looks great in isolation, but if we're also going to pursue the ideas that Keith suggested – we don't want two different ways to get the same information
… if this is good enough, great; if extending range is needed, great – let's not do both

Sanket: one thing to clarify from what I heard of Keith's proposal: two distinct sets
… native caret/selection; authors building their own caret/selection also building powerful experiences
… this one is in the former category – leveraging the native caret/selection
… it is okay if the solutions for custom and browser selection are different

Anne: point stands that generalizing the API might be necessary for highlight use case, worth looking for other overlap

Keith: sounds reasonable based on my use cases
… DOM rect information is different from highlights
… I envisioned an API to straddle both, but might be two discrete use cases

flackr: curious about the use cases for the API
… bounds wouldn't tell you about line wraps, etc
… for a selection thing, you'd need more

Anne: enough to position suggestions or similar near it

Siye: use case is mostly from Keith's original post – popups inside the text area

Keith: range information allows getting multiple rects, line breaks
… might be nice to have an API that gets the overall rect, and one to get all of the line rectcs

Anne: you could get that yourself by querying with progressively longer intervals

smaug: you could union the rects [hard to hear]

Siye: I've heard you're mostly supportive but would like to see this generalized

Anne: work with Keith

Sanket: Support for getSelectionBoundingClientRect, consider expansions to include custom start/end offsets?

Keith: one to get rect, one to get set of rects

zcorpan: matches what Range has

Keith: that was my assumption about leveraging Range

Customizable <select>

jarhar: in pretty good state, but could give a status update

Panos: we'll come back to it at the end of the list

Companion windows

Explainer

Jeremy: wanted to mention this to this group, as it's something we're starting to explore. Something that sits somewhere between frames and popup windows. The problem to solve is that a lot of Multiple Page Applications (MPAs) have some part of the content that logically should persist as you navigate from page to page. (Support chat widget, video being watched, …) You can do this today with a popup window, but popup windows are not favored for a number of reasons, e.g. the connection to the site is somewhat tenuous. SPA sites do something similar to companion windows today, but it's not possible to do this with an MPA today. In an MPA when you navigate, all elements go away. So we want something that's like a frame in that it's part of the content, but like a window in that it's outside the Document.

Proposed capability: open them, query the open ones, position them. No nesting allowed. Stacking order issues. User agent provides fallbacks for how to manage them.

Anne: can you position stuff on top of it?

Jeremy: you can put it inside an element, like an iframe. "Project" it into the element. Important use case is a lightbox or consent popup or whatever needs to be on top of the companion windows. This matches existing SPA experiences.

Anne: The interaction with popover, fullscreen, dialog will be interesting. "Super top-layer?"

Jeremy: Not sure exactly how it'll work.

Anne: different from the partitioned pop-ins proposal?

Jeremy: yes. Partitioned pop-ins are confined to the Document's lifetime. Their goal is to go through an auth experience then return to the page; they don't outlive it. Some overlap in both being windows, and we're talking to the right people to maintain some alignment.

fserb: Would there be any UI element from the browser to control this, e.g. closing them?

Jeremy: my philosophy is that the UA should by default provide those affordances when it's in a docked or floating state. If the site declares it wants to present the companion window inline, then it's taking responsibility for providing those affordances. Note that after you navigate, it necessarily enters into a UA-managed mode. This is important so you don't have to modify every possible page the user might navigate to in order to accommodate the companion window from the previous pages. You don't want to get in a state where neither the page nor the UA knows about it.

???: do pages need to opt-in? E.g. cross-origin?

Jeremy: it should auto-close after navigating cross-origin. Fits with general security/privacy restrictions, e.g. you can already control the presentation of all content on your origin, and it ties into storage partitioning. If you want something that's going to persist across origins, you probably need a real pop-up window.

Anne: only allowed in top-level windows?

Jeremy: yes

Ryosuke: The video use case want to move to PiP-type mode without stopping the video. Seems impossible.

Jeremy: it works if you start the video in a companion window. Popping it out to PiP-type mode only changes the presentation style, so the video can continue without problems.

Robert: does this need to be a new API space or can we extend window.open()?

Jeremy: I tried to keep it consistent with window.open() but it probably should be separate, e.g. for discoverability API surface.

(also there was great sadness in the room about extending window.open())

Anne: also it'd be best not to allow scripting across the boundary.

Jeremy: an interesting question. I agreed initially with restricting it. But it should probably be in the same BCG so that implies allowing scripting?

Anne: not sure I agree. It could maybe be its own agent.

Jeremy: I don't have a strong feeling. Partners we're talking to would be OK using postMessage().

Anne: iframes and multiple realms within agents is a huge regret.

Jeremy: agreed that if we had time travel we'd do something different. But should we be consistent with the existing regrettable situation?

Anne: performance isolation?

Jeremy: yes, that is also a benefit from preventing scripting. Although you could separately apply COI or similar.

Anne: and preventing scripting would make it consistent same- vs. cross-origin.

Khushal: can this be shared among multiple tabs?

Jeremy: current plan is no, it stays within a single tab. Even same-origin. What if I had both tabs open at the same time side by side?

(more agent discussion)

Simon: should the opener be able to navigate the companion window?

Jeremy: probably? Why not?

Domenic: because navigating it would be an API surface that isn't postMessage(). Cleanest is to say you have to ask the companion window to navigate itself.

Jeremy: yeah, not sure everyone likes that purist approach, e.g. COOP-RP was regretted.

Ryosuke: where can the companion window appear?

Jeremy: it cannot escape the Document's rectangle. Can't spoof OS UI or other sites. In the UA mode it's probably something like position: fixed.

Prevent programmatic focus in iframe

Siye: discussed in webappsec
… this is where the spec is going to be updated
… there is a spec PR because there are two open issues
… parent frames can programmatically set focus into iframes
… what should be the default value of this feature policy – enabled for all, or for self?
… webappsec meeting reached consensus that focus delegation seems reasonable
… for second issue, meeting mostly supported default being self
… Anne asked what the existing default behavior is
… WK already prevents programmatic focus and autofocus in cross-origin iframes, which suggests default of self
… want to update spec PR to reflect default value of self
… open another issue to allow focus delegation (which WebKit allows today)

anne: permission policy?

Siye: no, today's implementation allows parent frames to programmatically set focus into a cross-origin iframe

Anne: seems okay because parent is in control

Domenic: makes sense to me as an editor

Anne: if the iframe itself calls window.focus, currently spec has no guards
… we probably need to add in some way

Siye: webkit prevents it

Dom: chromium has some guards too

Siye: feature policy will prevent that if the iframe calls window.focus

Anne: might be tricky spec work

Siye: we should update this spec PR to reflect that parents can set focus into iframe programmatically

Anne: sounds fine, we'll see when the PR is done

Sanket: sounds resolved

Siye: Resolved: Update spec PR to change default value from * to self, and allow focus delegation (allow parent frame programmatically set focus into child iframes).

placeElement

fserb: heads-up: starting work on placeElement to have live elements drawn into canvas
… breakout session tomorrow at 8:30, going through use cases
… would be nice to have people there
… I haven't done process of WICG just changing WHATWG spec; how to make sure we remain in touch with editors, get feedback, engage with this WG to move through WHATWG stage process
… we can talk tomorrow about the actual thing

chrishtr: you want to incubate in WICG, HTML editors to be aware of—

anne: open an issue against the HTML spec

dom: open an issue, agenda+ each time a decision is made that impacts

anne: I'd like there to always be an issue whenever someone wants to change the HTML spec, provides one place where we can track ideas over time
… if we don't have it there, everyone has to keep track of a dozen WICG things, a11y things, etc is too hard

fserb: worried about diverging reality; dom's suggestion sounds reasonable
… also asking for Stage 1

chrishtr: requires explainer, consensus in exploring the space, implementer interest, venue

anne: would have to propose an issue
… you also wanted editor help?

fserb: there are still open issues to discuss, but at some point we have to write spec text and will want feedback on it

NoamR: Google-internal spec mentor process can help

Ben: looking for feedback from someone who might use it?

fserb: tomorrow's breakout is a good venue for that

@past
Copy link
Author

past commented Sep 26, 2024

Draft minutes from the joint session with CSSWG+OpenUI+WHATWG: https://www.w3.org/2024/09/24-css-minutes.html#t07

Draft minutes from the discussion (without power!) on Tooltips, Hovercards, and Menus: https://www.w3.org/2024/09/24-css-minutes.html#t10

The rest of the joint session: https://www.w3.org/2024/09/24-css-minutes.html#t11 and https://www.w3.org/2024/09/24-css-minutes.html#t12

@past
Copy link
Author

past commented Sep 26, 2024

Minutes from the joint session with the CSSWG: https://www.w3.org/2024/09/23-css-minutes.html

@past
Copy link
Author

past commented Sep 26, 2024

Minutes from the joint session with the Accessible Platforms Architecture WG: https://www.w3.org/2024/09/26-apa-minutes.html

@ricea
Copy link

ricea commented Sep 26, 2024

How much time am I likely to get to discuss compression streams in the meeting on Friday? To cover everything I want to cover will take at least 30 minutes, so if there will be less time I will trim it to the absolute essentials.

@past
Copy link
Author

past commented Sep 26, 2024

How much time am I likely to get to discuss compression streams in the meeting on Friday? To cover everything I want to cover will take at least 30 minutes, so if there will be less time I will trim it to the absolute essentials.

We have 2 hours and 3 topics in the agenda, so you should have at least 30 minutes.

@ricea
Copy link

ricea commented Sep 26, 2024

We have 2 hours and 3 topics in the agenda, so you should have at least 30 minutes.

Thank you.

@LeaVerou
Copy link

Since the joint i18n meeting seems to have a pretty scarce agenda, what about adding whatwg/html#7039 to it?

@past
Copy link
Author

past commented Sep 27, 2024

Since the joint i18n meeting seems to have a pretty scarce agenda, what about adding whatwg/html#7039 to it?

I don't see why not. Added, thanks!

@past
Copy link
Author

past commented Oct 1, 2024

Minutes from the joint sessions with the Web Performance WG and the Internationalization WG:

Attendees:

  • Olli Pettay (Mozilla)
  • Yoav Weiss (Shopify)
  • Noam Rosenthal (Google)
  • Jeremy Roman (Google)
  • Bas Schouten (Mozilla)
  • Scott Haseley (Google Chrome)
  • Domenic Denicola (Google Chrome)
  • Anne van Kesteren (Apple)
  • Michal Mocny (Google)
  • Panos Astithas (Google Chrome)
  • Sean Feng (Mozilla)
  • Philip Tellis (Akamai)
  • Eric Kinnear (Apple)
  • Nidhi Jaju (Google Chrome)
  • Adam Rice (Google Chrome)
  • Shunya Shishido (Google Chrome)
  • Kouhei Ueno (Google Chrome)
  • Tim Kadlec (IE, SpeedCurve)
  • Dominic Farolino (Google Chrome)
  • Ryosuke Niwa (Apple)
  • Guohui Deng (Microsoft)
  • Keita Suzuki (Google Chrome)
  • Alex Christensen (Apple)
  • Kagami Rosylight (Mozilla)
  • Addison Phillips (W3C Invited Expert)
  • Lea Verou (W3C Invited Expert)
  • Jeffrey Yasskin (Google Chrome)

Scribe: Jeremy Roman

Consolidating fetchLater

Request Limit WICG/pending-beacon#87
Deferred fetching fetch#1647

NoamR: this is an opportunity to share a previous discussion
… what is fetchLater? it's the new incarnation of send beacon
… we want to allow people to send some information from the page, queued & flushed when the document unloads or a long period of inactivity/invisibility
… API is similar to fetch(), with one additional dictionary member (activateAfter)

NoamR: returns a promise, but the fetch usually won't happen until you're gone
… it does resolve if the inactivity case occurred, rather than unloading
… because of its last-minute nature, it has to fail immediately – throws synchronously
… if it didn't throw, it should be nearly guaranteed to send, though of course not absolutely guaranteed
… disagreement on quota
… quota is needed because this is a resource that belongs to the user – bandwidth after closing the tab, though the user can no longer cancel it
… 640 kb quota for a top-level tab, because it's user-closable – should be enough for anyone 😀
… a web page has many third parties, like adtech and RUM
… we want to avoid "empty cart in supermarket" – where people hold space before they're ready with their data
… 64 kb limit per "sink" (origin you're fetching to)
… third-party iframes complicate this – we treat cross-origin iframes like one of the sinks & it receives its own 64 kb
… many cross-origin iframes would do this even though they don't need it, so permissions policy on the iframe is required to delegate a fetchLater quota
… this has broad consensus so far – now for the rest
… some of the people who want to measure things don't have access to the creation of the iframe – often libraries embedded somewhere
… we've found that libraries in iframes only need to send a small amount of data (8 kb, 16 kb)
… this is not a security problem, just quota delegation for a shared resource
… we want to let 3P iframes still send a small amount of information without permissions policy, and deal with this problem outside the standard
… can disallow quota for bad actors
… people who use it need to be fault-resistant – cannot tell if some other library has already consumed the quota, so need to handle that case already
… appreciate that different vendors have different views; I think browsers can differentiate here

Anne: we see an accountability problem
… this is a powerful capability in that after the user closes the tab, a network request still goes out
… seems reasonable that the top-level origin (shown in address bar) and its delegates have access to this capability
… but offering it to arbitrary third parties gets murkier, and gets trickier to handle
… if you have 100 of these, would those together have 64 kB or each?

Noam: each one can send 8 kB max
… if you have 100 frames, each with fetchLater, the browser can decide that some of the iframes will get quota rejected

Anne: this doesn't seem like an edge case to me

Yoav: how many of those will actually call fetchLater, what's the UA-specific quota allowed without permission?

Noam: we don't want to constrain it in advance based on a hypothetical

Olli: would many ad iframes use this? I could easily see them all using it, if available

Michal: if there is an edge case where you exceed the global limit, could you use size as priority? motivate smaller payloads

Noam: need to make sure it doesn't expose what other iframes are doing – potential cross-origin leak

Michal: could you fuzz the global limit?

Noam: yeah

Yoav: then it's a numbers game

Michal: also true with an arbitrary limit – just make more iframes

Noam: some APIs already allow for this kind of behavior – sending a keepalive fetch is restricted to top-level by the standard, same with service workers which can stay alive after the document is closed
… Anne, you said you were phasing out that behavior?

Anne: service workers running past lifetime? regular keepalive?
… we might want to put those under the same quota policy long-term
… for service workers, we keep them alive not so they can do work, but because it often makes the next navigation faster
… but that doesn't apply in the close-tab scenario, so in that case we could potentially shut it down quicker

Yoav: one difference between regular keepalive and fetchLater
… restricted quota during short lifetime – one fetch keepalive, using quota – quota gets freed once send
… here it accumulates over the lifetime of the document

Anne: we're primarily concerned about when it happens after nav away

Yoav: most keepalives are not in that time

Noam: iframes, though, die at various times
… we reached a bit of a deadlock

Panos: what is the actual disagreement?

Noam: small change quota for iframes (e.g. 8 kb, 16 kb) without permissions policy
… disagreement is whether the spec should mandate that this doesn't happen, or whether the UA can allow it

Yoav: getting site owners to change embed snippets in the wild is hard

Noam: this is a big barrier to adoption for valid use cases
… at Google, we want more evidence this is an actual problem rather than constrain it in advance (even if other browsers do)

Bas: it's hard to predict how people will use it, but it feels like if it is "may", and Chromium-based browsers do that, it's feasible for web functionality to depend on it – maybe less likely in iframes

Yoav: people should have fallbacks aside from fetchLater, like sending beacons eagerly

Bas: unless it very rarely fails in Chromium browsers

Michal: if it tends to fail on other browsers, sites might be less likely to adopt

Anne: how does the scoping work? document scoped?

Noam: scoped to reachable same-origin document

Anne: if the iframe itself navigates, it might free quota on the parent? hmm

Yoav: and you send its data

Anne: if you remove the iframe, you also have to handle that

Noam: spec handles this

Bas: if there is a small default quota, does the permission default still allow you to remove it?

Noam: it could

Yoav: could we have two policies, one for each size?

Bas: would that make people feel better about it?

Alex C: introduction of small one is all about letting people do it without permission…

Anne: if the iframe navigates or is removed, I guess I don't really care if that ends up sending some data – but when the tab closes, it feels more fishy
… if there's a top-level navigation, then iframes don't get their data

Noam: don't know that in advance, have to fail immediately

Anne: just drop it in that case?

Yoav: people will just not use it

Anne: I guess you could eagerly fetch it?

Bas: that's what we're trying to eliminate

Michal: sites use page lifecycle events today
… visibilitychange, typically
… re permissions policy to disable, per-sink limit was useful because if you know the global limit, you can guarantee they're in budget
… if 3P iframes can have budgets that blow the limit…

Noam: iframe gets part of the global quota by default, then if you have 10 of them…

Yoav: if you have too many, you're out of quota
… small quota by default, extra (or less) by permission, comes from global quota

Anne: and parent can take it all away

Jeremy: couldn't iframes observe each other's usage?

Yoav: no, frames already know how many there are
… what about nested iframes?

Noam: doesn't nest – can delegate further with permissions policy

Anne: how does that work with the logic of permissions policy?

Noam: would need to have different default for top-level iframes

Anne: that would be new

Noam: need to discuss with some people not in the room

Anne: me too; seems promising

Scheduling API updates

TPAC 2024: WHATWG/WebPerf Scheduling APIs

Scott: a few things shipped in Chromium; Firefox has prototyped some of this
… can we consider migrating to WHATWG: HTML and DOM?
… a few issues to be resolved, but want to know what is blocking
… what blocks a PR from starting, vs from landing?
… scheduler.postTask(): prioritized task scheduling; given a callback and priority (integrated w/ event loop: user-blocking, user-visible, background)
… recently shipped scheduler.yield(): returns a promise which resolves in a new task, to remain responsive
… TaskController and TaskSignal, analogous to AbortController/AbortSignal
… that signal is inherited through yield() calls, so an async function can be scheduled with postTask and retain priority across yields
… ran origin trial with partners and shipped this month
… unified into one explainer (prioritized-task-scheduling.md), but these three ideas are further along and might be ready for adoption by WHATWG
… three main issues
… speccing event loop priority, priority inversions, naming (mostly for future APIs)

Bas: our internal scheduler was also called TaskController – really annoying 😆

Scott:

image

… this is what task scheduling and priorities look like in Chrome
… HTML allows UAs to prioritize based on task source, in an impl-defined manner
… network, storage, timers, postMessage, etc
… in practice, we mostly lump it in one priority ("normal")
… with prioritized task scheduling, user-scheduled tasks affect event loop priority
… user-visible goes with most other stuff, but user-visible yield() continuation goes above that
… open question: how much do we want to spec?
… is this note useful for other implementers?

Olli: need to be quite precise when defining scheduling because it can cause interop issues if browsers do different things
… workers are a separate thing

Scott: workers is similar but without some of the priorities

Bas: we don't do that right now

Olli: could do something similar
… but would be very interested to hear from WebKit, whether this matches their model at all

Ryosuke: we don't implement anything like this today
… would need to do quite a bit of work to do something similar
… we use the platform event loop directly, so we don't have control over when tasks run per se
… it is theoretically possible, but hard in near future

Bas: in support of this API, we found that the ability to accurately control priorities and the order in which things happen is incredibly valuable in improving the user experience – having that better specced would help everyone
… right now websites make specific decisions based on the order things happen in Chrome, so we somewhat have to emulate
… it would be nicer if it were specified rather than reverse-engineered

Scott: could be better tested, too

Bas: I agree with Olli that were something like this to be done, it would be good if it were specced with respect to other things happening
… flexibility is great, but don't actually have it in practice because lacking consistency makes website perform worse

Scott: DOM manipulation vs timer is not well-defined

Bas: even things like when GC runs; this is not exhaustive

Ryosuke: useful at least to test the difference between idle and the others
… that is clearly testable

Scott: background is lower than others, test that as well

Bas: I assume the Apple OS event loop does allow some kind of urgency?

Ryosuke: It does.

Michal: looks like four default priority levels, which map roughly to these – but WebKit might use them already

Alex C: some flexibility is good

Ryosuke: ordering between timers and things like postMessage, idle/background must be predictable across browsers
… otherwise we may get interop issues

Olli: if you call yield() on user-visible, task is before timers – that kind of case needs to be defined

Eric Kinnear (Apple): there are 4 tiers – mapping things roughly to those 4 tiers has worked well
… overpromising tends to lead to footguns
… in media use cases, you care a lot about exactly when a frame arrives
… but you can end up with developers inflating priorities, need to resist that

Michal: are those 4 priorities already used?
… in Chrome's implementation, we're splitting

Eric: 4 buckets that map to numbers within bands
… as you use more CPU time within a band, gradually decay until someone else can preempt you
… I don't know whether user-visible ever decays enough to overlap background

Scott: we used to have such anti-starvation mechanisms, but it would affect ordering in bad ways

Eric: also easy to be deterministic, but then everybody needs to be a scheduling expert
… just specifying that background never preempts user-blocking is good
… certain things are guaranteed to happen serially, but between queues of scheduled work there is no guarantee – other than that things at higher priority generally happen sooner

Dom: between which is there no guarantee?

Eric: units of work are put into an event loop, stored in a priority queue
… you can group them into what we call a queue

Domenic: tasks -> task sources -> task queues

Dom: expand each task source into several priority bins?

Bas: if they interleave with other task queues, limit of OS priorities becomes a problem

Ryosuke: for example, the idea of an IPC on input being higher priority than other user-blocking things doesn't exist for us

Alex: sync IPC?

Ryosuke: special case for that, but for input we're at the mercy of what happens to be running in the web content process

Scott: we can carve out arbitrary bands, including some that JS cannot directly access

Michal: is it WK code that decides–

Eric: within a task queue, ordering is guaranteed – given task queue has a priority band it runs at, but individual tasks can have priority band associated with the task
… priority inversions can happen – things earlier in the queue get a temporary priority promotion until it runs

Ryosuke: OS supports that, but WebKit doesn't currently use that

Eric: currently WK doesn't prioritize individual tasks within a queue

Bas: does WK use OS event loop on every platform? Windows?

Alex: kind of, on many platforms — there is an implementation that uses C++11's built-in thing

Michal: besides how hard it would be to implement – relative order of 6 priorities should be a hard guarantee – should every API hard specify the priority it will run at?

Scott: currently in spec, we have ordering guarantees for these new 6 priorities
… providing strong guarantees made it more predictable for developers

Eric: causing starvation is your own fault?

Scott: could also do a user-blocking timer task, but wanted to avoid timeouts because, web being bursty, background jumping ahead makes user experience worst most of the time
… can add hooks if it does become an issue

Bas: starvation is a risk you take by using the API
… in my experience, having non-deterministic behavior is disastrous

Michal: if you want anti-starvation, you can do that

Olli: idle tasks already have anti-starvation deadline (I mean idle tasks have already risk for starvation, if timeout isn't used)

Dom: drifting priority?

Eric: never into a different band

Scott: considered something along those lines, so one task source isn't starved, but not today

Eric: one risk is that some things happening here might be outside our control, like network packets and IPCs
… if we are too deterministic, do we lure people into assuming everything is?

Bas: limits to how much determinism is achievable
… ordering at least between postMessage priorities should be deterministic

Ryosuke: should we have a timeout, like idle callbacks?

Scott: collected some data about deadlines used in practice – were frighteningly low
… concerned people will use 100 ms
… could add metrics to monitor starvation
… could add onto that with a high priority task, use TaskController to change priority

Michal: timers aren't a perfect way to control this, but often another signal requires some work to be finished
… if you hit an event that depends on idle work, you can "flush" that work by boosting its priority – better than timers

Ryosuke: in the main thread, the very thing that says there's more urgent work might be waiting

Michal: more urgent thing would be running at higher priority

Scott: should expose these to important async work like fetch
… there probably are user-blocking and background fetch completions
… similar for MessageChannel
… want to agree on the base here

Bas: other APIs would gain the ability to fit themselves in this priority model?

Michal: yes, all continuations

Eric: sounds like you have to – when a packet arrives, we don't immediately know who it's for and so what priority to use
… if it's user-blocking, you need the ability to jump ahead
… don't just give everything unknown max priority

Ryosuke: in addition to task scheduling, also need to look into priority of network fetches and other things in the system

Michal: some desire to specify more about things in the normal "blue" box

Bas: would make implementer's lives better

Domenic: general agreement on six categories
… it feels bad to make a contributor block new features on creating an interoperable order for the blue bucket, but we do want to do that over time
… Scott, do you have a way to do this incrementally?

Scott: we could say that any way you can schedule a task should have the same priority by default, start there
… at least these will be relative to that, do the rest over time

Domenic: to restate: the spec would have 3 UA buckets – blue, bottom, top
… not say what goes in each initially, but over time

Scott: input makes sense in top bucket, maybe even higher than this one
… very short time to respond to input; both Firefox and Chrome treat it as absolute highest priority
… sites now use postMessage because timers give the 4ms delay when yielding
… maybe also postMessage priority? defaults to user-visible but can be prioritized?

Domenic: getting complicated – want to make sure you have a way forward

Scott: let's discuss on the PR

Dom: change definition of HTML "queue a task", except for things with specific priorities?

Scott: too rigid right now? but then again, we do that today
… I meant certain task sources

Domenic: would be nice to not update all call sites of "queue a task"

Scott: if we put this blue bucket in user-visible priority, there would be ordering that wasn't previously guaranteed
… all browser do this

Olli: in Firefox, timers are treated specially

Bas: timers don't have the same ordering guarantees
… once the timer is up, then it's prioritized like other normal tasks

Scott: we try to alternate between those and immediate/non-delayed tasks, to solve the "coming out of sleep" problem

Olli: we have something similar

Scott: may have to change the guarantees

Bas: necessary for Google Docs

Scott: naming issue shouldn't be blocking, I think
… let's talk about priority inversion – but might need a followup meeting on that

Domenic: Chrome and Mozilla are positive on landing the spec, so as editor eager to get it in
… does priority inversion block landing the spec?

Bas: feels like it can land without resolving priority inversion issue – Ryosuke?

Ryosuke: given earlier hallway conversation, maybe solved, now that there's a way to adjust priority
… need to think more, but probably resolved

Domenic: getting this into HTML will remove many worrisome monkey patches

Compression Streams

Adam: expose existing compression/decompression algorithms via WHATWG streams
… currently support deflate, deflate-raw, gzip (most popular!)
… graduated to WHATWG in April, CompressionStream used on 6% of pages & DecompressionStream on 0.12%
… want more codecs, more configuration, dictionary support
… 76 thumbs up on Brotli support issue
… all major browsers already have Brotli decompression code (br Content-Encoding), but chrome and Firefox don't ship compression code
… decompression would cost 2 kb for Chrome to ship, but compression 500 kb (on Android arm32)
… this is a blocker for Chrome until we can prove user value
… Brotli has better bandwidth usage and performance; some use cases (e.g. progressive web fonts) require Brotli specifically
… shipping both or neither is least confusing for developers
… this year, I'm coming around to compromising on shipping decompression only
… breakout earlier this week proposed requiring decompression support in the standard, permitting compression support
… Safari could ship both; other browsers ship decompression
… once developers adopt compression for some browsers, the usage might justify shipping it in the others
… try-catch can be used to fall back; a polyfill would be possible but more painful
… usually use the same naming as Content-Encoding, but br implies a specific window size – maybe we should call it "brotli"?
… zstd support: Chrome in similar position as brotli, though somewhat smaller binary size cost – 11 👍
… some rough benchmarks today for 4 KB JSON compression
… 4.9 compression ratio, speed was zstd > zlib ~= brotli
… brotli doesn't do especially well on this sample input, originally tuned for fonts and then HTML
… compression ratio for 150 KB of JSON in 3 ms – similar but brotli ~= zstd > gzip
… most interested in the question: do we ship brotli in the standard or not? want discussion on that now

Alex: since Wed, we have a PR – implemented and ready to go

Adam: tests?

Alex: a few
… we want to do this!

Bas: why is it so big?

Adam: brotli has a built-in dictionary which is 190 kb
… decompression dictionary is much smaller, don't know why
… also a lot of code in there

Yoav: brotli compression library in wasm, compressed with brotli, is about 280 kb
… would be surprised if C++ output is twice as big

Bas: are we doing some weird compiler flag?

Olli: does WebKit impression have both compression and decompression?

Alex: yes
… needs polish before merging, but would like to move forward, tired of waiting

Bas: 500 kb vs 200 kb would change the math

Yoav: if it's not a problem on desktop, would it make sense to ship desktop-only?

Adam: dislike diverging on different platforms

Yoav: feature detection

Adam: makes me sad 😭
… if it's optional in the standard, Chrome could do that
… interested in opinions on idea of making it optional, thought that would be controversial

Anne: no Android brotli library?

Adam: didn't look, but don't think so – also old versions

Jeremy: Is it big because of flags maximizing speed?

Adam: let me skip to another slide about conformance requirements
… should an impl that takes an hour per kb at level 9 be compliant?
… it might be unpredictable if some browsers produce larger output or take much longer to compress
… concerned about developers developing for one browser where it works well, realizing users on other browsers have a bad experience
… brotli or not brotli is easily feature detected
… if developers UA sniff for a good brotli implementation, that would make me sad
… e.g. a version that does only level 1 or no compression would be bad

Yoav: I think desktop/mobile split is fine, brotli/broken-brotli is bad

Bas: Jeremy just said different compiler flags might just change compiler speed, which might be more readable

Yoav: 5% slower, sure, 100% slower, no

Adam: we do compile brotli for speed but most stuff for size
… compiling for size might be an option, could investigate

Domenic: anyone want to answer Adam's question?

Noam: what would they do if they don't have brotli? another codec?

Michal: yes

Philip: need to detect server side?

Yoav: client usually knows what the server supports

Jeremy: adam said magic numbers can be used to detect sometimes

Bas: within Moz, we think the preference is to require compression capabilities
… I believe size concern comes mainly from Chrome
… we don't love the idea of optional compression but required decompression

Yoav: why?

Bas: developers have to handle two different options, handle both on server side
… put smaller developers at a disadvantage to implement that additional complexity

Yoav: from my POV, as a developer you're either doing upload compression or download decompression
… two distinct operations that each have their own fallback

Adam: compressing things for local storage – you need both

Jeremy: media does this?

Adam: yeah, common in media but people don't worry about it

Yoav: in the storage use case, you'd start by compressing it
… so this seems better than the reverse

Eric: okay to have it asymmetrical as long as they can't trap themselves?

Yoav: yeah

Bas: potential if you move data that's unsupported? I guess not relevant if decompression is unsupported
… minimal divergence is good

Adam: chrome has been stuck for years, because no benefit to users

Anne: add it to spec, Firefox and Safari ship it, and then Chrome evaluates later

Adam: if you won't be angry at us
… I don't want articles angry about Chrome

Domenic: you do want that 😆

Eric: say we didn't have support for Brotli compression nor decompression, code when I check if Brotli is available still needs to be written
… no worse for me as a developer if it's asymmetric because I have to write the same code

Adam: Yoav's example earlier suggests this is safeish for developers

Bas: becomes less and less true over time

Anne: could in theory write a single supports check

Eric: which is why it matters what order

Anne: would be nice to have simpler supports check

Domenic: what is Gecko's position? does gecko support both-or-none, even if chrome doesn't impl?

Bas: from what I've heard internally so far, a spec with only decompression but not compression is fine in the short term
… optional is where people have reservations

Domenic: don't have same binary size concerns?

Bas: no, though 500 kb seems like more than it ought to be

Domenic: at least one path is spec requires both

Adam: with spec editor hat, unhappy with chrome not following the spec
… with chrome hat, okay with it

Jeremy: failing WPTs?

Adam: yes

Bas: if adoption is high, that helps you

Jeremy: would developers adopt even if Chrome doesn't ship?

various: we'll see, but perhaps – easy to incrementally adopt

Bas: we could take telemetry to evaluate
… if I understand Chrome's concerns, older Android devices might not be able to update

Adam: yeah, disk full & get stuck on old version
… we do grow our binary size over time in general, but we just try to spend that budget sparingly
… okay, now compression options!
… level (various numeric ranges by codec)
… all codecs also support a window size (in log-number-of-bits)

Domenic: how will you spec it?

Adam: have to write down what we mean, because for deflate/gzip, browsers might use different libraries
… brotli and zstd also have multiple implementations

Yoav: this is nice for gzip, mandatory for brotli because differences are dramatic

Anne: have some validation of integers passed, not out of range, etc?

Adam: for level, want to clamp it to what is supported
… some impls of deflate go above 9, idk

Anne: if you clamp it, you also can't go above 9

Jeremy: browser-dependent clamping?

Adam: yeah

Bas: some API to get that?

Anne: once you go above 9 it's impl-defined?
… detectable in the output, presumably?

Nidhi: zstd level 9 is not the same as brotli level 9

Adam: these would be per-algorithm

Anne: we should have a dictionary per algorithm?

Adam: proposing different dictionary per algorithm, pass object at WebIDL operation level and convert layer

Noam: shouldn't we have BrotliCompressionStream etc?

Anne: want options for existing things, too

Adam: don't want too many different ctors?

Anne: matches HTMLCanvasElement getContext

Domenic: a little ugly, but not too bad

Michal: would make it easier to feature-detect?

Noam: yes

Domenic: try-catch is fine

Adam: dev tools catching on all exceptions is a thing

[various back-and-forth about different kinds of feature detection]

Adam: we would also like to add dictionary compression
… would also need an options bag for decompression, to supply the dictionary
… can get crazy compression ratios

Jeremy: any additional binary size?

Adam: negligible

Anne: does it take SharedArrayBuffer?

Adam: don't want it to, sounds scary so would need to copy anyway

Anne: seems fine, can always revisit

Adam: conformance requirements – any requirements on level of compression, speed, etc?

Alex: WPTs require something smaller for a large file

Adam: not requiring impls to do the impossible, just what developers expect

Jeremy: just WPTs with some specific inputs seem sufficient

Kagami Rosylight: are we happy to add brotli and zstd to the spec?

various: on brotli, yes


Input type=email

whatwg/html#4562

Addison Philips: general agreement on direction, need to update the PR

Anne: did the i18n group discuss it as well?

Addison: we've consistently discussed it; no controversy left

Anne: nobody is pushing for removing all validation?

Addison: would like to see left and right side be unicode-capable, path to do that

Domenic: okay

Locale and language tag related issues

whatwg/html#7039

Domenic: Lea isn't here for this yet

Addison: discussed today, some stabs at currentDir; not urgent if she's not there
… spec recommends implementation of localization of form controls in section 4.10.5.2, but this is inconsistently implemented and kinda handwavy
… would like to see implementations tighten that up to render date/time/number in a localized fashion, and strengthen to at least "should"
… can file an issue if you want

Domenic: imo, as editor, issue or PR is reasonable
… agree that it's weird that we have a non-normative/encouraged section
… would be good for the community to make it at least "should" and get implementer reasons for why they haven't implemented, or motivate them to fix it
… like this path
… section says "according to either the locale implied by…or the user's locale"

Addison: feel strongly it should follow input element's language

Anne: goes against what impls currently do, but agree that it would be better to match element language
… potentially need to ship more locale strings, because they need to support more languages

Addison: already needs to be best-effort, because you won't have all languages, so fallback applies
… probably why the "or" is there – should prefer language of element, but if unavailable the user/browser language is a good fallback

Domenic: Thanks for bringing this up

Anne: if different locales expose different sizes, could that be a problem? fingerprinting which locales are supported by the UA?

Addison: by examining input sizes?

Anne: yes
… if the locale set doesn't change over time, or doesn't change across a UA version, not an issue

Domenic: probably consistent with UA version

Anne: have been suggestions for downloadable CLDR data etc, but already seemed like a bad idea

Domenic: do date inputs already change size?

Jeremy: Intl.* APIs already expose something similar

Domenic: makes sense to have parity with Intl

Addison: Fuqiao, file an issue about this?

Fuqiao: ok

Addison: there are a number of issues in your repo about presentational things for date and time values
… is a semantic element around a string, which can be anything, and can assign time/date to that
… different presentational things might want to control the appearance of date/time values

Anne: formatting?

Addison: link https://github.com/w3c/i18n-activity/issues?q=is%3Aissue+is%3Aopen+label%3At%3Aloc_time

Anne: declarative version of the Intl. API?

Domenic: this is definitely something people want, unprecedented in HTML to generate content in light DOM
… don't know what to do with that

Anne: does it have to be in the light DOM?
… one idea around is that there would be CSS to control how it is displayed, which hasn't really happened
… could imagine CSS content properties taking some sort of date formatting function, taking it from the date/time attribute

Addison: could see something like that, invited Shane Carr, convenor TC39-TG2/ECMA-402 (Intl object)

Shane: happy to answer questions about this area

Addison: Intl has bag of options for people to use; you can compose weird combinations, which is somewhat unfriendly
… yyyy-mm-dd type "picture strings" have to be localized by people, which is unhelpful
… emerging standard called "semantic skeletons" which Intl and ICU are considering, which might be a basis for connecting HTML, CSS, and Intl together in some sort of useful way
… e.g. "I would like the time; it should have two-digit hours" and take care of whether am/pm or 24h clock is shown etc based on locale

Shane: I'm also a co-chair for Temporal proposal in ECMAScript; some of its primitives such as YearMonth would be useful to more closely integrate with HTML input elements
… one thing Temporal does well is non-Gregorian calendars, which HTML input elements do not support
… general principle of supporting semantic skeletons: it represents the full set of possible field combinations that make sense for display
… for input, the set may be the same or may be different
… for example, on output we support displaying the weekday, but on input that may not make sense because you could select conflicting values

Domenic: very helpful; I don't think that gets at the heart of the time output problem
… for stuff like Temporal integration, that seems good to me and we should do it
… people implementing Temporal might not feel comfortable with the DOM part of their codebase, but as editor that makes sense

Anne: lot to unpack in what you just said, I'm not sure these are tracked against the HTML spec but should be
… it would be helpful because it gives us more time when we next meet to prepare and see if we have questions
… what is a picture string? for calendar example, idea is that UA can localize which calendar it shows but that the submitted date is always in a [specific] Gregorian calendar
… would have to evaluate how big of a use case that is, but reasonable to track in principle

Addison: we should organize issues to track this?

Anne: we start with issues with problem descriptions, agenda+ them to allow people to prepare before meeting to avoid rambling
… at least for WebKit, we're interested in expanding the set of controls to address more use cases

Domenic: of the four issues, did you want to highlight any of the other three?

Addison: not today, watching them
… in our group, people felt we should add pressure to date/time thing because it's an area we have emerging needs

Anne: makes sense, especially now that Temporal is nearing completion, to think about how a declarative counterpart would be exposed

Addison: I expect Temporal to be very popular in JavaScript; much easier to grok than classical timekeeping

Anne: once it's there, people will expect it to work together

[later on, when Lea arrives]

Lea: lang and dir attributes give lang and dir on the element itself, but to get the actual lang and dir you have to traverse the DOM or use Element.matches
… easily solved by adding a computedLang/computedDir attribute which give you the actual ones
… tracking when it changes is important, especially for components to adapt the context they are dropped in
… browsers already have this information
… would be possible with a MutationObserver, but would be expensive and can't pierce shadow roots
… would be nice to have an event like languagechange which could be fired when the language changes; already have something similar on the global
… Elika was concerned that people will want to compare it with other things and roll their own language tag parsing
… I think you generally would pass it to other APIs, but Elika wanted an API to do this kind of thing
… Anne and I seem to be converging on computedLang that returns a string, languagechange event, potentially down the line computedLangMatches
… [?] would be harder to spec
… people don't like tearoff objects, so shallower design might be a better choice
… we want to make it as easy as possible for components to be i18n-sensitive

Domenic: +1 to the design you're converging toward
… have some thoughts about language matching

Addison: makes sense to me; in most places language and locale are exposed as language tag strings rather than clothed in objects
… would be good to be consistent here, even though the string could be abused
… if we provide the right APIs, developers won't need to do that

Olli: attribute/element on method
… maybe method is better because it might need to traverse in certain cases

Lea: it would be cached

Olli: I doubt implementers would be willing to spend the memory

Lea: don't they need to for the CSS pseudoclass?

Olli: what if you don't have CSS around?

Anne: computedRole?

Domenic: doesn't exist in webdex https://dontcallmedom.github.io/webdex/c.html#computedOffset%40%40BaseComputedKeyframe%40dict-member

Lea: chrome exposes one, but maybe with --enable-experimental-web-platform-features
… Here is a test: https://codepen.io/leaverou/pen/gONEqba?editors=1111 for el.computedRole

Xiaocheng: what will happen if it returns the computed value?
… other things, like spellcheck, use a property

Domenic: methods vs properties signal how expensive it is to the developer
… if it is likely to do a tree traversal, it should be a method
… we don't do this uniformly, but it's a best practice

Anne: I think spellcheck does a tree traversal?

Xiaocheng: in chromium too

Domenic: that violates a TAG design principle https://w3ctag.github.io/design-principles/#attributes-like-data

Lea: it does seem that at least in some cases, it would be cached
… if you use a function at all times, can browsers still cache it?

Anne: yes

Lea: primary motivation is to make it fast

Anne: no difference in implementation between getter and method
… if we want to use a method to signify it potentially does tree traversal, and some impls cache it, that's fine

Lea: in what context do you have a DOM but no CSS?

Anne: disconnected subtree

Domenic: page with no :lang selectors

Olli: DocumentImplementation created document

Anne: on all these trees, there can be lang attributes, .matches etc do work

Domenic: which is a method

Anne: don't necessarily want to optimize that case for something obscure

Domenic: method is more consistent with design principles and likely implementation

Jeremy: getComputedLang in that case?

Lea: a property would urge implementers to make it faster

Domenic: I don't like motivating implementer's performance tradeoffs

Anne: I wouldn't expect this to be in hot code, so it doesn't make sense to cache if it's mostly one-off calls

Lea: not one-off in web components – each time a component is connected, and when language changes
… maybe event would reduce how frequently you have to read it

Domenic: performance is still better because you don't have to loop through language tag

Lea: .closest('[lang]') is already faster

Olli: traversing in native code is much faster anyway

Lea: ergonomically, everyone in the thread expects a property
… all of the methods like getComputedStyle() give you multiple, not just one

Anne: I don't think that's the rule

Lea: also getBoundingClientRect

Domenic: plenty of get methods return primitives

Lea: something that gives you a computed IDL attribute
… isContentEditable is also a getter

Domenic: I don't think arguing against signaling performance is a strong argument
… can make faster by using more memory, or slower by using a naive algorithm
… fundamental algorithmic tradeoffs cannot

Anne: if the principle is there that we should use methods when something potentially expensive happens, we should use a method
… I don't think anyone would implement this as a cached thing

Lea: as we've said in TAG, these principles are rules of thumb

Domenic: I don't see any reason to violate it here
… now that we're discussing it, I think it should be a method
… can we talk about language tag matching?
… it's complicated; belongs in Intl if it were to exist
… it's hard to compare en, en-us, en-us-x-lolcat

Anne: CSS needs to do it but not interoperable at the moment
… example matches in Safari and Chrome but not Firefox
… John Q (?) told me it doesn't match because splitting on hyphen first

Addison: it's allowed to be well-formed in various ways (there's a regex!) and an additional level called "valid" wherein certain deprecated subtags get remapped
… well-formed is when the letters, digits and hyphens match the grammar of a language tag
… valid is when you look at the contents of the subtags, maybe do some remapping

Anne: if you have a string "1test", is that well-formed?

Addison: no; primary language subtags must begin with an alphabetic character

Anne: that's not interoperable today but can be fixed

Addison: web contains tags like "english"; nothing stops you in HTML

Anne: is "english" well-formed?

Addison: yes

Domenic: we should have an API for this on the platform; Addison said there are algorithms

Addison: filtering for promiscuous match, lookup if you want exactly one
… CSS uses extended filtering so you don't have to name all of the subtags (e.g. script subtag may or may not appear in a Chinese tag)

Domenic: would be good if that was interoperable, and we had an API probably in Intl (will discuss with TC39 rep)

Anne: having a thing that matches what :lang pseudoclass does, which takes two strings and returns a boolean

Addison: or maybe a few different methods

Domenic: computedDir

Bert: what happens when dir=auto, do you get auto, computed value

Anne: the way we determine directionality always returns a non-auto value; I would expect it to run that algorithm

Domenic: indeed it always returns one of the two: https://html.spec.whatwg.org/#the-directionality

Anne: this can be implemented more easily with element.matches(":ltr") etc
… this is more ergonomic but essentially the same

Bidi issues

issues search
w3c/i18n-activity#1819

Addison: 8-9 things open about bidi, very challenging
… our WG wanted to set up a working party between our groups to go through it

Anne: in principle sounds great, but not sure we have any bidi experts on our side
… within WHATWG community, not aware of bidi experts with free time

Addison: with CSSWG, we have a monthly crossover meeting with a hard agenda
… important to have people who can represent the WHATWG perspective

Domenic: I might be able to provide some WHATWG perspective, but we mostly want to know what to do
… also need to know what the implementers say, which overlaps WHATWG but is not equivalent
… David Baron has gotten involved in bidi issues on Chrome recently

Anne: it would be useful to know what type of questions we can help with, because it might be hard to help with the bidi stuff itself

Addison: if we worked through this set of issues and said "we think you should do X", how do we pressurize that for implementers and the spec?

Anne: if you provided a recommendation, we would talk to engineers and have them evaluate it

Domenic: cut us out of the loop, if we can find engineers to represent the implementer view to you

Anne: not sure how much time they can commit, but can look into it

Olli: this year, implementers have spent a lot of time on dir attribute as part of Interop 2024
… e.g. in shadow DOM there have been various changes
… it has been a focus area recently

Anne: there might be more people due to the dir attribute fixes recently

Addison: to restate: we should invest time in providing feedback on bidi issues that exist, and if it becomes fraught, raise it at WHATNOT?

Anne: great, and separately, reach out directly if you want to have a synchronous call with implementers, reach out to David Baron, Ryosuke Niwa, Olli Pettay

Domenic: as editors, we want to land the right fixes
… as WHATWG guardians, we want to help you get in touch with implementers and secure their consensus
… if you don't know how to find implementers, we can help connect you
… otherwise, go and talk to them and come back to us with the solution

Addison: I don't know who to call on yet, but the names provided here help.

Anne: you can share some thoughts and we can tag people in who might be able to help

Domenic: if there's an issue that needs implementer feedback, agenda+ and we can take action items to get implementer reps where required

Anne: you might not even have to attend the WHATNOT meeting; I'll route it for you

Domenic: you also had a specific bidi issue to discuss? w3c/i18n-activity#1819

Addison: we talked a long time about this today
… I shared our concern about resolving it the way it was
… if you had a piece of text with no markup, and it were a single RTL span, adding markup that isolates part of it shouldn't change the directionality of the subspan
… because we default to LTR, today, it does
… particularly in Arabic where numbers proceed in the opposite direction; when you do dir=auto the default LTR reverses the order

Domenic: fantasai and dbaron would be better equipped to discuss this

Olli: Chrome tried to change the behavior, had to back out

Domenic: David comments about that on the issue

Addison: we think the new behavior might be better

Olli: if it's not web-compatible, that makes it hard

Addison: consistent with what speakers of RTL languages would expect; better mirrors their expectations
… challenge for RTL authors has always been that they have to mess around with control characters to get the right rendering
… we want to make that less of an issue; isolates help but this is a corner case where default behavior is not giving RTL speakers what they expect

Anne: did you study the bug report that Chrome got for the new behavior?

Addison: we didn't look into it today, but I've read it in the past
… any time we mess with this, some will be disappointed

Anne: overall you feel it's better to break that website and have the other cases in the last comment work?
… generally reopening issues makes them very long and history muddled

Addison: makes sense

Jeffrey Yasskin: brought up negative number case from bug report
… discussion had three related cases: negative numbers (change breaks), ranges of numbers (change fixes in some languages), punctuation (I didn't think there was a clear use case, change fixes)

Addison: having concrete illustration of the problems is helpful
… happy to file a new issue outlining the different cases

Anne: could have a switch, but don't know if we want to go there
… if there are multiple correct answers and you primarily expect negative numbers, maybe you want a different algorithm

date/time related issues and locale-sensitivity in general

Anne: curious about accesskey case sensitivity
… oh, bad browser interop

Addison: and all the input is from i18n people
… most of the time bicameral languages do not want case-sensitive accesskeys

Anne: for ASCII it's case-insensitive, but outside ASCII it's more muddled

Domenic: Ctrl+S and Ctrl+Shift+S often do different things

Addison: when you set it on a menu item, which letter is underlined is generally not case sensitive

Domenic: I see
… accesskey is not a well-loved feature

Anne: some people want us to improve it, like GitHub uses it
… some use it as a poweruser feature, but because it's inconsistent (which activation key you need), they can't advertise/document it broadly
… some other issues: allocate an accesskey which conflicts with a browser built-in one

Domenic: we could fix the small interop issue here; does the i18n group have a recommendation?
… everybody agrees on Latin letters

Addison: users expect it to be case-insensitive

Domenic: in a Unicode sense?

Addison: yeah; Turkish example

Anne: did that algorithm depend on locale?

Addison: there is a Unicode casefold that is not locale-sensitive, and there's locale tailoring over it, which is a pretty short list

Domenic: later in the thread it's noted it's about the keyboard events, which may have already done some of this work for us

Addison: if it's the key code, maybe it's not so bad

Anne: also hard to test

Addison: can generate a key event

Domenic: e.g. could use an algorithm to specify which key codes match, which shouldn't be too hard
… might have to pick a particular Unicode alg variant

Anne: maybe easier to motivate as part of a larger effort to improve accesskey

@past
Copy link
Author

past commented Oct 1, 2024

Here is the broken image from the previous comment that GitHub doesn't let me update after multiple attempts:

image

@ricea
Copy link

ricea commented Oct 7, 2024

Here's my slides from the Compression Streams session: https://docs.google.com/presentation/d/18ZrTuyvQCoQH1QBbV4Q8wY7iSZujD7Inrfh1xcW5Bgc/edit?usp=sharing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

10 participants