TPAC 2024 meeting #326
Comments
|
I'd like to discuss the general concept of "tooltips" in the joint OpenUI & CSS WGs session, please. Some related links include: |
|
Added, thanks. |
I'd like to actually expand this to "tooltips, hover-menus, and other hover-triggered popovers". Same links work. |
|
Got it, updated. |
|
@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 |
|
Sure thing, done. |
|
@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. |
|
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. |
|
Added both of these. Jeremy, let me know when the explainer repo is up so that I can link to it. |
|
Can we add scheduling API updates to the WebPerfWG joint session? |
|
More customizable select issues for the joint session(s) have been created: |
|
Added both Yoav's and Joey's topics. |
|
|
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...
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. |
|
Thank you Matthew, I updated the agenda with these topics. |
|
@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 |
|
Thanks Sanket, added. |
|
I'd like to discuss Compression Streams, either with the WebPerf group or separately.
|
|
Thanks Adam, added to the joint session with WebPerf as the WHATWG-only session is overflowing now. |
|
Notes from the WHATWG-only session: Attendees:
Scribe: Jeremy Roman Atomic movewhatwg/dom#1255 dom: Noam and I have been working on this API in the DOM standard and Chromium impl Noam: we also found it a bit weird that some existing APIs would have different behaviors from one another dom: if we needed another API that accepted NodeList, we could do that later Mason: ideally we would go back in time 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 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 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 Domenic: +1 for predictability; DOM APIs are already full of dragons Anne: DOM has long had two primitives: insertBefore, remove 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? Domenic: I tend to think this should be a different method Lea: my main concern is that this preserves an existing footgun 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 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? dom: there is a document linked to the agenda doc with more info 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? 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 APIdom: here with Ben from RxJs Ben: people would stop using them if they were always problematic dom: I think those questions are answerable chrishtr: would it be possible to change the default to hot, but still allow cold? Ben: I think that is plausible dom: or we could have different types for hot and cold observables Domenic: I am extremely cautious about diverting from precedent 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 Domenic: in addition to introducing a better model of event, they're also introducing a different way of doing resource management 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 sideshowbarker: maybe we should try to do outreach Ben: RxJs folks are of course used to cold observables API for visible caret position in textarea/inputSiye: briefly mentioned in joint meeting with CSSWG 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 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 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 Sanket: one thing to clarify from what I heard of Keith's proposal: two distinct sets 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 flackr: curious about the use cases for the API 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 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
|
|
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 |
|
Minutes from the joint session with the CSSWG: https://www.w3.org/2024/09/23-css-minutes.html |
|
Minutes from the joint session with the Accessible Platforms Architecture WG: https://www.w3.org/2024/09/26-apa-minutes.html |
|
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. |
Thank you. |
|
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! |
|
Minutes from the joint sessions with the Web Performance WG and the Internationalization WG: Attendees:
Scribe: Jeremy Roman Consolidating fetchLaterRequest Limit WICG/pending-beacon#87 NoamR: this is an opportunity to share a previous discussion NoamR: returns a promise, but the fetch usually won't happen until you're gone Anne: we see an accountability problem Noam: each one can send 8 kB max 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: service workers running past lifetime? regular keepalive? Yoav: one difference between regular keepalive and fetchLater 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 Panos: what is the actual disagreement? Noam: small change quota for iframes (e.g. 8 kb, 16 kb) without permissions policy 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 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 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 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 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 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 updatesTPAC 2024: WHATWG/WebPerf Scheduling APIs Scott: a few things shipped in Chromium; Firefox has prototyped some of this Bas: our internal scheduler was also called TaskController – really annoying 😆 Scott: … this is what task scheduling and priorities look like in Chrome Olli: need to be quite precise when defining scheduling because it can cause interop issues if browsers do different things Scott: workers is similar but without some of the priorities Bas: we don't do that right now Olli: could do something similar Ryosuke: we don't implement anything like this today 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 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 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 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 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 Michal: are those 4 priorities already used? Eric: 4 buckets that map to numbers within bands 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 Dom: between which is there no guarantee? Eric: units of work are put into an event loop, stored in a priority 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 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 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 Bas: starvation is a risk you take by using the API 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 Bas: limits to how much determinism is achievable Ryosuke: should we have a timeout, like idle callbacks? Scott: collected some data about deadlines used in practice – were frighteningly low Michal: timers aren't a perfect way to control this, but often another signal requires some work to be finished 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 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 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 Scott: we could say that any way you can schedule a task should have the same priority by default, start there Domenic: to restate: the spec would have 3 UA buckets – blue, bottom, top Scott: input makes sense in top bucket, maybe even higher than this one 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 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 Olli: in Firefox, timers are treated specially Bas: timers don't have the same ordering guarantees 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 Domenic: Chrome and Mozilla are positive on landing the spec, so as editor eager to get it in 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 Domenic: getting this into HTML will remove many worrisome monkey patches Compression StreamsAdam: expose existing compression/decompression algorithms via WHATWG streams Alex: since Wed, we have a PR – implemented and ready to go Adam: tests? Alex: a few Bas: why is it so big? Adam: brotli has a built-in dictionary which is 190 kb Yoav: brotli compression library in wasm, compressed with brotli, is about 280 kb Bas: are we doing some weird compiler flag? Olli: does WebKit impression have both compression and decompression? Alex: yes 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 😭 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 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 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 Yoav: why? Bas: developers have to handle two different options, handle both on server side Yoav: from my POV, as a developer you're either doing upload compression or download decompression 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 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 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 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 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 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 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 Adam: yeah, disk full & get stuck on old version Domenic: how will you spec it? Adam: have to write down what we mean, because for deflate/gzip, browsers might use different libraries 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 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? 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 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=emailAddison 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 issuesDomenic: Lea isn't here for this yet Addison: discussed today, some stabs at currentDir; not urgent if she's not there Domenic: imo, as editor, issue or PR is reasonable 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 Addison: already needs to be best-effort, because you won't have all languages, so fallback applies 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 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 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 Anne: does it have to be in the light DOM? 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 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 Domenic: very helpful; I don't think that gets at the heart of the time output problem Anne: lot to unpack in what you just said, I'm not sure these are tracked against the HTML spec but should be 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 Domenic: of the four issues, did you want to highlight any of the other three? Addison: not today, watching them 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 Domenic: +1 to the design you're converging toward Addison: makes sense to me; in most places language and locale are exposed as language tag strings rather than clothed in objects Olli: attribute/element on method 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 Xiaocheng: what will happen if it returns the computed value? Domenic: methods vs properties signal how expensive it is to the developer 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 Anne: yes Lea: primary motivation is to make it fast Anne: no difference in implementation between getter and method 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 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 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 Domenic: I don't think arguing against signaling performance is a strong argument Anne: if the principle is there that we should use methods when something potentially expensive happens, we should use a method Lea: as we've said in TAG, these principles are rules of thumb Domenic: I don't see any reason to violate it here Anne: CSS needs to do it but not interoperable at the moment 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 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 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 Bidi issuesissues search Addison: 8-9 things open about bidi, very challenging Anne: in principle sounds great, but not sure we have any bidi experts on our side Addison: with CSSWG, we have a monthly crossover meeting with a hard agenda Domenic: I might be able to provide some WHATWG perspective, but we mostly want to know what to do 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 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 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 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 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 Anne: overall you feel it's better to break that website and have the other cases in the last comment work? Addison: makes sense Jeffrey Yasskin: brought up negative number case from bug report Addison: having concrete illustration of the problems is helpful Anne: could have a switch, but don't know if we want to go there date/time related issues and locale-sensitivity in generalAnne: curious about accesskey case sensitivity Addison: and all the input is from i18n people 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 Anne: some people want us to improve it, like GitHub uses it Domenic: we could fix the small interop issue here; does the i18n group have a recommendation? 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 Anne: maybe easier to motivate as part of a larger effort to improve accesskey |
|
Here is the broken image from the previous comment that GitHub doesn't let me update after multiple attempts:
|
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
view-transitionas a token forblockinghtml#10513 )Topics for the joint session with the OpenUI & CSS WGs
<select><select>UA stylesheet: [css-ui] UA stylesheet for appearance:base<select>w3c/csswg-drafts#10857<select>content model: Content model and 'what' to render for stylable<select>elements html#10317appearance: basestylesheet w3c/csswg-drafts#10866<select>w3c/csswg-drafts#10908<select>w3c/csswg-drafts#10909Topics for the WHATWG session
moveBefore) Atomic move operation for element reparenting & reordering dom#1255focus-without-user-activationhtml#4585)<select><selectedoption>element html#10520 (Clone timing)<select>elements html#10317 (Content model)Topics for the joint session with the Accessible Platform Architectures WG
Topics for the joint session with the Web Performance WG
fetchLater(Request Limit WICG/pending-beacon#87, Deferred fetching fetch#1647 )Topics for the joint session with the Internationalization WG
<time>and potentially having locale-aware presentational elements.The text was updated successfully, but these errors were encountered: