05:20:44 dgrogan has joined #css 07:14:59 janina1 has joined #css 07:45:07 projecto- has joined #css 07:45:37 leaverou_ has joined #css 07:46:37 Rossen- has joined #css 07:47:07 shans_ has joined #css 07:47:38 sylvaing_ has joined #css 08:19:04 jfkthame has joined #css 09:10:47 jfkthame has joined #css 15:01:30 RRSAgent has joined #css 15:01:30 logging to https://www.w3.org/2025/03/20-css-irc 15:01:32 RRSAgent, make logs Public 15:01:34 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:02:26 present+ 15:03:46 scribenick: jarhar 15:04:51 Present+ 15:04:52 github-bot, take up https://github.com/whatwg/html/issues/11056 15:04:52 Topic: Keyboard behavior for the `interesttarget` attribute 15:04:52 OK, I'll post this discussion to https://github.com/whatwg/html/issues/11056. 15:04:53 present+ 15:04:59 present+ 15:05:24 masonf: i thought it would be good to intro interesttarget, first keyboard then touch screen 15:05:35 masonf: right now its an attribute called interesttarget with an idref 15:05:48 masonf: use case is hover triggered things. thats a very common use case, its on most websites generally speaking 15:06:02 present+ annevk 15:06:17 masonf: the reason the agenda has keyboard and touchscreen is that the mouse interaction is pretty clear - hovering with the mouse after a delay activates the target which is typically a popover which opens 15:06:20 present+ astearns 15:06:24 masonf: i wont go into much more detail on that 15:06:35 present+ fantasai 15:06:46 masonf: the main concern we have to deal with is that we want to support all input modalities, not just mouse 15:06:52 present+ emilio 15:07:13 present+ smaug 15:07:26 masonf: it solves a real problem for developers. most sites have these tooltips and they have to reinvent this wheel every time 15:07:48 masonf: they either dont think about keyboard/touch or create their own way, and they have no way to handle touch screen users and leaves them out 15:08:37 masonf: looking at design systems today, there are two directions: one is to have a hotkey. when users focus an element that can generate a hovercard, they push a hotkey and it shows up. 15:08:51 nigel has joined #css 15:08:54 masonf: the other way is to show something on focus. if they keyboard focus it then after a delay it shows up 15:09:00 masonf: these are both present on sites already 15:09:42 masonf: the issues are that hotkeys aren't easily discoverable, and that focus based activation is that its a nuisance, if you just want to traverse the focusable elements and you stop somewhere then suddenly you have a hovercard 15:09:57 masonf: the focus issue also happens with mouse, but keyboard users are stuck in this list 15:10:26 masonf: thats fine unless the hovercard has interactive elements, which changes the list of keyboard focusable elements 15:10:41 q+ 15:10:47 masonf: in openui we had a bunch of brainstorming, id like to get ideas from this group too. 15:10:52 q+ 15:11:03 masonf: prefer discoverability, use focus as the trigger 15:12:02 masonf: to mitigate the problem of the focus detours, theres a bit of complexity added: when you stop at a focusable element, it will either have focusable or not focusable elements. it will be rendered in a way that is not keyboard focusable. even if it has buttons in it, hitting tab will not focus into it. at this point, a hotkey will allow you 15:12:02 to move focus into it 15:12:25 masonf: you get the best of both worlds, you can trigger it and see it, but you have a place to show users to press a hotkey to move focus into it 15:12:37 q+ to ask how authors and users find out what the hotkey is on a given platform? 15:12:39 masonf: this is the idea from facebook, this is how they do things today 15:12:57 ack emilio 15:12:58 emilio: i agree that going for focus makes more sense 15:13:39 emilio: i wonder if showing accidentally the hovercard is such a big deal. ideally these would close with escape. if you tab on something you dont want to see, then you can press escape and its gone. seems like a simpler model to me 15:13:41 emilio: that would be my initial model 15:14:01 q+ 15:14:14 masonf: it has been considered, escape does close it since its a popover. there were some a11y concerns. maybe thats a great model though 15:14:40 astearns: i also wanted to ask the same question, escape is not a new thing people have to learn. not a big fan of adding another magic key that you have to learn or have to get announced from the hovercard if its cluttering the ui there 15:14:51 astearns: i expect designers will have that help text be the first thing on the chopping block 15:14:55 q- 15:14:57 ack astearns 15:15:06 ack keithamus 15:15:19 lwarlow has joined #css 15:15:21 keithamus: we trialed showing the hovercard on focus on github, and many users complained. it is not a pattern that uses like 15:15:36 keithamus: something more like a partial disclosure duriing focus and having a hotkey to activate is preferrable 15:15:54 keithamus: the discoverability is hard. because its non standard users dont know how to activate it. i think its alt down or alt up 15:16:05 keithamus: you can do this today and we expose it in our list of keyboard actions 15:16:22 q+ 15:16:29 keithamus: users dont know. we provided alt text which says push alt up to open hovercard, and that was annoying and redundant to screen reader users 15:16:40 keithamus: discoverability is hard, but partial disclosure is the right path forward 15:16:50 masonf: you said users dont like that it shows up on focus? what part? 15:17:18 q+ 15:17:24 keithamus: it was showing up at all. they are large enough that they occlude other important content. if youre using focus to read stuff, and then a popup occludes the thing that youre reading 15:17:37 astearns: and when you had it come up on focus, did you have a substantial delay? 15:17:45 keithamus: yeah we tried with delays as well but its insufficient 15:18:31 astearns: if we have a system where the popover comes up after some delay on a focus and there isn't a particular trigger and theres a hotkey to dismiss it, the user dismissing the popover should disable the popover from coming back again until focus changes i assume 15:18:42 ack astearns 15:18:45 masonf: i think that would be a side effect of the trigger gaining focus and a delay, but yeah we should make sure thats tested 15:18:49 q+ 15:19:10 emilio: i was going to ask keith - this depends on the content right? on github if i press search field and then press tab, that shows tooltips on focus. theres probably use cases for both? 15:19:26 ack emilio 15:19:35 keithamus: we distinguish between non rich tooltips and rich tooltips - we call one a tooltip and another a hovercard 15:19:54 keithamus: users find tooltips ok on focus because most of them are small and dont occlude content 15:20:04 keithamus: some of the longer ones are disruptive, but tooltips are fine 15:20:25 keithamus: hovercards which have buttons and the users bio, are 250px big and occlude a lot of content 15:20:37 keithamus: but they are very useful. we track engagement on them and see that theres very good engagement 15:20:57 keithamus: so yes there are use cases for both 15:20:57 ack lwarlow 15:21:11 lwarlow: the bit about pressing escape making it so it doesn't show up again, that is kind of automatic 15:21:27 lwarlow: if youre using more than one modality - if youve got focus and mouse, does hovering it show it again? 15:21:39 lwarlow: it might be that the gain lose interest mechanism is good enough without anything extra 15:21:55 https://www.mediawiki.org/wiki/Page_Previews#:~:text=led%20to%20a%2020%25%20increase%20in%20links%20clicked%20per%20page 15:22:14 keithamus: ive cited this before, but this is wikipedia saying that when they enabled this hovercard on android they saw 20% more links clicked 15:22:23 keithamus: this is genuiely things that websites want 15:22:47 masonf: the buttons on those hovercards are important 15:23:05 Does Wikipedia explain how they do this on mobile? 15:23:39 astearns: for the case where focus doesn't pop it up immediately, and there is a special hotkey to invoke the popup from focus, how does that get announced to the user? you were talking about the key being in the hovercard 15:23:46 astearns: if the hovercard isn't invoked then that doesn't get announced 15:24:18 q+ 15:24:20 q+ 15:24:20 q+ 15:24:24 masonf: in terms of sighted users - back to the mode where focus shows the popover and theres an additional hotkey to move focus into it, you could have an after set of content which says how to do it 15:24:33 masonf: i dont know what the best way to announce that to AT is 15:24:38 ack lwarlow 15:25:07 lwarlow: regarding the hotkey, whatever mechanism we come up with - if we let the developer style it thats fine but the text should be provided by the browser because the browser should let you remap this 15:25:34 lwarlow: its important that we dont just tell developers to put alt up in there because it might be wrong 15:25:43 ack keithamus 15:25:44 masonf: we probably need to localize the text as well 15:26:01 keithamus: we added aria describedby to say push alt up to open 15:26:15 keithamus: they were ambivalent the first time, but hearing it every time for every link was annoying 15:26:36 keithamus: should we put this into our growth hacking thing, so you only see it 3 times? the complexity on client side is just not worth it 15:26:53 keithamus: if a browser were to do a pattern like that like this is how you can do this thing, that could be a path forward 15:27:00 keithamus: the repitition was the big bug bear 15:27:12 keithamus: were willing to sacrifice ?? for simplicity 15:27:35 masonf: i was talking to aaron leventhal, his concept was you could announce things 5 times, and browser know that and stop it 15:27:39 s/??/discoverability/ 15:27:49 keithamus: there was something else i wanted to add. a big problem as well was deciding a hotkey 15:28:02 keithamus: if the browser had a control, people could get more familiar with it across sites 15:28:21 keithamus: there is nothing that exists today for back button etc. 15:28:40 astearns: since you took the discoverability hit, do you have data on how well it was discovered afterwards? 15:28:42 ack hdv 15:28:43 keithamus: no 15:29:00 hdv: it helps to standardize this so people can get used to it. if there is a standard hot key, then people can get used to their system 15:29:25 hdv: with aria details for popovers, that behaves differently in different browsers. youll hear that you can go to popover content, its different in jaws and nvda, and doesn't exist in voiceover 15:29:53 hdv: thats not a bug but a feature. its a good thing that ATs can decide what to do. authors can hook into a standardized thing, and ATs can do whatever they want, like showing it 5 times and never again 15:30:16 hdv: for me, all of that speaks to yes we need to standardize this and its not invented at github alone because then github doesn't know how to do it right 15:30:53 masonf: i think my summary is that it sounds like most people are ok generally with focus being the trigger ,and theres an open question about this partial interest thing, although keith was maybe like dont use focus at all 15:31:24 astearns: im not sure that we should have a single solution for both small popover and large card. im not sure if its worth to have the complication to have two different ways of doing this that could be misused 15:31:53 masonf: all of these things sound simple, but the devils in the details, and the details are horrendous. thats where we should not make it complicated for a developer but we can put that complexity in the browser 15:32:12 masonf: maybe we can leave it there and move on to touch screen 15:32:33 github-bot, take up https://github.com/whatwg/html/issues/11058 15:32:33 Topic: Touchscreen behavior for the `interesttarget` attribute 15:32:33 OK, I'll post this discussion to https://github.com/whatwg/html/issues/11058. 15:32:48 masonf: on touch screens, the situation is worse than keyboard 15:33:13 masonf: if we were starting browsers today, it would be pretty obvious what to do. every native app has an interaction pattern to show interest, and thats long press 15:33:31 masonf: the issue that we have is that browsers already did that a long time ago, and it already does stuff, and users like it 15:33:48 masonf: long pressing on a link gives you a preview of the link, and you get a menu like share or copy the link or open in a new tab 15:33:56 masonf: users do use those context menu items and expect them to be there 15:34:21 masonf: when talking to developers about this, what should the mechanism be? ok touch screen is taken, lets make up a new gesture, like long press and slide or double tab 15:34:35 masonf: lots of creative things, any of which could be valid, but none of which are engrained in what users know how to do 15:34:45 masonf: if you invent a new gesture just for this, nobody will find it 15:34:56 +1 masonf concerns, weird touch gestures are very undiscoverable 15:35:02 masonf: the very strong pushback from devs seems to be that long press needs to be the thing 15:35:08 masonf: now you have two things to do with this one gesture 15:35:28 masonf: we also considered where you long press, and it gives you the existing menu with another item that says i want to show interest in this thing 15:35:46 masonf: or some magical ux way that you have the existing thing and a new thing 15:36:07 masonf: its too much. long pressing youve already invested a lot of time. if you didnt get what you wanted immediately then youll give up 15:36:14 q+ 15:36:19 masonf: with one long press you should get both: the context menu and the popover 15:36:27 masonf: akin to keyboard, im presenting the current direction 15:37:02 masonf: when you long press on a link, which seems to be the use case that matter the most (buttons are easier), the context menu that you would have gotten still shows up, but in a position that leaves room on the screen for the hovercard that is provided by the site 15:37:24 masonf: in portrait mode on a phone, a context menu shows at the bottom of the screen and the hovercard appears at the top. the user can tap both things 15:37:37 masonf: to do that, the browser has to make room, put the context menu somewhere else 15:37:47 masonf: the browser still maintains control and can put it wherever they want 15:37:59 masonf: on very small screens they can choose to only show the context menu 15:38:11 masonf: it should expose the remaining area with css environment variables 15:38:17 masonf: thats the basic behavior, theres a lot of details 15:38:37 masonf: in most browsers right now, those context menus come with a blurring of the site. that cant be done because then youd blur the hovercard 15:38:42 masonf: that is the concept 15:39:04 masonf: we are prototyping this in chromium. there are a lot of ux concerns. our ux teams are looking at this and deciding whether this is good for users 15:39:10 masonf: is this confusing or is it natural 15:39:27 masonf: there are a lot of open questions about how to do this. just moving the context menu - what if youre on a tablet or landscape orientation 15:39:39 masonf: id love to hear feedback or better ideas 15:40:27 astearns: this idea of adding something to the existing long press ui would have security concerns. the existing long press ui is provided by the browser, so users trust it more than something on a webpage. if any webpage can mimic this part of the browser ui, it can pretend that it is the browser 15:40:46 q+ 15:40:59 lwarlow: anything thats rendered within the frame - they already can spoof it. likewise, a right click context menu it trusted but i can hijack that and render a popover that looks identical 15:40:59 ack astearns 15:41:09 lwarlow: i would say you already can do all of that stuff, unless the ui escapes the frame, but i dont think it can in any of the browsers 15:41:18 lwarlow: if it blurred the browser ui as well theres something there 15:41:31 smaug: it darkens the background, so there is a distinction with a real context menu 15:41:42 q+ 15:41:51 q+ 15:41:55 smaug: also if you show the browser provided context menu and something on top of that, then its confusing for users to know which portion comes from the browser 15:42:04 smaug: i was testing chrome to see how long the context menu 15:42:12 q+ 15:42:15 smaug: if you have a link then it already covers the whole screen, so theres no space for popovers 15:42:17 q+ 15:42:30 smaug: if you have an image which is also a link, then the context menu already covers the whole screen 15:43:00 q- 15:43:04 smaug: theres too many list items, they would need to be redesigned 15:43:28 astearns: have you considered allowing authors to give a long press behavior to elements only if there is not a current long press behavior for that element from the browser? 15:43:52 masonf: the primary use case is on links. on all browsers i know, links are the big thing that has a context menu. buttons are in that category 15:44:01 masonf: links are the key use case where they do intersect today 15:44:35 astearns: there possibly could be a path where we provide a web standard way of defining a long press behavior. we can show that its so useful that browsers will decide to allow the author version of a long press for links with an extra button to get to our own instead 15:44:41 ack masonf 15:45:05 masonf: we talked about that too. that was in the category of the two clicks, thats just the other direction of it. there was pushback on both of those because users really like the context menu, so making either of them harder felt like a no go 15:45:33 masonf: i actually shared your security concern. you can do this today, and i talked to some google security folks, and they all agreed that you can do this today 15:46:02 masonf: there is a blur that is provided by the browser, but the people in this room that this little blurring is a security signal and nobody else does 15:46:09 masonf: i was convinced by that 15:46:45 masonf: olli mentioned that some context menus are very long. in the chromium prototype, the regular one for links with images it becomes scrollable, so it will be important to make sure these are sorted 15:46:54 ack keithamus 15:47:28 keithamus: this is github.com in firefox on ios. if you long press a link you get a preview. this is a native ios behavior. the menu falls off the bottom of the page, and i can drag to show more of the menu or more of the preview 15:47:32 keithamus: this is a common pattern in ios 15:47:58 keithamus: the problem is that the resulting preview is just not very helpful. if i click an avatar, i get a bit of the description, but the button isnt interactive. the button is just going to take me to the page 15:48:22 keithamus: were doing two server requests because we dont cache those. it is multi factorial that we use hovercards: its better ux and better performance, its a cost saving measure 15:48:32 keithamus: most of the data we got about the user we already got in the first request 15:48:53 keithamus: native apps, this is the wikipedia native app. i can long press and get this summary. this is the ideal thing for us 15:49:07 astearns: in the native app, is anything in that preview interactive? 15:49:12 keithamus: not that ive seen 15:49:24 keithamus: social media websites will have a similar feature 15:49:43 keithamus: since they have follow features, maybe theirs are interactive 15:49:51 ack dandclark 15:50:11 q+ 15:50:37 jamesn has joined #css 15:50:42 dandclark: several variants of this have been discussed. ill put in a vote for the two stage model, where the long press gets you the content and then you can press something else to get the context menu from the browser. it solves the space problem because its just one button. it has an additional barrier to get to the native thing, but its not 15:50:42 another long press and its not a new gesture 15:51:06 masonf: i think the best way to spec this - speccing this is going to be an interesting question - but the placement of the context menu is going to be up to the browser 15:51:19 masonf: i think both the ios way and the extra button makes sense 15:51:29 masonf: how and where you render the context menu should still be up to the browser 15:51:35 ack lwarlow 15:51:51 lwarlow: the wikipedia native app on android is different. a tap on a link is what shows their preview ui 15:52:05 lwarlow: it has open in new tab and stuff 15:52:12 lwarlow: clicking the whole preview will do the navigation 15:52:31 lwarlow: i do wonder if this should just be that long press does the interesttarget thing 15:52:37 lwarlow: and the browser should just give up their context menu 15:52:55 lwarlow: its the sort of thing that peoplare going to try disabling the browsers native thing anyway and it will have worse ux 15:53:13 lwarlow: like they might just use a button instead of a link because that disables the browser ui 15:53:20 lwarlow: and use user-select:none 15:53:42 lwarlow: all the friction we add to this is probably just another layer of im not going to use this builtin browser feature. which maybe is fine, but worth keeping that in mind 15:54:43 lwarlow: the other alternative is the context menu you get in browsers, can we just let them render inside it? like replace the preview bit at the top? for links you usually get useless stuff at the top 15:54:50 lwarlow: thats how it works in native apps 15:54:55 lwarlow: the wikipedia example is like that 15:55:09 lwarlow: im hesitant on having two bits of ui just on a devs wont use this perspective 15:55:31 keithamus: we can disable the contextmenu, but thats not desirable because people do use the open in new tab thing 15:55:46 keithamus: we want to retain open in new tab, we can replicate it but its not what people want 15:55:53 keithamus: id like to keep exploring two context menus 15:56:01 keithamus: showing context options is important to me and github 15:56:28 masonf: long press does generate a contextmenu event you can preventdefault, but it sounds like in this room there are multiple opinions, so we could leave it up to the browser to choose 15:56:34 ack keithamus 15:56:46 ack fantasai 15:57:14 fantasai: i thought this was an interesting conversation, but apple does have concerns that are expressed in the issue and i cant explain better than that. just wanted to say there are concerns 15:57:37 astearns: not just apple, i also see martin thompson also expressing concerns 15:57:46 masonf: the concerns are all this feels funny, id love to have more discussion 15:57:46 s/thompson/thomson 15:57:59 fantasai: it would be useful to bring this up where tess and anne can participate. unfortunately they had conflicts today 15:58:11 masonf: can we just keep this particular part on the agenda and that could be the venue? 15:58:20 fantasai: tess will be on vacation next time, anne will be available 15:58:24 fantasai: and we have a f2f 15:58:26 s/will/might/ 15:58:35 astearns: if there is a meeting in 2 weeks, there probably wont be any css folks in it 15:58:49 masonf: maybe we should cancel the one in two weeks, and it sounded like in 4 weeks could be a good time? 15:59:17 fantasai: you might want to check in if they can make that one specifically 15:59:35 dbaron: if you also want martin thompson thats going to be hard to include australia 15:59:50 masonf: or a breakout on this topic 15:59:52 fantasai: yes 16:07:28 topic: end 16:07:36 zakim, end meeting 16:07:36 As of this point the attendees have been hdv, keithamus, dbaron, tantek, masonf, annevk, astearns, fantasai, emilio, smaug 16:07:38 RRSAgent, please draft minutes v2 16:07:39 I have made the request to generate https://www.w3.org/2025/03/20-css-minutes.html Zakim 16:07:46 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 16:07:46 Zakim has left #css 17:01:09 Francis_Storr has joined #css 17:02:39 Adam_Page has joined #css 18:02:58 Penny has joined #css 18:46:22 cabanier has joined #css 19:22:16 projecto- has joined #css 19:22:47 leaverou_ has joined #css 19:23:47 Rossen- has joined #css 19:24:17 shans_ has joined #css 19:24:48 sylvaing_ has joined #css 19:54:07 flackr1 has joined #css 21:07:02 janina1 has joined #css 21:14:22 janina1_ has joined #css 22:50:19 CSSWG_LogBot has joined #css 22:55:48 jensimmons has joined #css 23:10:01 CSSWG_LogBot has joined #css