Meeting minutes
<westbrook> leolee: introducing the topic Scoped Custom Element registries
<westbrook> sorvell: to present slides
<Jayson> github issue links:
<Jayson> whatwg/
<Jayson> whatwg/
<westbrook> sorvell: status
<westbrook> ...: shipepd in safari 26
<westbrook> ...: behind a flag in chrome, blocked on today's discussion
<westbrook> ...: under development at FF
<westbrook> ...: polyfill in distribution, but not updated to the current spec/implementation in Safari, due to the issues today
<westbrook> ...: SCER is a critical piece to broader consumption across developer groups
<westbrook> ...: Thanks WebKit/Safari for bringing the spec to where we are today!
<westbrook> ...: shadowrootcustomelementregistry of null may leave children undefined
<westbrook> ...: API bound to element registration/import/creation
<westbrook> ...: remaining issues...
<westbrook> ...: initialize() should upgrade
<westbrook> ...: registry.initialize(el) sets el.customElementReigstry without upgrading the element, leaving the code in an odd state
<westbrook> ...: the element could be connected, have a custom element registry and _NOT_ be upgraded, likely never desireable
<westbrook> ...: example code to the state in the presentation
<westbrook> ...: reattachment will automatically upgrade, which is an even larger gap from expectation
<westbrook> ...: proposal: registry.initialize(el) _should_ upgrade all initialized elements
<westbrook> ...: similar toregistry.upgrade(el), but NOT shadow inclusive
<westbrook> anne: would you only expect the upgrade is the registry has changed, or regardless?
<westbrook> anne: do we call upgrade in the noop case
<westbrook> rniwa: you can call registry.initialize(el) on something that already has a registry
<westbrook> anne: similar to calling upgrade today
<westbrook> sorvell: the lack of connection is an interesting nuance to the question
<westbrook> sorvell: this is a weird case, but I'm more worried about when you are connected
<westbrook> sorvell: initialize also initializes the whole subtree
<westbrook> sorvell: seems like it should likely do the same in both cases
<westbrook> rniwa: regardless of registry?
<westbrook> rniwa: will we upgrade in that case regardless of registry?
<westbrook> sorvell: not proposing a change to upgrade(), which is called on a registry and only upgrades elements therein.
<westbrook> sorvel: proposing initialize() works like upgrade() without being shadow inclusive
<westbrook> justin: while SSRing if you pair initialize() and upgrade(), one works on a single shadow depth and the other works all the way through the tree of trees
<westbrook> justin: then you have to re-initialize() at each depth and then call upgrade() again
<westbrook> sorvell: in SSR, you'll likely have null registries in each DSD meaning you'll not have step through the whole process
<westbrook> rniwa: clarify the foot gun.
<westbrook> justin: maybe not specifically, but the need to call initialize() [shallow] and then upgrade() [deep] means you're repeating a lot of work in upgrade()...requiring this.
<westbrook> rniwa: now that we understand the issue, clarifies the proposed solution
<westbrook> rniwa: what is it has the same registry and had not previously upgraded()?
<westbrook> sorvell: proposal to "upgrade" without being shadow inclusive
<westbrook> anne: notices that upgrade() is across all registries (either errant in the spec or the implementation?)
<westbrook> sorvell: proposes the spec should align to that, especially if implementations do.
<westbrook> rniwa: is alignment with the proposed semantics
<westbrook> jayson: seems like this aligns with use cases
<westbrook> jayson: doesn't see a reason wy not, though he saw a conversation about this possibly being performance negative, but only because it's the same as the two step process used now.
<westbrook> leolee: no objections?
<westbrook> room: no
<westbrook> sorvell: now, null registries
<westbrook> sorvell: you can't have a null registry without a shadow root
<westbrook> sorvell: you have automatic flipping when you are attached and have a null registry where you get auto upgraded to the registry you are attached to
<westbrook> ...: proposal: set the registry for elements with null registries when the element is _adopted_ into the document
<westbrook> ...: preserves the ability to have a null registry in other cases
<westbrook> ...: show required code to this context
<westbrook> justin: explain microfrontend via CDN use case for parts of DOM having different scoped registries when SSRing their pages
<westbrook> sorvell: will move a more formal approach to this issue into the github issue
<westbrook> rniwa: clarity on why a null registry is desired will help gather support the path forward on this
<westbrook> justin: will support drafting use cases to drive that conversation
<westbrook> rniwa: let's revisit why null is needed
<westbrook> sorvell: about freely rendering the DOM without having to worry about preparing/synchronizing a registry
<westbrook> ...: wants this is available in shadow DOM right now, but ensuring it's possible on non-shadow contained elements, for similar reasoning
<westbrook> ...: allows for lazy loading of a scoped registry without automatically adopting the document's ancestor registry
<westbrook> ...: would be a really complex MFE, but maybe just a plugin in a WP blog
<westbrook> ...: things that wouldn't otherwise need to know about the registries
<westbrook> ...: being able to delay the application of the registry unlocks these interactions
<westbrook> justin: reiterated use case
<westbrook> ...: different teams make frontend for MFE delivery
<westbrook> ...: are using CDN, aren't using shadow DOM, need to clarify the segmentations to free delivery of each part of the page without hashing/branding the custom elements in that part of the page
<westbrook> sorvell: MFE is a super complex part of the issue, but at the level of a plugin system, where there's not a major team supporting the architecture, this disambiguation between registrations is equally important
<westbrook> ...: initial design was coupled to a shadow root, and evolved to element creation, so this may be mostly a remnant of that early structure
<westbrook> rniwa: clarifies if `<div customelementregistry>` effects the element or it's whole subtree
<westbrook> sorvell: subtree
<westbrook> anne: seems reasonable and close to what we're already doing with the shadow root
<westbrook> sorvell: because the attribute on the element isn't in a template, can it be a parse time configuration so later affectations do not effect the actual registry
<westbrook> anne: with that let's do the changes (1 and 3 in the slides) and then follow up later with a "customelementregistry" attribute on all elements later.
<westbrook> justin: points out that 1 is the only part blocking the chrome implementation shipping
<westbrook> sorvell: agrees
<westbrook> anne: looking for someone to drive spec updates on this "agreement"...
<westbrook> sorvell: would attempt to do so...
<westbrook> ...: thanks in advance for implementor support in this area.
<westbrook> jayson: agrees to support inline with his work on shipping this in Chrome
<westbrook> rniwa: this attribute and it's effects only address the current DOM tree, right?
<westbrook> sorvell: yes.
<westbrook> sorvell: not shadow root inclusive
<westbrook> anne: only a parse time solution, right?
<westbrook> sorvell: yes.
<westbrook> sorvell: only want to change the registries _when you want to_.
<westbrook> anne/sorvell: bringing up 3 later (being it currently throws) will be fine.
<westbrook> jayson: recap...
<westbrook> ...: 1 will ship
<westbrook> ...: 2 looking into adding the attribute to support same tree null registries
<westbrook> anne: 3 change createElement(), and attachShadow() as separate spec/test changes
<westbrook> justin: we have rough agreement?
<westbrook> anne/rniwa: seems like it.
<westbrook> jayson: who's ready to take 1 in the spec
<westbrook> anne: volunteers
<westbrook> justin: again, many thanks to everyone who's been part of this process!!
<westbrook> sorvell: so excited to break to global namespace after a long time coming, really appreciates all of the work that's gone into it.
domfarolino: Menu elements proposal
… menu is an overloaded term
… motivation: menubar and menulist is very common.
… menulist items could invoke things or have sub menus
… another motivation is that, despite being very common, the behavior is wildly inconsistent
… keyboard behavior especially is inconsistent
… or does clicking an item close the menu or not?
… or loop behavior through the menu
… second motivation: we've built a lot of the foundational pieces out now, so the time is good
… [explains the gif being show]
… the prototype uses little JS, thanks to new features built out on the platform
… [explains the code sample on the slide]
… re Navigation: menubars are commonly used in these cases
… but is controversial, and we don't really want this element to be used for navigation. The Navigation Bar proposal is meant to cover this use case
… [explains the ARIA role mapping slide]
… keyboard navigation: we've referenced different OSes and other tools, to build out the sensible defaults
… [finishes explaining slides]
… could be questions about legacy menu element
keithamus: arrow key navigation: is that spatially consistent?
… does a right arrow on open a submenu open a menu on the left because of screen constraints?
masonf: no, we want consistent keyboard behavior
domfarolino: I think it would be good to allow both in that situation
masonf: we should follow ARIA APG's suggestion here
keithamus: looping or not?
domfarolino: we're still discussing but we're hopeful it will come
… just want to make sure we think about confusing use cases
keithamus: unless you have a menu with 100s of items, it should be clear you've looped
keithamus: I'm thinking about the menu's in firefox's UI and how we could replace with this, so would like consistency here
sorvell: concerned it could be too opinionated
… there's a lot of things built out that means that devs could build this out themselves
… and it would enable devs to have the flexibility to customize
… so what's the benefit here?
… of using these opinionated behaviors vs using a template that's built out?
domfarolino: keyboard is tedious to implement, hard to build out
… and where things are very inconsistent
… a11y upfront, keyboard, and checkable state
masonf: menus are misused very often and get them wrong all the time
sorvell: do you support keyboard shortcuts?
domfarolino: not initially
sorvell: concerned about not using this then if I have different opinions about how this should work
keithamus: shortcuts: we could solve this outside of menus
sorvell: would be good to find the balance between wanting to customize parts of this with having to throw out the whole thing
domfarolino: we're not preventing it, it should be possible
… there isn't really anything preventing extensibility of this
… our survey of most websites found that this should be able to cover most of them
sorvell: worried about parsing-related concerns
domfarolino: to encourage them to not be used incorrectly, things like anchor elements are display:none by default but can be overridden
… at least until navigation bar happens
masonf: +1 to no change the parser
… how do we fell about new elements vs reusing existing?
<sorvell> new
domfarolino: reason for new elements: the existing one could do new opt-in stuff. It could work, but we prefer new
… but open to discussion
rniwa: in window or stick out?
domfarolino: in window
rniwa: some consideration about in the future to support native UI
… so let's keep that in mind as we design this
Kurt: how to style these? new selectors needed?
domfarolino: existing things seem to cover it all so far
Kurt: can customize how to popup? delay?
domfarolino: we talked about "safe triangle" pattern, but it's tricky JS
… so not built in at the moment
… have discussed default hover delay
justinf: what's the plan for safe triangle?
keithamus: could consider some click behavior to help out
… or setting menu items to active
westbook: should really consider safe-triange pseudo
masonf: need to study this, validate that it's true
JRJurman: checkbox and radio, how do you access them? are they in a form?
domfarolino: [shows slide with code on it] using a fieldset around the menuitems
… not form associated
justinf: talk about issue 1323
… google docs does this, figma does, and custom elements in here too
domfarolino: interactive should be sibling, because of nested interactive content
masonf: +1 nested interactives is bad
… gdocs example is possible with this proposal
justinf: what about table?
domfarolino: need to think about this. maybe some questions about custom elements as siblings
justinf: maybe a protocol or something
<Zakim> zcorpan, you wanted to say HTML usually doesn't hide things that's not conforming to content model, and to consider treating these as block in the parser
zcorpan: re hiding links: not something HTML generally does
keithamus: +1
… could see a reset stylesheet
zcorpan: also the parser: have these elements as block
masonf: for clarity, I'm ok with changing the parser for this
zcorpan: problem is that you can mix elements like <p>
<justinf> Can `<menulist>` just be directly nested in a `<menuitem>` instead of using the `commandfor` attribute?
domfarolino: will make a note and explore
Jacques: in many menu systems, you go deeper and deeper.
domfarolino: by default support click and drag
sorvell: not used to seeing submenus on mobile. How do these render?
domfarolino: no
… no native difference in rendering. but could use media queries if you need to
sorvell: could be problematic/footgun
Kurt: what happens when you have a large one? overflow scroll?
domfarolino: same as select; scroll overflow
… lots of similarites to select
domfarolino: concerns about fieldset vs menuitemgroup?
<justinf> fieldset here feels more like optgroup
anne: styling should be ok, if we fix fieldset styling
masonf: is it broken or just weird?
anne: not described in CSS yet, so this would need to happen as part of that
<jarhar> github bot, take up whatwg/
<jarhar> github-bot, take up whatwg/
<jarhar> github-bot, take up whatwg/
<jarhar> github-bot, take up whatwg/
base appearance for customizable select
jarhar: customizable select already in spec, listbox in document with list of options, want to make that customizable in appearance
… prereq issue, mobile platforms no way to get listbox , made PR to discuss
<Kurt0> https://
[show demo] Chrome canary with exp feature enabled, regular select with regular attiributes, show customizable already in spec. Multiple hard to use because need to select multiple using shift, base appearance has visual indication of what's selected
… renders similarly to drop down one
… size=4, 3 items, can only select 1
… [talking to demo] multiple size=1, pending outstanding OpenUI discussion, trying to get 2 listbox into spec
… positive mozilla position PR that redefines how influence dropdownbox vs. listbox
… hoping to make "multiple size=1" work on macOS
zcorpan: width of widgets depends on what's inside
jarhar: same as regular
zcorpan: should we solve it for regular ones
jarhar: hard to solve, can do it for case where button not replaced, using fieldsize property, open question whether to respect fieldsizing property, open to changing even if this shipped already
bkardell: people are now using it, are there OTs shipping this or customizable select, any feedback this not usable because can't go outside window
jarhar: if make list very long, will have scroll bar instead of escaping content, but to make this escape window is tricky
<lea> Just to add a use case around listboxes, laying them out horizontally can be pretty useful: https://
bkardell: dealbreakers for some devs, looking at electron, devs do wild stuff just to escape window (impossibly complicated), talk to VSCode (PWA version) that should just work that same way, but they do things to escape the window
… should be fine, consensus has changed, curious what's the feedback
jarhar: not huge pushback, launched "multiple size=1" in chrome, users filed bug that it doesn't escape window. In future primitives, we could make this work with customizable select.
masonf: developers understand they have a choice
bkardell: does this use native picker on mobile
jarhar: uses more native, iOS same
keithamus: appearance based, do we get same thing or native?
jarhar: get exactly same behavior
zcorpan: ship it
<sorvell> +1
room consensus, no objections
jarhar: want to do base appearance for "multiple size=1" afterwards, for base appearance
annevk: we can proceed with base appearance
lea: continue to be listbox on macOS, or just auto with appearance base, what's the intent?
… if listbox in same cases and another in others, might be confusing
zcorpan: trying to solve consistency between dropdown and listbox on desktop, proposal makes it more consistent
anne: appearance:base consistent on desktop, appearance auto it depends
lea: multiple shouldn't make it multiple ideally but that ship has sailed
<jarhar> mozilla/
jarhar: standarads position open, asking for review
zcorpan: will review
declarative css modules
Kurt0: i discussed this at web components and brought it up here a few times. i can share some context of the feature
*kurt shows demo on screen*
Kurt0: a big thing that came up at web components was consistency
Kurt0: consistency as in consistency with the existing style tag
Kurt0: it does behave a little differently here
Kurt0: domenic said to treat it static like an import map
Kurt0: which is counter to some of the suggestions from web components
Kurt0: what happens when the style contents changes? with the static way, it would be too late
Kurt0: there were some suggestions to look up the specifier from the import map and then replace sync the new contnets
Kurt0: would get it more consistent
Kurt0: curious what yall have to say about that
Kurt0: is this a good idea?
JakeA: would the same happen if you change the specifier?
Kurt0: yes that was my next question
<masonf> side note about this and the custom element registries thing: I'm sorry for suggesting "shadowroot*" attribute names. Way too long.
Kurt0: right now its all very static. nothing changes when you mutate
Kurt0: import maps go through an execution context and only run once
Kurt0: with a style tag folks expect it to be live
JakeA: aside from the text, would this have a sheet property? a cssom?
Kurt0: not on the style tag. it would be in the module map
Kurt0: you could import it throuh script and get it that way
Kurt0: you coulud replace things there and do that through script
JakeA: so you could modify that stylesheet and look at the text of this style it would override those changes? just replace sync
Kurt0: yes
Kurt0: this wouldnt be new, it would just be more consistent
westbrook: if i were to import with an import attribute something that was on the import map which had css
westbrook: the value that came out would be live
westbrook: what is the functional difference with the value that comes out here and the imperative use case?
Kurt0: there would be no difference, youre changing the same underlying sheet
Kurt0: it would be doing the same thing as if you imported foo here and then replace sync
Kurt0: theres no new scenario, it would just do that automatically when the contents of the style tag change
sorvell: i used kurts implementation in canary
sorvell: the stylesheet that you get in this div's shadowroot, its going to have an adopted stylesheet. you can access it and replace sync on it
sorvell: this is basically the same as if you messed with textcontent
sorvell: thats sort of similar to if it were directly imported
sorvell: i think the style text content should be live, the specifier should not be allowed to be cchanged
<anne> (That seems extra weird to me.)
sorvell: i think that jakes point about can you just apply the sheet in css, anyone that uses css is going to want that
sorvell: that should be part of the mvp
sorvell: i think youre going to get that feedback from csswg
Kurt0: @import ?
sorvell: yes
Kurt0: that it tricky because you cant do that with existing css modules, its broken
Kurt0: thats something i will look into
sorvell: when we discussed this at web components, one idea was - the syntax was import url, could be good to propose a css issue. maybe we could do at import module
keithamus: yes that was the thing we discussed, you can have this tainting thing so you couldnt allow at import modules with any stylesheet
keithamus: emilio said that was fine
keithamus: i dont want to speak for them but that seems tractable
Kurt0: ill file an issue and get that going, but i think it can be done in parallel
keithamus: i dont think this demo demonstrates the issue
keithamus: there are more compelling reasons for this
keithamus: for the replacement
keithamus: the shadowroot adoped stylesheets is ordered. if you dont load it in the right timing then youre stuck with unresolved modules and silent failures. i think its important that we make this live
keithamus: on the topic of changing the specifier, if you dropped type module does that become a regular style tag?
Kurt0: yes
keithamus: you could have a module stylesheet and if you drop type module it becomes a global stylesheet?
Kurt0: thats not how i implemented it, that would be good to discuss
Kurt0: i freeze the type when its first connected, you cant turn it back from a module into global
Kurt0: if this is soemthing people want then it could change
keithamus: i dont think its desirable, but its interesting that you locked it
Kurt0: this was another side effect of following the import map because they have an already started flag
keithamus: does that mean that you could drop type module and also the text content and it wouldnt update the module?
keithamus: if it was live you couuld make it un-live by dropping module?
Kurt0: yes
keithamus: fine, but weird
<sorvell> this is way more like a `<script>`... we need `<style-script>` lol...
lea: i would expect the content and the specifier to be live
lea: if we dont want authors to assume this then we should change the api
lea: import maps already have semantics that the script only executes once. i wonder if we could piggy back on import maps for this
lea: i expect the sheets to be live
lea: we should just design it to be live
<bkardell> `<script type="css-module">`
lea: when esmodules were designed, the way to specify between urls and specifiers is well defined
lea: this goes beyond at import because adopted stylesheets also takes imports
lea: you need to disambiguate that its a specifier not a url
lea: as long as adopted stylesheets takes urls, then you dont know whether to specify it as a url
<sorvell> Why does it need to take a url?
lea: since shadowroot adoptedstylesheets then we could introduce the same semantics
lea: once that ships, then that will be very hard to change
lea: once we figure that out then yes at import how you disambiguate
lea: one way to do that is at import takes a url fn or a bare string
lea: not sure how compatible that is
lea: i suspect that is web compatible in which case we could do it that way
Kurt0: the bare string it tries to treat it as a url
lea: yes but how many people are doing it
anne: no
lea: the way its defined right now, you can specify it in shadow dom and you have specifiers everywhere and there are issues with that
Kurt0: there were some concerns about it, but this is how it works for the inherited ones
anne: on the topic of mutability, i guess i dont feel super strongly but it should be consistent across the whole feature
anne: if you can mutate the stylesheet then you should also be able to mutate the attributes
anne: last time, we talked about importing the global map and whether thats desirable
anne: if we ever get to declarative custom elements, then how might we want to reuse features like this? in that case i dont think you want it to be global
anne: if we want to be more explicit that this is for the global case, then make it clear which use case this is addressing
Kurt0: yeah i think thats a great suggestion
JakeA: are import maps mutable already?
JakeA: if something has already imported that, then what happens if anything else tries to import?
Kurt0: import maps are static, you cant revoke it
JakeA: so if changing the modifier can't work, and to annes point we should be consistent, then we should not support mutability
Kurt0: then there is that feedback that its a style tag and it acts different
Kurt0: you cant just revoke that unless we change how import maps work which doesnt feel like the right now
JakeA: if you run attach shadow to something with a declarative shadowroot then it empties out the shadowroot children. what does it do with the stylesheet?
Kurt0: it should do the same thing as adopted stylesheets
Kurt0: it clears the adopted stylesheets
anne: adopted stylesheets are retained
rniwa: we could enhance it by clearing it but that would be a change
bkardell: so it keeps the adopted stylesheets currently?
anne: yes
anne: the shadowroot is retained
bkardell: you could manually clear it with script?
anne: yes
rniwa: one thing that started to bother me was in the scrip tcase theres no restriction that adopted stylesheets exists, you can just adopt any stylesheet
rniwa: it seems arbitrary that we need to be consistent with ?? in the current version
rniwa: idk what problems that would pose but it does seem like a discrepancy with imperative vs declarative api
<sorvell> confirmed, sheets are *not* cleared
Kurt0: in what sense? i get that it has to be a module script, but what would you suggest to make it more consistent?
rniwa: we could design api where this concern of whether styles are imported as a css module or not separate from this adopted stylesheets
Kurt0: in a declarative way?
rniwa: conceptually we should have parity between js and css
rniwa: for the script based approach you can use either regular css constructor or stylesheets
rniwa: but for the declarative model we are restricting this to work just with css modules
Kurt0: the reason is that you can already do a very close equivalent to the non module case with the link tag, link rel stylesheet, that gives you something thats not a module
Kurt0: this gives you the adopted stylesheets array
Kurt0: it doesnt populate adopted stylesheets but it does do the tree scope
<anne> That brought to mind that this is also different from `<script>` vs `<script type=module>` in that the latter still applies to the document, but `<style type=module>` wouldn't.
Kurt0: you can have a non-module stylesheet declaratively already but you cant do that with modules today without this
sorvell: the processing model that we actually want is script
sorvell: making these scripts imo makes more sense
sorvell: but people freak out and dont want to see styles in scripts, so we are left with a weird looking style
sorvell: somethings going to be weird. having said that, i would argue for changing the text content changes the thing
sorvell: using urls in the adopted stylesheets array doesnt seem like it works that well right now and i dont understand how it will work, and i dont understand why its important
sorvell: i dont understand how youre supposed to make the style available. it doesnt fetch right now, but theres not a good way to get the style
Kurt0: i have a local prototype that does do the fetch
Kurt0: which is not great
JakeA: can you explain how its supposed to work?
sorvell: i saw your wpt kurt, and the thing you did was imported the style via a css module in a script and then set html unsafe
sorvell: i did the same, but thats not the use case we intended
Kurt0: it currently doesnt initiate a fetch, so if the fetch is already complete. i had to use sethtml because the template tag doesnt create declarative shadowdom unless you set html unsafe
Kurt0: i agree that is weird, but the current behavior today is that it looks at the module map for that specifier, it could be for something long finished
Kurt0: it looks to see if that specifier is there
Kurt0: what i have prototyped is it does a fetch and then appends it to adopted stylesheets array
Kurt0: that gives you a cleanear api
JakeA: flash of unstyle content
westbrook: you can make it work
keithamus: you could author a page where you have a link prefetch and then someone removes a prefetch and its a silent failure. its not just a flash of unstyle content, its no content. you have to do a fetch
JakeA: even with a prefetch it would be a race condition?
JakeA: its when the fetch completes?
<zcorpan> FouC is also not great
noamr: it just cant fetch in this syntax because you need crossorigin and priority, you cant just add a bunch of attributes with urls and expect it to work
noamr: this is two features. one is making module scripts available as adopted stylesheets, the other is having inline elements appear in the module map
<lea> +1 noamr
noamr: the second one is what makes the mutability question interssting. if would be intersting if you had inline scripts availble in the module. if you change the script or remove it what happens then?
noamr: maybe it would have been easier to reason about if we started with eextranl styles in the module map
noamr: you can mutate them if you go into them with script
noamr: on top of that, think about inline elements in the module map and solve mutability there
noamr: thats where inline elements in the module map are interesting
noamr: when you can declaratively do it. worth solving, but when solving both of these together you get into weird sitatuations where it feels like its too big
lea: we dont want styles in script tags
lea: i think were doing two things. the actual css code inline and then the mapping of specifiers. these dont have to be in the same place
lea: +1 to what noam was saying
lea: can you make a specifier and then in js use that specifier?
lea: regarding race conditions with fetch
lea: order is preserved with fetch
lea: about mutability, you can import and object and then change its properties
lea: if you think about it that way then mutating the content makes sense, but changing the specifier doesnt
<sorvell> +1
lea: if this is tied to the style element
lea: if you do it with import maps then thats also solved
lea: using import maps would solve all of these problems
Kurt0: that is what happens. that creates an import map with a blob url
lea: why do we need a blob url? we already have a way to link two fragment sin the page
Kurt0: it could either be a data uri or a blog
*blob
Kurt0: i had switched to a blob with concerns that it will be better performance
lea: performance changes
lea: as a broader point, this has a lot of css implicatations and should be discussed at csswg
lea: it seems to have changed since the last csswg discussion
lea: that is not something to be decided here
Kurt0: the plan for importing modules will be csswg
lea: i will discuss that at csswg and get coherent story
Kurt0: i wonder if we made it type static module that would make it more clear
anne: lets do ideation later
JakeA: to go back to url thing, whats the way that devs are supposed to use it?
JakeA: it will fetch. how are devs supposed to use it if flash of unstyled content is not acceptable?
Kurt0: use link preload, and other than that some script that waits and does a callback to proceed
JakeA: +1 to bringing back to csswg, need to load those in a render blocking way
zcorpan: only works if you do it before body exists
rniwa: reiterating point just made, we need to block rendering
Kurt0: so block until fetch is complete, and if it doesnt finish, would it keep blocking?
zcorpan: if you have a link stylesheet that never complletes
zcorpan: regular stylesheet blocks rendering
zcorpan: in head
<sorvell> why not add specifier to link?
JakeA: thats the fundamental way to avoid fouc
rniwa: without it youd have fouc everywhere
Kurt0: then the fetch version is like warning dont use this
anne: maybe we shouldnt add it
Focusgroup
Jacques: presenting
Jacques: Problem today, authors create control patterns with arrow key nav
Jacques: listen to key events, a lot of boilerplate, no standard or consistency
Jacques: manual implementation of toolbar with buttons, use tabindex, keyboard listeners, think about reading order etc
Jacques: focusgroup would help a lot
Jacques: move around with arrowkeys
Jacques: first token 1d vs 2d, minimum aria role
Jacques: modifiers, wrap, arrow key restrictions up or back do the same thing
Jacques: last focus memory, authors may want to remove it
Jacques: why not new elements?
Jacques: more flexibility, don't need to refactor everything
Jacques: can extend focusgroup
Jacques: two different kinds of keyboard navigation, tab+shift-tab, and directional
Jacques: get into focusgroup (explains behavior of demo in slide)
Jacques: don't need to set tabindex=-1 on everything except the current active element
Jacques: advanced usage exist, can use focusgroup=none in a subtree
Jacques: if you hit tab, enter into opted-out subtree, hit tab again you get back
Jacques: goal of focusgroup is to allow authors to opt into behavior but allow flexibility
Jacques: feedback?
Jacques: have a draft spec in whatwg/html
rniwa: very complicated topic
rniwa: none of the exmaples match safari by default
rniwa: I think we need to be very mindful of different platform conventions
rniwa: we need to be able to support different divergent behaviors
rniwa: users expect things to match platform conventions
Jacques: have discussed safari behavior, if user don't have keyboard navigation enabled, UA can choose to not make this available
masonf: thanks for working on this. You should talk to the ARIA WG
masonf: we would like to use this capability for the menubar element
masonf: menu should get the behavior by default
Jacques: interested in how to do that, new to spec land
frehner: similar to mason's point, overlaps with menu proposal
frehner: if there's an established proposal, but want to customize it, would you be able to put these on menu to change behavior... seems complicated
Jacques: might be tough
masonf: if menubar come with this by default but you can override, seems fine
Jacques: ok
sorvell: there's a setting for this
sorvell: chrome nor firefox honor the OS preference
sorvell: already not consistent
sorvell: focus priority, anti-pattern?
Jacques: used to be tabindex-based
Jacques: don't like it, but you would previously set tabindex=-1 on everything except current active
Jacques: expect active element to be where focus is
sorvell: why not automatic?
Jacques: doesn't manage focus state
Jacques: author uses JS to manage
sorvell: radio buttons are closest analog for native behavior
sorvell: active one is selected when you focus first one
sorvell: maybe don't need this
Jacques: authors may want to influence
sorvell: tabindex is basically deprecated
sorvell: why encourage it
masonf: I think it's not like positive tabindex
masonf: button or div don't support it, shoudl be equivalent to radio checked
Jacques: only thing you hit when tabbing through
masonf: once you tab into it, you enter where you left
Jacques: right
sorvell: ok that makes sense
keithamus: would autofocus attribute work?
anne: (shakes head)
keithamus: if autofocus is in focusgroup? don't focus?
rniwa: shadow root has this behavior
rniwa: can delegate
rniwa: can have autofocus
LeoLee: are we close to stage 2?
domfarlino: seems like stage 2?
anne: would be good to have some more investigation into rniwa's question, that it honors platform behavior
Jacques: something specific you're looking for?
masonf: currently, the items in a focusgroup, need to be focusable... doesn't need to be common across browsers
masonf: what's focusable is up to UA today
Jacques: that's where we landed
keithamus: does it change the solution? or blocker for stage 2?
anne: some parts are focusable by default
anne: need to be able to specify what thing it is like
rniwa: point is breader, not certain that the behavior described here is a thing that exists on native
rniwa: when we're designing this, make sure we respect platform conventions
anne: haven't looked at latest PR, whether it integrates with the current focus algorithms
cwilso: so look into that, then revisit stage 2 question
domfarolino: does the PR integrate with focus algorithms? or sidestep?
Jacques: it has been updated to attempt to do that, not evaluated yet
cwilso: lunch
<cwilso> RRSAgent: make minutes
meta name rating
<jarhar> bvandersloot: *presents slide deck*
<jarhar> keithamus: theres many sites like social media sites where some content is adult and other is not. is there any interest in demarkating regions as adule?
<jarhar> *adult
<jarhar> bvandersloot: it doesn't have the benefit that this system is already in use. if you set this attribute on the tag, does that mean display:none?
<jarhar> keithamus: there could be some agency of the site author, but it could hook into the os control settings
<jarhar> bvandersloot: yeah we want to expose however we can
<jarhar> keithamus: does it matter if we are interested or if governments are interested? in the UK, OSA is a bit of a disaster. as far as we can see they want to double down on the issue and not look at ?
<jarhar> keithamus: this sounds great and we could work on this, is that going to meaningfully ?
<jarhar> bvandersloot: i dont have the power to make them do anything
<jarhar> bvandersloot: uk civil service was in the room and there was interest in several parties in the room, i cant imply that they had interest, but this sort of shape was interesting to some people in the room
<jarhar> keithamus: there 3 shapes?
<jarhar> bvandersloot: device has any sort of say and listens to platform signals. all of these are different than you having a digital credential in your wallet and being prompted to share your id with websites.
<jarhar> bvandersloot: we could do nothing. the government can ignore this work and we can ignore the gov, and the work in the digital credential api will be the only thing on the web
<jarhar> AramZS: its dangerous for sites to self identify
<jarhar> AramZS: we will be required on sites to have this meta tag, and it will change how we are indexed by search engines. governments will sue browser agents and forcing them to enforce their definition of adults, and then web browsers will block LGBTQ content on a new site for example
<jarhar> AramZS: browser choosing is much better
<jarhar> AramZS: if governments dont like it then instead of dealing with browsers they will deal with content publishers
<jarhar> AramZS: it is pretty important that we dont do a meta tag in this way
<domfarolino> +1
<domfarolino> +1
<jarhar> AramZS: easy to see how this works in history. in the us we have the comstack act. the question about what to do with under 18 users should be done with the publishers of the content
<jarhar> bkardell: you said that this is being used now? do you have httparchive stats?
<jarhar> bvandersloot: in the top million random httparchive ones, middle of the year was around 5000 sites?
<jarhar> bvandersloot: its not universal among adult sites
<jarhar> ErikAnderson: for the meta tag, its just extensions?
<jarhar> bvandersloot: yes
<jarhar> ErikAnderson: for safe edge supports this as well. i believe supports you meant? at one point in time it would enforce a safe search
<jarhar> bvandersloot: ive had a bit flipped in my browser and i dont use bing
<jarhar> ErikAnderson: if im in a regulatory regime then i might as well mark everything as adult and i dont think thats great for kids about how to reduce friction for most users and only prompt when they need it. server should handle it browser should not passively emit it
<jarhar> domfarolino: i just want to +1 what AramZS said
<jarhar> marcos: i want to reitate everything that aram said
<jarhar> marcos: the risk for censorship is very high
<jarhar> bvandersloot: prefers safe is where the signal is being broadcast
<jarhar> bvandersloot: the site could just block everything and set prefers safe
<jarhar> bvandersloot: or they could be told to implement digital credential api
<jarhar> marcos: its deceptive to say that the site wants your full credentials
<jarhar> marcos: if they need minimum age that could be the only piece of information
<jarhar> marcos: there is a risk of give me your whole drivers license or do you meet the minimum age requirements
<jarhar> bvandersloot: im trying to present this assuming theres pitfalls like overasking
<jarhar> marcos: idk if this is sufficient since its been around since 2006. already used by netnanny, has not made enough to block anything
<AramZS> I will note, for the minutes, that right now the Texas law will almost certainly require news organizations to censor themselves and block U18 app users via mechanisms they have required on the app store. It will likely spread to other US states. The risks here are very high and the censorship problem is very clear.
<jarhar> marcos: standardizing it may help, but wont be enough
<jarhar> marcos: feels like we are placating regulators
<jarhar> bvandersloot: the existence of these kinds of signals was surprising to some
<jarhar> michael: on the meta tag i didnt know that there were browser interventions by it. the tag was introduced by google because of safe search and they wanted to give sites a way to say that this page should not be shown in safe search. its already widely adopted because sites because the search engine
<jarhar> michael: i think its a much better fit for that, and i agree with aram that pushing it into the user agent is bad
<jarhar> keithamus: i agree but i also dont see prefers safe being any better because rather than forcing sites to put adult arbitrarily, govs could force browsers in regions to force prefers safe all the time which would be more ruinous
<jarhar> keithamus: govs can force the hand of anyone, so it doesnt matter which way you swing it
<jarhar> keithamus: maybe makes this whole thing untenable
<jarhar> anne: i think that was the point i wanted to make. i didnt understand arams point about - many websites identify as adult and then browsers
<jarhar> anne: if browsers are sending at age thing and then sites need to block access and would have the same end result
<jarhar> AramZS: its clear where pressure can be applied more easily by regulators. at the end of this year, texas state law which requires app stores to add an under 18 signal which will block them in particular states
<jarhar> AramZS: pressuring app stores is easy since there are 2 of them. if individual publishers dont understand this safe for under 18, then theres a much larger surface that regulators will have to deal with. publishers have dealt with this throughout history
<jarhar> AramZS: im not familiar with the rfc, but it very much depends on how its described. can a user agent be required to implement it or not?
<jarhar> AramZS: the rfc doesnt require it. if i believe that the california privacy law doesn't apply to my site then i can choose not to comply and then the gov can sue me
<jarhar> AramZS: right now in texas, folks are being banned from libraries because lgbtq is considered adult content
<jarhar> AramZS: if i am a library i can attempt to oppose it. if the state goes in and seizes all of the books thats a different problem
<jarhar> AramZS: the state would force user agents to become their agents and censor that data. with prefers safe, there is a signal that is a preference. even if user agents are required to emit it, individual entities can fight against that which is much harder for a state to fight against it
<jarhar> AramZS: the server should handle it
<jarhar> johannhof: its sufficiently good of a solution on the first slide. how do you compare that to digital credentials?
<jarhar> bvandersloot: it is a hope that it is good with tradeoffs. imo, it is unrealistic that this is not easily circumventable as is the digital credentials api if you use a vpn
<jarhar> johannhof: youre assuming that digital credentials is circumventable?
<jarhar> bvandersloot: yes
<jarhar> marcos: that is a fair assumption
Add declarative scroll commands to HTMLButtonElement
topic is whatwg/
sakhapov: the feature is to scroll with a <button> element
sakhapov: the explainer outlines why we went with this design
the explainer is at danielsakhapov/
sakhapov: there is a comment from anne about logical properties being relative to writing mode
<bkardell> danielsakhapov/
<bkardell> whoops
[presenting example on screen]
zcorpan: physical directions are up/down/left/right?
zcorpan: but inline-start isn't a direction but a side of a box. this is bikeshedding, but is there a good word for the logical direction?
sakhapov: we use these words in CSS scroll buttons
bkardell: the example looks like carousel. I'm worried about the accessibility of some of this.
bkardell: there were discussion in ARIA this week, has anyone looked at this from an a11y standpoint? the explainer says it's accessible, but not how and why
bkardell: I don't really know, but think that if you have a normal div and it overflows, you don't get buttons for the scroll region.
bkardell: how much has this been looked at?
masonf: this is part of the accessibility story. part of the criticism is for pseudo elements
masonf: I think it will improve the acessiliity story because you can add buttons and have full control
bkardell: the way that a scroll pane works on the web isn't the same as paging.
bkardell: yes, the same as if you focus a scrollbar and activate it with a keyboard
bkardell: would the accessibility tree also be a page at a time?
<anne> I think the main thing that's tricky is that the feature depends on CSS so it's a bit unclear what any of this means when CSS isn't applied. Slightly less unclear without the logical keywords, but still quite a bit.
<domfarolino> (answered my own question)
zcorpan: for keyboard users, when in a scrollable container is to just use the arrow keys. are buttons for scrolling a useful addition for keyboard users?
zcorpan: I think it's mostly useful for mouse or touch
zcorpan: is there some usability testing for keyboard users, whether the buttons are in the way or are helpful
keithamus: on the naming, it should be some word to advance or retract along some axis.
scroll-page-towards-inline-start
<masonf> scroll-me-down-a-bit-more-please
AramZS: I think it wouldn't only be used for [???]
AramZS: If you're keyboard only, switching between one direction and the other? don't have an answer
bkardell: paging depends on CSS inert which I don't believe we should take as read
keithamus: in a carousel, the cards that aren't in view are inert. you can click them but not focus them
masonf: I think that's an orthogonal concern?
keithamus: kind of, but it probably obviates the need for buttons. if you have a long list you probably want something like roaming tabs
masonf: I talked to Sara yesterday and keyboard users probably don't want buttons, but for voice control users it could be.
keithamus: my conclusion from this is I'm not sure and I think this would need to go in front of the ARIA WG
keithamus: I'd suggest an action item to schedule time with them, but the design seems relatively inoccuous
<br>
w3c/
foolip were the names to use resolved there?
fetch retry
mych: *presents slide deck*
pmeenan1: question on the options. if the retry after unload is actually necessary? is there a case where you want to keep a live fetch but not retry until the document is gone
mych: retry after option?
pmeenan1: yes
mych: i think it was also brought in the discussion thread. maybe it is not necessary, but we are adding here for the origin trial
mych: it makes sense that people just want to keep alive request once and dont want to retry
zcorpan: similar question for keepalive. maybe no other opt in is needed?
zcorpan: for general fetch if you opt into retry how much configurability is needed? is it enough to say please retry and the user agent decided
mych: for this api the configuration is the same
mych: providing this retry option will enable the normal fetch to retry
zcorpan: the proposal has retry attempt and timing. is it a good idea to let the developer specify all of that? or is it better to leave it as a simple opt in to retry or not and have the user agent decide?
keithamus: i think theres a variability in endpoints so you might want to tune the backoff so youre not fetching expensive resources. an individual website might have different retry configs for different endpoints
keithamus: often with exponential backoff, it is ? ui to the user to say we will retry in 10 seconds, but do you want to click this button to retry now? how does this allow for that?
mych: we want to retry immediately?
keithamus: yes
mych: in that case this design doesn't support it. you can only abort a request and retry
keithamus: thats unfortunate. id be interested in a design like that. this becomes a thing where you can implement it to a certain level of complexity
fergal: you can still build that by doing regular fetches and then if you get to the end of the pages lifetime ?? i think doing what youre talking about and building it into this api might make it quite complicated
bas: given this is for flaky networks there are situations where the os has realized or the browser knows that the connection has gone bad. should there be a capability for it to automatically retry when the browser realizes that the network connection has been restored? if the delay is 30 seconds, and you know that you have network again, might as
well do it right away right?
mych: idk if this already done in the network layer
mych: i dont think this api considers that
fergal: i think its a reasonable suggestion
ErikAnderson: i dont recall if your explainer cals this out, but enabling a more pervasive cross network device tracking is a bit of a risk which we solve with some of the background sync
ErikAnderson: do you have any implementor guidance which says that the network switches, perhaps abandon the retry unless the page is still open?
mych: we do consider that. currently the proposal is the retry is in the same active document with the same partition key
anne: so you adhere to whatever time is for the service worker?
rakina: it can go beyond the lifetime but we will only retry if there is another document with the same key
rakina: if you save the same information in local storage ???
fergal: this sticks to the same rule
anne: and that justifies the separate opt in?
fergal: thats the meaning of the keep trying after unload is to turn that off
toyoshim: i guess we cant do the same thing in javascript api. how did this information leak concern happen?
mych: we have criteria about what ? the browser is going to retry
anne: a fetch call might fail because of cors or csp or tls or dns
anne: thus far, what we expose to js is only did it fail as a single bit
anne: if we dont want to expand on that bit, then we need something like that. we dont want to retry because of cors
anne: if we take those requirements into account then you end up with something like this
fergal: its unclear how you would tell the caller that it failed but keep doing the fetch
toyoshim: cors is intended to protect the server, so its ok to have this flag
mych: we hope that its ok. the proposal here is that we want additional headers that can be used in cors request
toyoshim: user cannot set the arbitrary header
mych: this will be set by browser if the retry is attempted
ekinnear: weve had a lot of people asking for this from native apis that do http, so we are looking at doing something similar. dont want people to rebuild this
ekinnear: the timing thing - im worried that the moment i expose timing information, the fact that i dont tel lyou that a retry is obvious because it was exactly 2 multiples of ?? handshake took, so then you know you did it twice
ekinnear: is there some amount of fuzzing in the numbers needed? or is just telling you we did a retry bypassible?
ekinnear: dont you have a discrepancy between the timings if you made your own timer?
anne: between a fetch without retry and the fetch itself? there would be differences
ekinnear: like a suspicious amount
fergal: cant you already measure that?
ekinnear: is that a leakage of information that matters
fergal: longest possible amount of time to reject the promise. even if you give up after the first one because of cors
ekinnear: for the positive case nobody wants to hang out that long
fergal: you could just do fetches yourself
ErikAnderson: i need to wait 5 minutes or 10 minutes to find out that the thing failed, but youre delegating so deal with it
ErikAnderson: any thinking baout how this related with network error logging or reporting api? sites can cross reference with what their server logging sees
ErikAnderson: how can i discover my server failed 20 times in a row and it was out for that long
mych: can be considered but yeah
rakina: retry attempts will help for this. one of the reasons for this is partner was trying to ab test and see if retries show up on their server
anne: for retry attempts, is the idea to restrict it to not allow no cors requests to be retried now? mark nottinham brought up that it is doing work in this area on protocol stuff and we should be alinged with that work?
anne: have you looked into that?
anne: if we really want to do a header then we should resolve those things
rakina: fine with not doing this for no cors
anne: maybe discuss with colleagues
fergal: where was marks comment?
anne: its in the primary issue for it
anne: on naming, i think if we did it without preflight ?? would be needed, thats generally waht we do to not surprise servers with new headers
zcorpan: thinking about what keith was saying with retry now, you can do that today but not ccombine it with this new api
zcorpan: can you cancel the current fetch retry?
zcorpan: or add a retry now method?
rakina: theres no way to do that, might conflict with not exposing ? attempts at all
zcorpan: i get that for keepalive you cant do anything. this exists for regular fetch right?
zcorpan: isnt there something where you can call a method?
keithamus: if you had a method on the request object
keithamus: its not uncommon to create the request object yourself
keithamus: its a bit weird
zcorpan: yeah either abort or retry now
ErikAnderson: similar to the thing about detects a good network is up, maybe the os does or doesnt do that but we give guidance to app developers to make a request to find out if its working - app might find out before the os does that the network is up
zcorpan: online and offline events
fergal: does it make sense to do this reetry now through a signal?
cors readability
Slideset: https://
<rakina> @anne: ok will do, thanks! (not sure how to reply on irc)
<nidhi> To Anne's comment about the IETF, there's an active draft about idempotency keys(https://
patrick: Want to talk about security and CORS readability for compression dictionaries. Compression dictionaries let you use a prior resource as a dictionary for a new resource. Either same URL or different URL.
patrick: ... CRIME and BREACH are two side channel attacks that are timing specific. Killed prior SDCH. Danced around it by only making it work when the responses are CORS readable. But now running into non-CORS scenarios. Embed scenarios with scripts sprinkled all over the web.
patrick: ... two options, credentialed. Have to update the web-- anywhere the script is included. Chicken and egg problem. Script owners don't want to add dictionary support if no one is using it. Site owners don't want to do it if no scripts are doing it.
patrick: ...can't cache single response on CDN edge. Site-specific Access-Control....
anne: why does it need a preflight? credentials don't need it.
patrick: ...okay, I'll scratch that out. Just can't cache then.
patrick: ... for anonymous update-the-web problem, probably only a Chrome issue. Want to separately talk about fixing is the uncredentialed connection problem. Those end up on a different connection which creates scheduling H2 and H3 problems.
<anne> q/
patrick: Originally when we came here we were planning to ask for an opt-in way to request CORS readablity. Compat concerns about making 3p resources readable to pages, showing up in stacks, increasing surface area of CORS-readable content. Someone pointed out this is essentially CORP. CORP handles spectre attack for out of order speculative
execution. Origins can opt into protection by adding CORP header that blocks cross-origin readability for sensitive cross-site responses.
patrick: ... current proposal is just use CORP. It already handles side-channel attacks for readability of content.
patrick: ...alternative would be to default-safe and don't allow compression dicts to be used unless they add a CORP policy. Either would be great for our use case and wouldn't open up general readability of the response. All we care about is closing the side channel.
anne: Can you tell more about the nature of the side-channel attack? How easy to pull off?
patrick: Very theoretical and not very easy to pull off. If you control the dictionary which really isn't the case, but if it does, and you can force origin to compress with arbitrary dictionaries, can populate dictionary with things it wants to see in the response and it can tell based on the compression rate if those things were in the response.
In both cases it largely depends on the attacker being able to control the payload of the response to deduce what's in the payload of the response.
noam: To clarify... cross-origin isolation protects against Spectre. CORP just allows a particular resource.
anne: I think as far as my preference goes, I prefer default-closed. Because generally we don't want to give access to no-cors responses and we are trying to standardize opaque response blocking. Which is like a new form of CORB. And so the last bullet point about default closed is where I end up. Even though CORB is originally designed for
something else but it's pretty applicable here.
patrick: My only concern here is, and I don't know use cases for it, is to make sure there are no unintended side effects of including a CORB response on headers where it hasn't been the case currently.
anne: Then they might also be able to get Spectre attacks.
patrick: If they put this in the response they assume it will be a target of one of these attacks.
anne: Which is why it seems not good, but okay.
noam: Would also be available in a cross-origin isolated document.
noam: ...it would never error.
patrick: In that case, just don't add the header. If you don't want it to be cross-site it becomes not available and not readable.
patrick: ...you literally wouldn't add this header unless you want the behavior that comes with it anyway.
anne: There's a slight risk of cargo culting this and people not realizing the implications. But I think it's reasonably clear and people looking at documentation for the header see some hint of attacks being possible. Should double check and add that if it's not there.
<zcorpan> crossdomain.xml
Conclusion: create a PR.
patrick: I have a PR in flight, I'll bring this in.
patrick: Long tail was RFC getting published, with happened a few weeks ago.
fetch retry redux
rakina: we resolved to retry ? header, ok for cors and preflight
anne: modulo having a discussion with ietf folks first right?
rakina: an opt in on top of the opt in to make sure that you really want to retry posts and stuff
rakina: i dont know if people have opinions with that
anne: ? changes over time. i dont think we anywhere in the platform - the network stack has an idea of item ? but the browser doesnt
anne: everything that fetch can do is essentially the same for all methods
ErikAnderson: maybe retry if request headershavent gone out? narrow if useful enough?
ekinnear: if you make a connectio and it dies before it sends anything we will make another one
fergal: thats the second option here
ekinnear: we can rename it non idempotent or safe
ekinnear: theyre two different things in spec
ekinnear: right now we automatically retry things that are safe in some cases. otherwise people have them stop being safe to retry. not unreasonable to retry things that are replay safe by default
ekinnear: we can bikeshed whether its useful to ? ipotent
ErikAnderson: is ? exactly the same? the server is reached and does a tls negotation and that fails, is it useful to retry?
rakina: use case for this is some partners have intermediate servers that they dont control, so they only want to retry if we cant reach there before
fergal: if weve established a connection but havent set headers
ErikAnderson: the best example is if im temporarily on a captive portal. ive reached a server but i probably want to retry later
anne: even sending the headers is fine, you can resent the headers?
ErikAnderson: dont know how far the server got in processing it. we have office teams that are like why did this retry?
ekinnear: we should retry by default if it is safe. you have the option to say for anything that is not a safe method or say please dont, then as soon as you send any bytes then dont retry
ekinnear: then were still debating to say whether i know im doing somtehting like a post but i want tyou to retyr anyway because i know that this is dns over http, post of dns query is replay fine so dont bother me and do it twice
anne: we would retry outside of we want retry context?
ekinnear: like we do today?
ekinnear: yes
ekinnear: the ability to control the backoff , theres a lot of useful value add
ekinnear: reasonable to say that the default is not the best
ekinnear: safe things are in fact safe to retry
ekinnear: they are currently retried in 2 or 3 browsers
anne: posts are 2 to be fair
ekinnear: that one i dont feel as good about
anne: is that also true for subresource requests? i know this happens for form submissions and navigation, but not for fetch or xhr
ekinnear: i dont know which one is which
fergal: youre talking about no retry behavior. youre opting into retry, so dont be surprised if its retried
ekinnear: *describes pressing buttons and retrying 5 times*
ricea: its only available if you opt into it with a header. cross origin there isnt an information leak
ekinnear: i dont remember either way
ricea: in other words, you cant determine whether a retry happened by using clock time
ricea: if the server gave you resource timing, they can tell you how many times they saw an attempt or precise timing so i dont think thats an issue
ricea: i dont think we need to wait for max time
anne: resource timing was not the concern. this was discussed a long time ago
fergal: you can just measure the time yourself?
ekinnear: was the question about csp? so the server never saw it. that was the one i was confused
ekinnear: if you end up with a failure and you never got to the server, you can see that it was instant or not
ricea: so you need to wait max time to tell no
anne: things can be changed, but as long as we hold the line on making errors less granular
ekinnear: 50% of requests would be less than maximum, not sure we care
anne: some security researcher will find a way to determine your randomness
toyoshim: can you clarifhy the behavior on the redirect things?
rakina: we only retry from the beginning. what if we allow an option to retry from the last redirect hop?
rakina: retry from requesting to c instead of requesting from the beginning again
rakina: details to be worked out on headers
rakina: but yeah this will reduce the load on servers in the middle and it will allow more cases to be covered
rakina: because we can not send multiple requests to previous servers
rakina: any concerns about doing this?
anne: what details were concerning?
rakina: maybe if any of the redirects are cross origin
anne: i think if its an exact replay because redirects are not observable
ekinnear: we have discovered that there are a lot of ? for redirects. in podcasts, its normal to have max number of redirects, they get mad if you stop following their redirects
ekinnear: we should think about in considering was this a retry header from the itf side of things. as long as they still get to count you as having listened then its fine, adn we cache the end of the redirect chain
ekinnear: i would love this behavior but we need tob e careful that theres this kind of retry doesnt create a way for people to unintentionally pay 5 times because we retried 5 times
anne: if we retry someone ends up paying more?
ErikAnderson: if they want to engineer it then they want to specify the origin
ErikAnderson: i suppose that would solve their use case
ekinnear: i would consider the idempotency spec as a better way to do that. help people disambiguate
anne: how does idempotency help?
ekinnear: if i wanted to retyr a post can i put a unique key in it to disambiguate
ekinnear: yes, jumping straight to c instead of a again is good
ekinnear: we do need to be careful. its not just are we reducing load, but were impacting revenue stream
rakina: bikeshed thing is whether we should ? prs or not
ErikAnderson: this one is interesting because i know some things have services where they build their own protocol for backoff
ErikAnderson: if i was managing my own retries with backoff logic then theres something to come up with a server to say i own the client but the server is dying so please stop
ekinnear: theres also the retry after header. do we respect that or not? the server can say come back in 5 minuts
ekinnear: we still dont support that because of time constraints than we dont like it
anne: because its ties to cors its ok because we can read the response
anne: the more features we put on this the longer it will take, so consider if this is neded in v1 or if we can add it half a year later
Introspection
Anne: "What things people would like to see improved, who is interested in helping improve things, and what keeps people from improving things."
https://
anne: sometimes presentations went on a bit too long - too much exposition. We should try to limit presentations to 5m max maybe? Room can solicit additional bits (e.g. if the use cases aren't clear, etc.)
… we want to keep the meeting group-driven not single-person-driven.
… might benefit from the timer
jarhar: automatic scribing would be nice.
… [or even hired scribing]
zcorpan: can we use autotranscribe with attribution?
cwilso: not really
ekinnear: with really good queue management, you can?
???: TC39 pays a transcriber (person not a bot)
leo: +1 to audio issues: remote audio was not great.
<zcorpan> one mic per person
mason: I liked the pacing.
… also, there are other conflicting meetings. Sometimes it worked well, sometimes it didn't.
westbrook: +1 on nice agenda; agenda was not cross-posted to W3C.
fergal: the individual items on the long items were not available on the calendar.
… having each item as a separate event would have been good.
jarhar: bumping up, there are some really old PRs sitting on HTML that will need to be rewritten or lost.
cwilso: do we need to review the "cruft"?
zcorpan: we could, or if we can do the bikeshed conversion on PRs?
dom: somewhat related to Simon's burndown idea, we are at like 2k open issues. What should we do as a community or editor community to bring that down?
zcorpan: one thing we could try is focus on a particular topic, and when that topic is burned down switched to a different one
… "themed triage"
dom: maybe use a part of WHATNOT meetings for that
Anne: need a couple of people drinking the firehose to add labels, etc.
… lots of occasionally raDICAL feature requests
cwilso: explicit call to the triage team?
mason: do we have a how-to doc for if you want to help with triage?
anne: I dont' think so
zcorpan: we do have label descriptions but we should do more.
cwilso: might also do RIP - rapid issue processing
noam: the 2k issues, does that include all incubations?
dom: not sure, but I believe it's a growing list of actual bugs too.
noam: can we be more generous with labels? Incubation vs backlog, for example.
anne: we do have "needs concrete proposal"
dom: no problem with increasing list of "NCP" - more about bug amassing that I'm concerned about.
anne: feature might land, followed by 5 bugs on the feature, and then those don't get fixed for a long time
zcorpan: we should be better at using "needs" labels, that would help "what needs to happen next" and make progress.
Dom+Anne: yes
mason: 5-10 minutes for triage at every WHATNOPT meeting
keith: ARIA WG does this
noam: in general, relation with incubation could be more transparent.
… we're missing a lot of incubation opportunities.
… seems like incubations sometimes go too little before bringing to us
dom: can you restate the problem?
noam: feels like the concepts that come here could have been cooked more in incubation.
noam: this isn't the right forum for ideation.
cwilso: ideation no but maybe we need to get attention
noam: not the FYI, but the 3rd/4th/5th time something comes to us
keith: maybe proposals need a certain amount of socialization first
noam: CSS does breakouts first, maybe somethjing like that
keith: yeah, in ARIA we do deep dives, similar concept
mason: openui is one of those places, but in practice we need to come here.
dom: should we have separate breakout sessions? Like OpenUI
dom: should we have separate breakout sessions? Like OpenUI