Matthew: I wrote a sort of proposed comment... I think the use case is a good one to be trying to solve.. some issues, particularly this changes long established behaviour. On Monday it sounded like that we (or someone) had asked them to be more specific. and actually now we're asking them to be less specific... A couple of other things - one was a question on the way focus order works... The other is: it adds a value to the CSS interactivity property which we just had a concern about in #1037. But still it's predicated on this thing that we asked people not to ship.

Dan: Dependency?

Matthew: it has a dependency on a value on the CSS interactivity property - in 1037 we asked them to not ship so this has similar issues. Jeffrey has also give some feedback.

Marcos: It seems to replicate popover... I don't agree that shifting this from developers to UAs is something that's going to work well.

Matthew: webkit supported popover=hint but not the specific interest target because it overrides the UI for long press. Also: would we want to chnage prefetch rules?

Martin: in an application if you tap on something that isn't a link then everything's fine... it's just a matter of building app such that there aren't multiple layers of interaction... This is one ... where we (mozilla) are getting pressure from Google. The upshot is still the same. There is no consensus on the feature. It requires uninform acceptance to change the bounderies of standardization. It has long been the case that long-press is UA behaviour, not something in the spec... Unless Safari willingly concedes that it's subject to standardization then I don't see this going anywhere...

Marcos: Martin raises an interesting point around long-press.. Trying to figure out why we haven't standardized the long press...

Martin: well we had context menu for right click...

Dan: in some web applications, context menu is over-ridden.

Martin: e.g. in Google docs...

Dan: just noting that there are examples of a default behaviour and an ability to override the behaviour.

Matthew: I'm sympathetic to this use case ... especially for people who are browsing on mobile this could save users time... E.g. checking the status on a github issue...

Martin: My view is that in this example this is something GitHub could provide you. On sarari a long press already gives you a preview of the page that's at the other end.

Matthew: for me with a vsion impairment that preview isn't of use to me... So I'm sympathetic to the bounderies but also enthusiastic for the use case.

Matthew: the popup is useful because the key info is there .. the preview isn't useful because it's too small to see...

Martin: isn't that an implementation problem? The stylesheet of the

Dan: so it would be an extension of responsibe design...

Marcos: a design choice by GitHub (e.g.) ... other option: if you can identify a window... media query - this happens to be a preview - you could

Dan: so a new media query type --

Martin: of type preview and adapt the content accordingly.

Matthew: one of the pitfalls .. if you didn't have the ability to reliably establish you were in a preview you would load the important info first.. rather than limit it to the contents of what you would put in the popover... So the idea of having a special, reliable and simple way of loading as a preview here... I like it bcause it avoids that problem. I also like it because it could be generalized to other sorts of preview cards...

Dan: where does the info you're interested in come from?

Marcos: could be in the page, could be that you need to load it...

Matthew: presumably ... you get told the page is being loaded in a preview ... could do the same thing on desktop... I'm sure that involves more transfer of data... and on mobile transfering less data would be desirable.

Marcos: you could do a preview source if that was a concern...

Matthew: we could say "interest target and interest target source"...

Marcos: there are other ways of solving this problem... for example considering using a media query, loading an alternative document, etc...

Martin: if your list contains everything you need to display the preview fine, but in some cases it doesn't... if the goal is to use the preview as a stepping stone it makes sense to load and prepare to render the page... so having it be a different type of content... might be a bad thing. The savings is... having a bootstrap but doesn't cost a bunch extra until we load it...

Matthew: this is about avoiding the need to load the other page... I think I will rephrase the draft comment.

Matthew: definitely the use case is a good one... I will have more of a comment by breakout C.

Jeffrey: this is an interesting one. Martin and Tess don't like the way OpenUI are proposing this... The issue is that hover on a touchscreen is really difficult ... originally they proposed that you would express interest in a platform-defined way. They tried to provide that direction... long-press... however long-press already shows a context menu / preview (on some platforms)... and Tess is unhappy with changing that behaviour (in Safari)... We could help ... They landed on normatively requiring long-press... Whereas we could say "it's a way"...

Matthew: it does seem unusual to be that proscriptve about UI in a spec...

Jeffrey: we say some similar things elsewhere... but e.g. VR headsets might need an entirely different UI for "expressing inetrest"

Yoav: one more thing about this general pattern... pattern that devs have already been implementing... some conflict there with intention to prefetch... looking at speculation rules... and this pattern. They are not 100% at odds but some conflict. This pattern encourages people to engage with links without necessarily visiting.

Jeffrey: that's a really good point that we should include.. Maybe interest target should turn off prefetching... or developers could specify how to prefetch the result...

bump to breakout C

• Previous discussions:
  • Want them to find new ways of thinking about this
  • From Slack discussion: Apple not interested in this use case, so suggesting that they find ways to make Apple happy might not make sense
• Continue discussion
  • There are some interesting and important boundaries here. Typically we shy away from specifying UI, have never attached specific things to long press. Doing so now encroaches on what browsers considers UI.
  • Draft comment: consider other ways to solve the problem of improving a review of the target page
  • If we take links out of the equation, it's far less of an issue
    • You could long press on stuff that doesn't encroach on exisiting UI. But there are no user affordances
• Open question: how requested is this feature? Sympathetic to use cases, but also need to let browsers control their own UI
• Original proposal was to leave it up to UAs. The implicit idea was that long press would show a context menu with an item to show the interesttarget. They suggested UI because Apple asked them to suggest UI. Apple didn't ask them to mandate UI, just asked to show what it looks like, so the proponents did more than was asked in mandating it.

Matthew: Discussed this, needed to comment … have concerns about possible alternative ways … put a revised comment in the brainstorming thread … want to make sure that Marcos is happy with it Hadley: Can we put a comment in the brainstorming issue so Marcos has a look? Matthew: Will ask Marcos and Jeffrey for comments. Hadley: Ideally, contact them via Slack

Wait for Martin and Marcos.