| 06:27 | <Domenic> | annevk: ping on https://github.com/whatwg/fetch/pull/1737 when you get the chance |
| 08:57 | <sideshowbarker> | zcorpan: Are you aware of any particular sites/cases for which the firing order of textInput and beforeinput is a problem? |
| 08:57 | <sideshowbarker> | Or short of that, do you have an idea of what possible problems it might cause? |
| 08:58 | <sideshowbarker> | I’m not questioning that we should have interop on it. I’m just hoping to get a sense of the developer story around it — what problems/pain it causes for developers |
| 09:58 | <zcorpan> | sideshowbarker: not aware of any instances of problems for textInput specifically, but recall seeing complaints about the lack of interop in event order generally is a pain. e.g. https://youtu.be/1bZYmpOOC8U?si=tVeWBiVbwAnRpvPt&t=392 for focusout/blur/focusin/focus order |
| 09:58 | <sideshowbarker> | thanks — I’ll take look |
| 09:59 | <zcorpan> | jQuery overriding it (until v4) is telling |
| 10:06 | <sideshowbarker> | yeah, agreed |
| 10:38 | <hsivonen> | annevk: The interop situation here is pretty sad: https://hsivonen.fi/idn.html when trying to see which URLs the browsers try to fetch. (Note that those URLs don't go to working server setup.) It seems to me that Safari is the closest to the spec, Firefox enforces the bidi rule on a per-label basis instead of whole-name basis, Chrome is just weird. |
| 10:40 | <hsivonen> | Those host names do have DNS entries, though. |
| 16:02 | <nakima> | Yo |
| 16:02 | <nakima> | Dripg is in the matrix area with chocg |
| 16:17 | <nakima> | Ok what's next new to element |
| 18:01 | <smaug> | keithamus: I guess I need to still learn how that tooltip thingie is supposed to work. |
| 18:02 | <smaug> | somehow when on mouseover you trigger the hint and there are attributes which does all that magic? And when mouseout happens then tooltip can be hidden? |
| 18:03 | <smaug> | ....except if mouse moves on top of the tooltip, then it should be hidden too even though mouse can be still over the element which triggered showing the tooltip.. |
| 18:03 | <smaug> | (I'm know we've had various issues with tooltips with xul:tooltip) |
| 18:04 | <keithamus> |
There is an alternate set of invoke actions we're calling "interest" which is mouse or keyboard focus, and the |
| 18:04 | <keithamus> | So for e.g. ^ Hovering or focussing on this tooltip would open the popover. Losing focus or mouseout would close it. |
| 18:05 | <keithamus> | Separate to the invocation is the desire for a separate tooltip stack, (which we've named hint), which would only close other hint popovers, and not close auto popovers. (auto popovers would close both IIRC) |
| 18:10 | <keithamus> | ....except if mouse moves on top of the tooltip, then it should be hidden too even though mouse can be still over the element which triggered showing the tooltip.. interest to abstract from when it is removed. We've discussed various ways in which the to provide UI affordances to keep "interest" on an element, which includes mouse/keyboard focus staying within the interesttarget, but also includes a "safe triangle" calculated between the cursors current position and the boundingrect of the interesttarget, to ensure that users can easily move their pointer device between the interest invoker and target. |
| 18:10 | <smaug> | And how do you hide the tooltip when moving mouse to be on top of an element which doesn't have tooltip? |
| 18:11 | <keithamus> | interesttarget dispatches two events on the target element; interest and loseinterest. So the proposal is that popovers will open on interest and close on loseinterest (similar to invoke but there's two events). |
| 18:16 | <keithamus> | So concretely, if a mouse user moves their mouse on top of an element with interesttarget, then the element that is the interesttarget - if a popover - will open and dispatch interest. If the pointer moves beyond the interesttarget and the button (and the proposed safe triangle) then the browser will hide the popover and dispatch a loseinterest event. |
| 18:17 | <smaug> | How does this work if the tooltip node is underneath (in dom) the element, for which the tooltip is created for and you move mouse over the tooltip? |
| 18:18 | <keithamus> | moving your mouse over the tooltip will not fire the loseinterest event, and not close the tooltip |
| 18:19 | <smaug> | Isn't that quite surprising? |
| 18:19 | <Luke Warlow> | That's the accessible way to do it |
| 18:19 | <Luke Warlow> | The title attribute is wrong in its behaviour in that regard |
| 18:20 | <Luke Warlow> | Focusing the popover would also not close it when using interesttarget (for the same reason) |
| 18:21 | <Luke Warlow> | If you think of the dropdown menu concept with nesting menus you don't want the sub-menu to close when moving from the interest trigger to the sub menu for example |
| 18:21 | <smaug> | That is quite different ui |
| 18:21 | <Luke Warlow> | Same trigger mechanism though. (admittedly hover triggered menus aren't great but it's just an example) |
| 18:22 | <smaug> | Tooltips tend to hide, also outside browsers |
| 18:23 | <Luke Warlow> | Example of an interest triggered UI |
| 18:23 | <Luke Warlow> | You want to be able to interact with the popover |
| 18:23 | <keithamus> | This is part of the reason why I think it should be distinct from tooltip,. Tooltips have some purpose, and should remain on the platform as-is. popover=hint and interestarget might be able to replicate somthing tooltip-like, but the much more interest aspects are interactive floating UI such as github hovercards |
| 18:24 | <Luke Warlow> | sent an image. |
| 18:24 | <smaug> | Right. That wikipedia thing isn't a tooltip |
| 18:25 | <keithamus> | I am glad we're in agreement 😉 |
| 18:26 | <smaug> | And which is why I was talking about tooltips specifically |
| 18:26 | <Luke Warlow> | Tooltips tend to hide, also outside browsers |
| 18:27 | <Luke Warlow> | If content shows by hovering then hovering that content should not close it. (Except if it's UA provided UI which I don't think should behave the way it does but it does) |
| 18:27 | <smaug> | (anyhow hopping of the tram, back later :) ) |
| 18:38 | <Luke Warlow> | Quick question regarding whatwg participant data, I originally signed up as an indivual but am now part of the Igalia organisation. Do I need to remove myself from https://github.com/whatwg/participant-data/blob/main/individuals.json or will the system handle it? |
| 20:35 | <smaug> | keithamus: hmm, so, loseinterest is dispatched when? When pointer is outside both triggering element, and outside the tooltip? |
| 20:43 | <Luke Warlow> | keithamus: hmm, so, loseinterest is dispatched when? When pointer is outside both triggering element, and outside the tooltip? |
| 20:44 | <Luke Warlow> | (and potentially in other UA defined scenarios for wilder input modalities) |
| 20:44 | <smaug> | and how does one hide the tooltip? |
| 20:44 | <smaug> | (per that WAI document "A mechanism is available to dismiss the additional content") |
| 20:45 | <Luke Warlow> | Escape key (or other close requests e.g. android back gesture) |
| 20:45 | <Luke Warlow> | Same as auto popover |
| 20:45 | <Luke Warlow> | Also click outside |
| 20:47 | <smaug> | ok, so this all is very much not a tooltip but something else (which is perhaps fine, especially if it is called "hint") |
| 20:48 | <keithamus> | Right. But it might be used/abused to make tooltips. |
| 20:49 | <smaug> | but not really tooltips, since the behavior is so different |
| 20:49 | <Luke Warlow> | I don't agree it's not a tooltip? |
| 20:50 | <Luke Warlow> | It's not solely a tooltip but I don't see why it can't be used for one? If the popover is purely text (with appropriate semantics) then why wouldn't that be a tooltip? |
| 20:51 | <keithamus> | In the traditional sense of a tooltip which is non-navigable, non-focusable, and dismissed via non-escape presses (eg ctrl key) this is not that. |
| 20:52 | <smaug> | and is hidden when pointer moves over it |
| 20:53 | <Luke Warlow> | and is hidden when pointer moves over it |
| 20:54 | <smaug> | I'm not saying anything about a11y requirements 🙂 It is just how tooltips have traditionally worked. |
| 20:55 | <Luke Warlow> | To clarify for my understanding are we talking about title attribute tooltips or something else? I'll admit I'm not super familiar with native platform behaviour off the top of my head |
| 20:56 | <smaug> | native behavior, since that is where title attribute behavior is derived from |