Upcoming WHATNOT meeting on 2024-08-29

[past]

What is the issue with the HTML Standard?

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

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

[past]

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

Agenda

Attendees: Luke Warlow, Joey Arhar, Panos Astithas, David Baron, Emilio Cobos Álvarez, Brecht De Ruyte, Dominic Farolino, Mason Freed, Chris Harrelson, Sanket Joshi, Brian Kardell, Vladimir Levin, Alex Petros, Ajay Rahatekar, Noam Rosenthal, Kagami Rosylight, Anne van Kesteren
Scribe: Joey Arhar

1. Review past action items
   1. Chris will find someone from Chromium to take a look at allow notifications and actions to specify a navigable URL.
      1. Chris: reached out to multiple people at Chrome, waiting for their response on the thread. Will ping the thread with them to remind them.
   2. Olli will ping Emilio on add popover=hint.
      1. Emilio still thinks the proposal is fine and will try to find time for a deeper review.
2. Carryovers from last time
   1. Anne, Olli to review <select> proposal for stage 2
      1. Anne is OK with moving this to stage-2. Consensus around the stage transitions is that we should wait 2 weeks (3 consecutive WHATNOT meetings) for feedback before moving forward.
   2. [Alex] HTML forms do not support the PUT, PATCH and DELETE methods
      1. Consensus that this is an interesting path to explore, but there is still ambiguity around private network access and preflight, and solving those issues first will likely be the right next step.
3. New topics
   1. [Dom] Atomic move operation for element reparenting & reordering
      1. Anne thinks this is probably OK for stage 2, will check by next week. Emilio thinks it's OK, but will check with Olli first.
   2. [Chris/Vlad] Proposal: Element 'sensitive' attribute
      1. Discussed the tradeoffs between various use cases, like translation, speech to text, etc.
   3. [Dom]: Anne, should we wait for Olli on Use DOM's post-connection steps for <script> elements #10188?
      1. Carry over.

Action Items

1. @chrishtr will ping the thread on allow notifications and actions to specify a navigable URL.

Minutes

allow notifications and actions to specify a navigable url:
panos: Chris, did you find someone to look at this? I haven't seen any comment on the issue, so I'll leave this for the next meeting.

add popover=hint:
panos: this was a request to chime in on popover=hint
emilio: i commented on the open thread about nesting of popovers. i got convinced this is fine. if you need me to ?? Then I can do it. it wasn't clear if ?? or stack of open
mason: the one comment was resolved. If you have others, that is great. Otherwise, I'd like an official position. it sounds like you're supportive but its not marked that way
emilio: sounds fine to me, i'll check with olli and simon.
mason: thanks, and other comments on the spec pr would be useful.
emilio: i'll take some time to review next week

select proposal for stage 2:
panos: we have the question about how mozilla and apple feel about stage 2, and then there's a question about the process. Let's talk about stage 2. Any objections to moving to stage 2? last week olli it seemed fine from mozilla. Anne, any objection for stage 2?
anne: seems fine. still a lot of details, but they can be done as part of the issue.
panos: anyone else from mozilla want to chime in? If not, let's talk briefly about the other aspect. Anne, you and I were debating what it takes - how firm to be about when to stage 2. My interpretation from the last meeting is that the wording in the document says that … There's no objection and at least two engines support moving to the next stage. this is where it was a little bit unclear, could we have moved on without waiting for the third, in this case webkit? or should we always wait to have firm consensus from everyone. If so, does the document need any updates?
anne: we don't need to wait, but if everyone said they would review it and give a stance, then we should wait. We could also set a deadline, which is also what we want to do for PRs sometimes. if you don't then we're going to go ahead in two weeks. If someone says that they want to review it, then we would try to allow time for that to happen. In this case I did express that I wanted to look at it so it would be surprising for it to move ahead.
panos: I was having a similar interpretation to you. We discussed two meetings ago. In the first one you said it seemed probably ok, and I took that as no strong objection, so I thought two weeks would be sufficient, which is why we delayed to this one. Let's say you weren't attending today. What should we have done in this case?
anne: in the event that i hadn't said anything yet?
panos: having said what you said in the first meeting, that its probably ok but you haven't looked in detail
anne: i guess i would maybe expect some more leeway or someone setting a deadline first, minute that, and have a final chance to say something. Maybe I read it wrong. The other thing was the timeslot last week so I wasn't able to make it.
panos: this is a scenario that might be the only corner case.
anne: two weeks would be fine if i didn't say that i wanted to review it
panos: do you feel that transitions between stage 1 and 2 are lower complexity than 2 to 3 and 3 to 4? or should we do everything in the exact same manner?
anne: similar is fine, unless we notice that it doesn't work well. we can always go back if there's a big problem that nobody noticed.
panos: the reason i pulled that out is that the commitment that webkit expresses is higher the further we go along the stages. from 3 to 4 it's in the PR, and it's more work to go back.
anne: We should still try to keep it somewhat informal because in most cases it's a much shorter time frame. for a lot of PRs they go from stage 0 to 4 in days.
panos: the way you have drafted the document gives us a ton of leeway to change our mind, move back and forth. Any other thoughts on this topic?

html forms do not support methods:
alex petros: I know this issue has a long history. the basic thing we want to do is get the 3 additional http methods. from an api standpoint there's not fluff in the proposal. We did our best to specify how that would work with the back button, refresh button. put together a couple use cases for why this is pressing in the ecosystem, now is a good time to address it, there's been progress in other parts of the spec that make this more doable. How should I proceed? What can we do to move this forward?
anne: i have some loose thoughts and question, but i'm not sure if now is the right time or not
alex: I'm willing to put together a prototype of this in some of the implementations. the main thing i'd like to get out of this meeting is are there any unresolved questions before we put in that work
anne: one is that private/local network access is not really ready yet. it hasn't been integrated in html and hasn't been implemented by a second browser, so how feasible all that is… also all the changes to fetch haven't been made. this feature would also require html and fetch to sort of work out how preflights work
alex: What changes do you think would happen to fetch? ideally this would use the existing stuff
anne: you need to do a preflight, and fetch doesn't do preflights for navigation. It does do them for local network but that's different. fetch will have to be instrumented and carry out that thing. That will be easier once the private network access is implemented, but that hasn't happened yet. as far as the method goes, sure that can just go through. i did see in the discussion that you wanted different semantics on the ui side of browsers, for post when you refresh we say do you want to do this again
alex: I'm not attached to any implementation of that, it's just a question that has to get addressed. in some way that has to get resolved, i don't think those are the focus that's the benefit for users, but browsers have to build around that. My proposal is that this is one of the ambiguities. The way we handled in this proposal is that you could take advantage of put and delete, but if you want to say that's legacy behavior for post then you could not do that.
anne: should we support arbitrary methods? xhr was limited in the early days, then we decided to support everything except a few corner cases of get and post. there might be similar issues, like you can't use the dialog method for the dialog element. there might be some stuff to sort out there too.
alex: somebody commented on the issue. i'm supportive of custom extensions of the standardized methods, but it's a more complex api surface, and just having these 3 methods that are already standardized would have a lot of benefit for basic rest applications, and it has to happen on the way for custom methods. if we just make these happen, then it will make custom methods easier.
anne: Yeah maybe. It depends on how much custom work is needed. At least for xhr, all the other methods behave in the same way, so that's ideal. we need somewhat of a good reason to limit it. i would have at least have us wanted to think what it means to support all of them and reject that for a technical reason
alex: adding support for 3 methods doesn't close the door for arbitrary methods. it doesn't take away from our ability to do that.
anne: in case insensitive matching, is that a problem to tackle now or later? for these methods they would be case insensitive like they are for xhr.
noam: i don't think we should flesh out all this in the call. any special handling of 201 and 202 for post and delete. Does that do anything? Is that somehow reflected in html? things to think about.
luke: regarding the custom method stuff, if you try to do that as a followup then what you do in the meantime with methods that aren't recognized which could lead to compat problems. if you have method foo it will now have one behavior and in the future have another one.
alex: don't we already have that problem?
luke: if we do the override method as a new attribute
alex: yeah. if we do an additional method attribute for backwards compat, then yeah the custom methods should be done for that
emilio: same thing. We need to figure out if we have data on how often we find invalid methods right now? I was curious if we have the data.
alex: i don't have that data, just the valid methods
emilio: so you have data on how often people do method=delete? presumably it's not a huge counter? is this something that would make us need that override method
alex: That's something that I was hoping to get feedback from yall on. there's a world where we say that the 3 new methods are supported, or have an upgrade path. if we have an override method, then we need to consider a future where we support custom methods.
emilio: we could do something like a list where we expose it when a method is supported, but yeah. that seems like - if we have data on how many sites will break by just supporting one method, then that may be worth tracing early to figure out what the api should eventually be. ideally method just works.
alex: The way I envision an override or custom method is one in which you also backwards compat - you do rollout support for new methods to the method attribute.
panos: luke is asking if this is available in chromestatus?
alex: no, we did github searches. If there's a way you would like us to collect data we can do that. we used htmx, how often do you use put/patch/delete as opposed to post.
anne: it's worth looking at httparchive to see what values the attribute currently has.
luke: if you could, chrome counter would be useful. how many instances of a form with a certain method don't have preventdefault? if you preventdefault in the submit then the semantics are irrelevant. the value itself gives you an upper bound, but the real value is low, could be useful to look into.
panos: i hear consensus that this is a useful direction to pursue and there are no objections?
anne: worth exploring, but worry that its early considering that private network access is not in a good shape.
alex: anne, i expect to run into that, but are there any things with private network access that would block the spec or api?
anne: yeah its a large part of what makes this feature, the preflight thing, that's an essential part of this feature. that has to be standardized in fetch and html has to call is. you could try to bypass private network access, but then people don't think it's worth the lift, and not important enough to have this complexity. with private network access people don't think it's worth the complexity for that either. rolling out would require everyone to update their network access.
chris: upstreaming the preflight method from private network access to fetch is the next actionable step to advance what Alex is hoping for? Is that right?
anne: that is a next step, but what i'm trying to say is that there is still quite a bit of uncertainty around private network access and how it should work, and that needs to get better
chris: Where is that uncertainty expressed?
anne: the issues, the approach keeps changing, people think it should be a permission instead of ? based.
chris: are these issues on private network access - in wicg right?
anne: it's in some repo. yeah its wicg: https://wicg.github.io/private-network-access/
alex: doing this in conjunction with private network access is an attempt to find the path of least resistance. Recent trends have shown an increased importance for this feature. if this runs up against the fact that private network access is stalled, we can at least say that this is what the api shape would be, we can at least implement it against that. I hear you on making sure that includes a robust thing for how navigation preflight would work.
anne: its reasonable to try to prototype that all out. I just worry that we put a lot of effort into this and then people dont think its worth the lift.
alex: i know this is going to take a while, and that's ok
panos: any other thoughts?

atomic move operations:
dom: we would like to get a feel for how people feel about moving this to stage 2. We have a spec PR up with webidl, and some todos in the processing model. I feel that we have consensus that this is going in the right direction. it seems like an appropriate time to inquire about stage 2. Some spec work needs to be done with initial feedback that Anne gave. I think we all feel fairly settled on the direction we're going in. I wonder how people feel about stage 2. also if there's any movement we could have on the webkit standards position.
noam: we have a prototype of what's currently in the PR. we were asked to find implementation complexity, and we fleshed it out and didn't see huge things in chromium.
dom: how do people feel? anne in particular
anne: i'm not convinced that the current mutation record is correct
dom: i agree, that could use some more work
chris: That's the kind of detail work we can do in stage 2-3?
anne: we do have rough consensus on the api shape, and for webkit standards position i should get back to that. i think we can … give me a week or so on that and i can sort those things. I think it's ok for stage 2. I did see ryosuke had some concern.
dom: i think it was good questions about the specifics, seemed more inquisitive than scared or critical
anne: I don't have enough experience with the animations side to judge the complexity there. Tim at least thought it was manageable.
dom: implementation wise it was not difficult compared to other things we are preserving. the general point is regardless of what direction we go, it seems reasonably scoped. so chromium and webkit, is that enough for stage 2?
panos: as we were discussing earlier, we will take at least a couple weeks for everyone to chime in.
dom: that was for standards position
anne: we are ok for stage 2
emilio: seems fine to me but olli would have the last word. interactions with pseudo elements are tricky, but same with - that can be figured out before stage 3. in general, no objection but if - i should ask olli to see if he has any concern otherwise.
dom: this brings us back to the question about going to stages. Are we not in a position to move the stage bit today?
panos: we will wait for olli's take, and assume no objection happens by next week, unless olli is gone, we will flip the bit then. two weeks at the latest.

element sensitive attribute
vlad: browsers are starting to add tools to utilize ai LLMs to help users with various tasks, like help me write or autofill that can use these LLMs to populate input fields. in order to get access at models, you typically send information to some server that runs the model and response is sent back. A lot of these are based on the page content, like what is this page or input field about require you to get the page content, what ends up happening is that page content via these tools is being sent to the server. This causes a problem in certain cases. For example, e2e encrypted chats where the site does not want the information to leave the device. The proposal here is to let developers annotate their content as sensitive, which means that tools within the browser that would send it to the server would not send that information or the content of those elements. it would only be for browsers to respect that. things like dom snapshots and a11y tree would still send all information so that other legitimate cases don't break. This is not necessarily about AI, servers have larger compute than devices, so it could extend to other things, like screen sharing where we can censor information.
brian: wondering if things like text to speech services that google has cloud text to speech services. would it - that's an example of sending something to the server, but you might want it to still speak that, but its sensitive in a different way. i'm not sure what sensitive means here, and how you put it so that it always makes sense
vlad: good question, eventually proposing having various values for this attribute that can distinguish some cases. I don't know for this example for text to speech on the server, sometimes you want it sent and sometimes you don't, depending on the degree of sensitivity.
panos: this is a tool for the website designer to make that decision
vlad: if it's expressed such that the web dev can distinguish those cases, then this is a tool they can use. the question is how to make it expressive
emilio: I was going to bring up an example, like translations. it seems like it might be more of a user decision than a webapp decision whether the data should be sent. Imagine somebody sends me a text in arabic. if i don't expect it to be sensitive then i might want it to be cloud translated. This has some really limited utility, but I wanted to bring that example up. this attribute wouldn't really cover. most ai stuff should have the same issue, decision shouldn't be made by web author.
sanket: couple points. What has already been stated? There is some processing that happens, some client and server but necessary to consume the site in a meaningful way for translation. marking it as sensitive - do we want to prevent users from translating. What's the scope? are we really just targeting these - maybe the intent is like this data shouldn't be used or stored in an additional way. What's the use case we're trying to target?
vlad: the concerns i've heard so far is that this would be too restrictive. it would be concerning that e2e chats shouldn't be uploaded. The problem here is - without this attribute, it's too permissive, and there's no way to isolate cases and say this should never leave the device. the solution to say no nothing and everything can leave does not seem appropriate to me. storage vs access, whether we can do that can all be done with values of the attribute. I'd like there to be something that can isolate information and force information to stay on the device.
sanket: part of the challenge, for the same feature browsers might choose to do client side or browser side, and we could have interop issues or things wouldn't work
vlad: this would force translation to happen on device
sanket: you mentioned this chat scenario. Are we targeting enterprise type things?
vlad: as a user i don't want my whatsapp chat to be sent to a server, but there are enterprise use cases for sure. a lot of these ai features are gated by enterprise policy. That again is a big hammer that prevents valid use cases that are not sensitive from being used. This is a more granular approach to partition the site into this is allowed and this is not.
sanket: for the enterprise one, i agree enterprise policies are the way they do this. for whatsapp, as a user you don't want your data to be sent, isn't that a user choice instead of a dev choice? you can go into your settings and turn off ai features. some features you can filter by site. you can make that choice as a user, but some other user might say they are ok with chat being sent
vlad: two thoughts. that requires a lot of user knowledge of what's happening, it's not obvious that if im translating a whatsapp chat that im leaking information. The permission model can work, but are these two orthogonal? if a site annotates it as sensitive, the browser could ask the user. In those cases, if we want to say that it's a hint and the user gives a permission to proceed anyway, then they can. seems like it would enhance user choice instead of limit it.
luke: some concerns have been raised about user choice in whatsapp. As a user I want my search results not to be sent to the cloud. I'm still going to rely on them to mark it as sensitive which isn't useful for me as a user. it's not clear that this attribute will have a lot of ? if whatsapp wants to mark their page as sensitive, it's not going to stop extensions from having that data, maybe with a permission. requires users to have understanding, so they've already got to make that decision somewhat, then user not understanding the privacy aspect because they already kind of have to. there's nothing to stop an extension, autocomplete of gets ignored or track? gets ignored. attribute does not help if its contract cannot be fulfilled. it feels like we would need a lot more to say here's some data, the browsers should render it but dom apis cant access it. if we don't want the data to be sent to the server, we could also want to not want anything local to process it either, and not clear whether this attribute would cause that to happen or imply that.
vlad: this proposal is for users who do want to use ai features, but not on everything they view in their browser and developer annotates it. distinguishing between extensions in the browser is worthwhile, i don't know if that's something where we want to blur the line. maybe? just wanted to raise that
anne: how as an end user would i know that the developer used this correctly?
vlad: they marked too many things as sensitive?
anne: unless you really know that the website used this feature and you know it existed. I'm not sure how this works from an end user's perspective. i have to trust that the website did it correctly, or trust the ai model. I don't see how an end user can make a decision whether or not to … they have to decide that independently of this attribute because they can't know if the attribute is used.
panos: we are at time and i see that this conversation could continue
chris: i think we should continue it next time