Upcoming WHATNOT meeting on 5/23/2024

[past]

What is the issue with the HTML Standard?

Today we held our now weekly triage call (#10340) and I will post the meeting notes there in a bit. The next one is scheduled for May 23, 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 me 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]

Hey @whatwg/triage, I don't see any agenda+ items. If there are no tagged issues or PRs by the end of day I will cancel this instance.

[mfreed7]

I would love to get agreement on #9625 (comment), so I’m tempted to Agenda+ it. But I’m also not sure it would be helpful to discuss before the second developer poll happens.

[annevk]

I think it makes sense to talk it through (briefly).

[mfreed7]

Ok great, let’s do it.

[past]

@aphillips if you want to have the I18N-related discussion in this meeting, please add a comment with the proposed topics.

[cwilso]

Thank you all for attending the meeting today and special thanks to Robert Flack for copiously taking meeting notes! Here are the notes from this meeting (the next one is at #10365):

Agenda

Attendees: kagami, Robert Flack, Brian Kardell, Anne van Kesteren, Emilio Cobos Álvarez, Rakesh Goulikar, Chris Wilson, Chris Harrelson, Luke Warlow, Olli Pettay, Simon Pieters, Mason Freed, Tantek Çelik, Sanket Joshi, David Baron, Dan Clark
Scribe: Robert Flack

1. Review past action items

   1. @emilio to work on pulling out the common points for iframe throttling into the issue about Consider improving interoperability of <iframe> throttling margins, and maybe a spec PR.

      1. Carry over

   2. @domenic to ping relevant Chrome people to give opinions on Consume user activation in show the picker #10344 and Remove UA style for h1-h6 in section (et. al.) and hgroup #7867

      1. opinions given, complete

   3. @zcorpan to find other issues with file pickers.

      1. Commented in the issue, complete

2. Carryovers from last time

   1. Rakesh will write a PR to have a more concrete conversation on The dropEffect column in the Drag and Drop events summary table should clarify it represents default values.

      1. Carry over

   2. Rakesh will compare the platforms-specific behavior and come up with a concrete proposal for Drag and drop spec allows multiple values for dropEffect which might cause browsers to behave differently and How should UAs handle web authors setting dropEffect values?

      1. Carry over

   3. [Addison] Joint session with the I18N WG. Addison will provide a list of topics.

      1. Carry over

3. New topics

   1. [Mason] Invoker Buttons - allowing popover/dialog and more to be invoked without JS

      1. Comparing command/invoke/click
      2. Action: Mason to collect options, others to weigh in to add options via emoji response, possible developer survey of options after. Focus on target name as primary common case. Sticking with two attributes. Keep in mind interest target. **Done: **[Proposal] Invoker Buttons - allowing popover/dialog and more to be invoked without JS #9625 (comment)

   2. [Mason] Add popover=hint #9778

      1. [emilio] Sorry, I still have to review this. At the very top of my list now
      2. Anne has raised concerns about the name of hint vs tooltip as an alternative proposal. No longer blocking, we should proceed with the name popover=hint.
      3. Action: Emilio to review all of popover-hint

   3. Feedback on Introduce DOM post-connection steps dom#1261 (Introduce DOM post-connection steps)?

      1. Olli was okay with it, but there was a related discussion in the PR.
      2. Action: Anne to review the PR for editorial content. Dom to file new issue and refer to this PR.

   4. Continue discussion about opt-in modes for select styling?

      1. Do we need special opt ins for select? Anything useful to discuss here post-TF meeting?
      2. Decided on CSS as opt-in mechanism, but didn't decide exact mechanism; should definitely involve CSS members.

Action Items

1. Mason to collect options on invokerbutton naming, others to weigh in to add options via emoji response, possible developer survey of options after. Focus on target name as primary common case. Sticking with two attributes. **Done: **[Proposal] Invoker Buttons - allowing popover/dialog and more to be invoked without JS #9625 (comment)
2. Action: Anne to review the PR for editorial content. Dom to file new issue and refer to this PR.
3. Action: Emilio to review all of popover-hint

Minutes

• Past action items.

• zcorpan's action item to find other issues with file pickers.

  • Can we have a link to security issue? Prefer not

• Invokers

  • mason: There is PR with editorial approval, one last bikeshedding question
  • mason: existing attribute names use invoke-* (action, target). Is this the right name? Is there a better name? E.g. click, demand, others? Want to gather feedback or decide.
  • ChrisW: I'm not sure I see coalescing around one proposal. Is there any overall leaning in one direction or another?
  • Luke: We want to lean away from click, command is a possibility. We've been leaning towards invokers but may be biased. Leaning away from click because it invokes input specific thoughts even though it's not, and click-action-target? is a bit long. We've had action as an alternative but not web compatible.
  • mason: +1 my bias is towards something agreeable. Invoke seems less confusing than click. We're focusing on the target attribute, the action is usually implicit (auto).
  • Simon: I like the command theme. Seems like a lot of knee-jerk reaction to click even though click is not device specific
  • Luke: We have two things in platform that are similar. Click is used for multiple input sources. Close is a new thing. There's history for both directions so it doesn't feel like a strong argument. Lots of people raise question about whether it works with a keyboard with click in the name.
  • Anne: both attributes have simple token values. One attribute is implied, can we combine them and split the value e.g. on space, first value is id and second is enum value. This reduces some of the verbosity concerns. We might have two IDL attributes to set this.
  • mason: This was discussed / brainstormed, we decided before to go the other way . Does this affect decision on the name of the attribute?
  • Anne: People don't like indirection of invoke, and prefer click as what actually triggers it. We could live with command. We're just wondering if we can make web dev exp better by not having to type as much. Order would be id first then optional action value.
  • Luke: How does this work for IDL attribute for something that's not ID referencible? I think it might work, just not be serializable. Simon mentioned idea of setting invoke-action=close you wouldn't have to give a target. If it's all in one attribute not sure how this would be done.
  • Anne: You'd need a token value for both of those cases probably
  • mason: This parallels the openui discussion. It sounds nice but there are issues e.g. element reflection. It either doesn't work or it's a special case where it reflects into multiple attributes. In the primary use case the action is auto so you usually don't have to use action attribute. For me, the extra character savings is less valuable than the complexities of having a single attribute. The biggest obstacle for me is click-target-action implies they need to have special keyboard handling.
  • ChrisW: I hear resistance to invoke, and anti-pref to click and click-action-target and general acceptance of command and command-target.
  • Anne: I don't like that the default api is the long attribute name.
  • ChrisW: command-target isn't that long
  • Anne: You'd expect to just have to use the short name unless you need to do something special. Here it's inverted.
  • mason: See your point, but typing is fast, trying to shorten adds confusion. Most sites aren't hand typed
  • Anne: Web devs do value brevity. It also adds clarity if the shorter name is the one you use by default.
  • Luke: Can we come up with another pairing? trigger was also floated rather than invoke.
  • Anne: Maybe just call it command and command-action?
  • Simon: Or command-type?
  • mason: It sounds like it'd be valuable to spend some time picking the right terms but could we decide on two attributes versus one? Then we can take it back to the issue to brainstorm terms.
  • Anne: I think this would be okay. I see some of the concerns. I think it would be possible to resolve. We can have custom IDL getters and setters including doing element reflection. It's more work but it is doable. You'd need some serialization for the id to reflect it's not referencible. TLDR; I'm willing to cede this, but still want a short name for target since this is the primary API.
  • ChrisH: So we'll have two attributes. How about we list all of the options and emoji vote?
  • mason: Might be worth doing a developer poll. More opinions is better, i'd love to have a vote somewhere. First we'd need to brainstorm list of names.
  • ChrisH: Maybe put a comment with all the options you know of, and we can edit the comment as new ones are suggested. Then we can come back to this and decide. Does this sound okay?
  • mason: I will start this on the issue, 9625
  • ChrisH: Let's loop Keith in
  • Simon: Can you have a demo for how to close a dialog without having to use id?
  • mason: I'll put the options of what does the invoker element look like with both attributes used.
  • ChrisH: Also make clear we're going with two attributes and deciding on the attribute.
  • mason: Feel free to add on to the comment. We just want to have a fair poll.
  • ChrisH: We can do an external poll for additional data points
  • Luke: Also worth keeping in mind the interest-target proposal, and what that would look like or how it would change w.r.t. this name.

• Feedback on Introduce DOM post-connection steps dom#1261 (Introduce DOM post-connection steps)?

  • ChrisH: Basically a question for Olli
  • Olli: It seems okay, there's a related discussion about what happens if you run it multiple times, which seems outside the scope of the PR. I think with new name it is okay. The comment from Dominic is still important since it seems like browsers aren't doing the same thing.
  • ChrisH: Does this have editorial review?
  • Anne: Think I need to do another take given the renaming. I'll look in next week.
  • Anne: Can someone update the PR with a link to the issue tracking the long comment from Dominic?

• Popover=hint

  • On top of emilio's review queue
  • ChrisH: Should we discuss the name?
  • Emilio: happy to discuss the name.
  • ChrisH: Anne raised concerns, tooltip was an alternative proposal. Was that the primary concern?
  • Anne: Wasn't prepared for this discussion
  • Luke: One of the issues was that they weren't stackable, but this was resolved. So basically it was just the name left.
  • mason: That's my recollection as well.
  • Luke: We discussed this alongside the interest to conclude this is diff than a tooltip.
  • Anne: Larger concern is that it feels somewhat adhoc, but I don't think we'll block on this.
  • ChrisH: Is hint a reasonable name?
  • Anne: I think it's been discussed enough
  • ChrisH: So popover=hint is fine, emilio will review, anything else?
  • Anne: We'll wait for emilio's feedback

• Continue discussion about opt-in modes for select styling?

  • ChrisH: I don't think we should discuss aspects outside the purview of WHATNOT, but there may be aspects which are. E.g. do we need special opt-ins for select? Would that be okay to unlock select?
  • mason: My take is we decided CSS is the opt-in mechanism, but not what property, pseudo, names etc. This discussion should definitely involve CSS.
  • Anne: I'm concerned about including as it is today. If the idea is that the select today is not stylable, then I'm not super comfortable with this. ChrisH: You want the existing select to be more stylable? Anne: Yes, feels like this should be part of the deal. The base appearance has to work for existing and new semantics. It wasn't entirely clear that this is what was being proposed. I viewed this as separate things. One is changing the parser to support richer DOM trees, second is changing the semantic model such that new elements in options (or siblings) have some meaning as well. This new meaning has to work for the normal appearance value (auto), so the native picker needs to do something for this, e.g. extract the text value, probably we could support images in our native picker and maybe some easy styling stuff like text styling. Then there's a separate thing for making it all stylable. This should work for everything that select element represents, both today and new elements. Luke: This tracks with what I'm thinking. You can have appearance: base-select and no parser changes. This would work, just not meet many developer expectations, but you could style stuff. Anne: I think this addresses a lot of what devs want. A lot of people use select but just want to style it and this would be great. Luke: Based on my experience, most people want rich content. Images you could maybe do with background, but most of the things need parser changes. If you have a select today with this base opt in you could change styling on it. The pushback I had was that you could do picker(select) and that would be enough, but this wouldn't let you change the button element. Anne: To be clear, never said this was all you'd need. Luke: But it wouldn't unblock shipping it in chrome, you'd still need appearance: base on the button itself. Anne: This would only be on select element and picker. Luke: If we have appearance: base you get compat problems. Anne: Right, that's why a diff value is nice Simon: I understood Elika suggested a different option for select. I want to hear if there's any reason not to have appearance: base and control-specific values, base-select, base-checkbox, etc. This addresses both concerns, we can do a staged rollout based on priorities and authors can feature-check each thing and use a single value to target all of the controls. mason: forward compat is still an issue, someone who opts in could have a broken change when a new control supports base. Simon: So we could add the base value later when we have enough controls implemented. mason: Right, you'd have to support this chunk of controls. I want to +1 what Luke said, the big demand is arbitrary content primarily inside the picker. There was a fairly good study in 2020 of non-named selects on the web. Most pickers were divs and spans because they contained things like two lines of text with diff fonts, or diff presentation in picker versus in the button. Button is a simpler control, but it meets needs because you can put arbitrary content in buttons. Compare this to select, where you only have text. Anne: I doubt this is true for long tail of sites. If it's about what you see, it's probably a couple sites that have resources to do all the fancy stuff. ChrisH: When you say styling of existing select, do you mean applying css to the picker of an auto select? Anne: I meant a select element without any new markup ChrisH: Meaning CSS? Anne: HTML. You have your normal with s and in css you apply appearance: base and maybe do a picker opt-in. This should be stylable without any additional HTML changes.
  • ChrisH: Without additional changes in HTML, things should be stylable in CSS, agreed. To clarify you weren't saying auto needs to be stylable.
  • Anne: When you have an auto select, there's some choices you make for native appearance, like do you render the images or just the replacement text. What do you submit, etc. For native appearance we can leave it to implementations, but we probably have to say what assistive techs will see, what's submitted, etc.
  • ChrisH: That makes sense.
  • mason: If that's the point, we agree. We should do as much with appearance: auto as we can. blink does a lot of customization today, fonts, spacing, padding, color, etc. There are limitations and there are security issues (e.g. blow it up to a large size to fool user). Adding images makes this trickier.
  • Anne: We might disagree there, not necessarily saying styling of native pickers is arbitrarily allowed.
  • ChrisH: All of these things should be taken into account for browsers implementing this in their native pickers. AX, form submission etc should be standardized.
  • Anne:
  • Simon: We might want restrictions for native popup so as not to run into web compat concerns. E.g. if one browser supports images and others don't. If we agree on the restrictions we could put them in the spec even though appearance is up to UA.
  • Anne: Fair point, we may want to do this.
  • Luke: May just want appearance: auto to just have the content, nothing else, if this is considered tricky.
  • Anne: Glad to hear we're largely on the same page. Just using slightly different languages.