Meeting minutes
<astearns> github-bot, take up whatwg/
Touchscreen behavior for the `interesttarget` attribute
<github-bot> OK, I'll post this discussion to https://
masonf: interesttarget gets put on an element, and when the user shows interest in the element, it triggers interest in the target element. when you hover with a mouse it shows the popover, and when you take the mouse away from it then it hides the popover
masonf: with keyboard, focusing the element shows interest. theres also partial interest to prevent hijacking the focus order
masonf: were now moving on to touch screen. we talked about this last time
masonf: touch is the most difficult way to show interest, because the kinds of patterns you can use are limited
masonf: our first proposal was to just say in the standard that user agents had to provide the user some way to show interest in an elenent but not say how
masonf: there was webkit pushback that it should be specified so that its the same on all platforms
masonf: based on that we did design in openui, and we had multiple ideas we kicked around
masonf: the only one that people were happy with was long press is the trigger, and when you long press something that has interesttarget, you get both things - interest is shown and the browser contextmenu shows up
masonf: there is a way to make them both get shown on the screen at the same time
masonf: there is some pushback on that. it is a funny pattern, might be confusing
masonf: those were the comments we were hoping to come back to
masonf: im prototyping this in chrome and ive been talking to chromes mobile ux team and they have pretty much the same feedback
masonf: i think it needs more work and exploration but there is some feedback about that
masonf: i think this proposal does make sense when you see it in action
masonf: the alternative is much more simple. if the user agent shows a contextmenu with an additional menu item to show interest
masonf: it takes two taps and takes extra work from the user. developers were not that happy about it, but at least it does allow the user to get to that content
masonf: i dont want to lock people out of the content that desktop users can see
masonf: or we can leave it to the user agent. for touch, maybe different UAs can do different things customized to that user
masonf: i would like to get to a direction youre happy with
masonf: we can debate which one is the best
annevk: general concern with this feature is that theres no great platform precedent for it
annevk: on desktop theres a clear hover based ui that you can emulate
annevk: on touch screen theres no such thing and for spatial computing devices
annevk: not discoverable for end users
annevk: you could reimagine existing features, but then they dont do what users expect anymore
annevk: it doesnt try to standardize something that already exists, it tries to add completely new ui paradigm, not something that standards body is well suited to do
masonf: clarifying question: no platform precedent for it - meaning long press?
annevk: long press on ios is a way to get link preview and context menu. i dont know what happens for long press on android. its not customizable by apps. you can get touch events and implement your own thing, but then youre pretty far away from affordances that the platform offers and what users might expect
masonf: that is what i was thinking - the second proposal was keep exactly that. the current thing in android and safari is it gives you a context menu, so lets just add something to that menu
annevk: is that something that web develoeprs would even want?
masonf: if its that or nothing then yes, and it sounds like its that or nothing
ntim: people will start by designing on a desktop. the way it might be shown on a touch screen might not be accounted for
ntim: especially if its so hidden
masonf: in the "show both" idea where you show both the context menu and popover is that developers wouldnt consider it and it wouldnt be placed correctly
masonf: for customizable select, we decided the same styles for desktop and mobile, and you just have to add styles for mobile
annevk: we havent investigated this, but it further blurs the distinction between what is platform ui and what is in the website
annevk: all the context menu options are related to platform actions like open in a new tab or share or copy
annevk: but this goes back into the website, and that might lead to user confusion about what ui is which, which in the long term would not be good
annevk: there was something of ? related to the address bar that talks about a similar issue in the past
<astearns> arguably the link preview is *not* OS-provided UI, so adding more to that might make sense
lwarlow: we touched on the line of depth thing in the past
lwarlow: in practice, there is a very subtle indicator that something is browser ui vs website ui on mobile
lwarlow: in practice theres not really a clear indicator, and sites can already spoof browser ui, and basically no user can figure it out. very subltle shadow on browser ui
lwarlow: i think the line of depth aspect felt wrong at first, but its probably ok
lwarlow: if we had it as a context menu item, it would be important if we had a way to skip the context menu and go straight to my thing
lwarlow: if you have a button and set user-select:none then its going to go straight to the context menu
lwarlow: maybe theres a way to open preview for links and you could provide your own button to visit the link. wikipedia has this, open in new tab option
lwarlow: you can just go in and preventdefault on the contextmenu. apparently webkit also has a thing where you can disable it in css
lwarlow: theres already ways to say youre in control
lwarlow: if we have that as an option, then id be fine with a contextmenu option as a default, and the web developer can have an option to skip straight to the content
lwarlow: ive always slightly disagreed with the consensus
lwarlow: i think it avoids what i imagine is quite a bit of implejnentation complexity where you show them both and environment variables
lwarlow: even just the safe area inset variables can get tricky
lwarlow: accounting for those and the keyboard thing as well and the contextmenu and all of that so that your ui renders nicely is probably quite diffulct
lwarlow: avoids some issues with small screen where its not feasible to do both
lwarlow: youd end up in a situation where the site doesnt want to show both at the same time
lwarlow: there is an existing pattern, its long press
lwarlow: on android, icon buttons show something on long press which is like a tooltip
lwarlow: likewise on ios you had 3d touch and now youve got long press which shows context things
lwarlow: only novel thing is that its declaratively doable which doesn't seem like a bad thing
lwarlow: but forging a new path for something thats not necessarily discoverable
masonf: you can as you mentioned cancel contextmenu and get just interesttarget behavior
masonf: i want to get the both behavior. the fundamental is that theres only one gesture, it can mean two things, and the site doesnt necessarily know which one
masonf: i want to keep access to show both
masonf: we did discuss security issue, our security folks and people in the issue showed it doesnt matter
masonf: showing an item in the context menu doesn't have this problem, because when youve chosen it the context menu goes away and now its back to the site
annevk: i would be interested in knowing the techniques that people use to prevent the thing from showing today, those might not be intended
annevk: if people had code samples id be interested
annevk: at least for me, the line of depth concern is still real
<masonf> addEventListener('contextmenu',(e) => e.preventDefault())
annevk: there are cases where the lines are blurry but i dont think that means we can ignore it
annevk: there still is a concern because we dont have cases where you click browser ui and the website does something in response
annevk: there might be with web target destinations, but we might not support that. in general that is not a thing that
<past> luke shared https://
<masonf> the unload event?
annevk: i have a hard time trying to come up with precedent for that kind of thing
annevk: some buttons end up doing a new tab, and some buttons trigger something on the website, but we dont know if the website display:nones the popup
past: you said that for platform specific interactions its not great when standards bodies come up with new ones
past: when we said that the behavior is not explicitly specified, is that an option youre warming up to?
annevk: if theres no real precedent then we should not invent something. maybe we should wait until that thing is realized, and then we can figure out how to integrate that into the web
masonf: isnt that a chicken in egg problem? it will never happen
masonf: theres no api that the developer could use to show both things. by definition we will never have an example of that
annevk: if that was desired then theyd put it in apps
masonf: long press is already exposed in native apps, huge precedent
annevk: you mean when you long press a link in a native app?
masonf: links are a thing from the web. in wikipedias app, when you long press you get things
masonf: if you long press an app you get a list of things to do with the app
ntim: i dont know if theres precedent for long press having the same behavior as hovering an item on desktop
annevk: these long press things are very different
annevk: the thing that long press does is different from hover on desktop
annevk: on desktop we dont show on hover
masonf: if you long press on something on the screen it will show a contextmenu. if you switch to the mac you get different behavior. on touch screens, native apps on mobile long press is the way you show interest in something
annevk: im not sure thats correct
annevk: contextmenu is not a thing of interest, not on desktop either
annevk: right click, its different. different semantics
masonf: you have more degrees of freedom on desktop
masonf: hovering an icon will show you a tooltip which is equivalent to this
annevk: not equivalent to long press
masonf: on android it is. the fundamental problem is that you have only one finger and you cant hover
masonf: it is like hovering and right clicking on desktop
masonf: on desktop you have multiple gestures, but on mobile you only have one gesture
masonf: were trying to allow access to hover with that one gesture
past: we are 31 minutes past the hour and id like to time box this so we can get to more discussions
annevk: i think were going in circles, lets go to the next topic
masonf: it sounded like the pushback is that we will wait for the precedent to emerge, can you give me a flavor of what that might look like since its not possible?
annevk: luke mentioned force touch earlier. thats an example of where there are some new input affordance that can allow users to discover more things. that also came with proposal for web api for develoeprs to tap into that. that fizzled out before my time, but it could be something like that. its brought to apps and the web, and we can make use
of that in some way
<astearns> It might help to show examples of long press giving hover-ish functionality in native apps. In my tiny sample in the last 5 minutes, it looks to me like long press only does right-click-ish things in native iOS apps
masonf: there already is a gesture. force touch became long press, which seems to satisfy the need for mobile apps. a new gesture would exist only on browsers on mobile, and that would not be discoverable. users spend most of their time on native apps and native apps use long press
ntim: maybe there could be a device that literally allows you to hover your finger over the screen
masonf: some devices do that, but its not discoverable because its only used on browsers
masonf: i think they got rid of that for phones because people werent used to it
past: there is an action item for anne to look at the links that luke and mason shared
past: i suspect we will want to have the topic come back another time
end
<astearns> ntim is showing https://
<astearns> If any of the resolutions ntim summarizes seems very wrong to you, please feel free to comment in the issue. We can revisit issues if there is any new information we did not consider
<dbaron> lwarlow, if you can add a pointer to that in w3c/
<astearns> github-bot, take up w3c/
[css-forms-1] Shouldn't all buttons be replaceable with custom content?
<github-bot> OK, I'll post this discussion to https://
masonf: the reason i wanted to discuss this here is because there are a couple things - issues against css-forms-1, they are things that affect html and css
masonf: in the context of buttons, some of the buttons that are in the proposal, like the button in the file picker, are not replaceable with content. you cant put your own html <button> in there.
masonf: some design systems have buttons, like angular. its a very complicated thing with animations and hit testing
masonf: if were redesigning all the form controls, you should be able to use a button from a design system, or hide the control and build it from scratch
masonf: i think the idea here is to let people use the existing form controls
masonf: css-forms is a css spec, but it should be fair game to talk about html too
masonf: customizable select did this, a lot of behavior that changed in html. maybe we should do that where needed for other controls
annevk: this means theres still a lot of confusion about what these things are
annevk: we could have done appearance:base for select without semantic changes
annevk: if we wanted the input type file button to be replaceable, youd have to put a button somewhere in the tree and make the input reference it. it doesn't have anything to do with css
annevk: we have to figure out how it works for auto and none anyway
annevk: if appearance base comes after that, then we have to figure that out
annevk: use this layout tree with appearance base. theyre not intertwined in the way you suggest. one is about styling and one is about ?
annevk: there was big confusion about the select element from google about this
annevk: this part we change in the semantics layer, and this part is in the parser
annevk: you could ship them separately
annevk: i dont know why we keep revisiting this idea that html and css co evolve in lock step
lwarlow: they dont have to be intertwined. we could have done appearance base select and not done the parser and replaceable buttons, but it wouldnt have solved use cases
lwarlow: we could have done this afterwards, and we could have done them separately
lwarlow: maybe for 95% of these controls, its not as important as the parser changes for select
lwarlow: i dont think its wrong to think about html composability while we do this. especially because it does have an impact about how appearance:base is defined for some of these controls
lwarlow: one solution is that we do have command invokers now, you can have buttons do things declaratively. for the file picker, you could just have a way to say heres a button, it calls showpicker on the other one. using css and customizability of file inputs now, you could hide it and put the other thing in its place. anchor positioning lets you
do this now. maybe it solves the use cases enough
ntim: one of the reasons i wanted this discussion to happen after is because if we introduced composability now and people start using that before they use pseudo elements, then youre essentially teaching a bad pattern for simple use cases.
ntim: unnecessarily complex pattern for simple use cases
ntim: it would be nice if what we have now came out and people start using them widely and then see where the gaps are if there still are some
ntim: i think it would be good to teach the simple thing first before the more complex way of doing things
ntim: i agree with anne that they are mostly independent
masonf: in select thats exactly one of the things that we designed it together. you can design some parts of the in page control or replace its content
masonf: in desiging them together, simple and compelx things are doable
masonf: for file input if you expose the pseudo now and compose later then ?
masonf: angular is going to jump through a lot of hoops to make their ripple effect happen with the pseudo element, but if they have the composability now then its going to be much easier for them to implement
masonf: i dont know a system where you design half and then design the other half
annevk: i dont think its like that. enhancing the semantics of the element is different from making things stylable. theyre not tied into appearance base. if appearance base already exists, then how does it this impact the layout tree that we have. we could have done that with select, and i dont think your argument about how its difficult for
angular is correct
annevk: it would be wrong if these things are so dependent as we suggest. that means we can never enhance the semantics
annevk: we want to continue to evolve these controls
annevk: in the next 5 years, if they actually have to be designed at the same time then theres something wrong
annevk: wouldnt it be bad if it required a new appearance value?
masonf: luke said it best. wouldnt it be a good idea to think about both halves?
annevk: the issue i have is blocking the work that were putting into appearance base with the idea that it needs to be developed with new semantics
masonf: im not blocking it
annevk: i think its fine to discuss it, but it seems like its blocking appearance base
end
<astearns> no need to wait for the next meeting - just add comments to the issues now!
<past> excellent point!