Csswg-drafts: [css-box] increase pointer target size independently of element layout

[tylersticka]

It's critically important that touch/click target sizes be adequate for an interface to be usable. But sometimes the visual needs of an interface element are out of step with its ideal pointer target size.

Some of the ways developers deal with this today:

• Nesting additional elements so the interactive area can be defined separately from the visual appearance. This complicates the markup.
• Using transparent borders and background-clip. This forces use of box-shadow in place of border and may also prevent border-radius from working in the expected way.
• Absolute positioning pseudo elements larger than the parent element. This conflicts with overflow: hidden.

It would be cool if we could somehow _extend_ the pointer box of an element without impacting its layout or visual appearance?

.button {
  pointer-box-offset: 0.5rem;
}

(I was encouraged to submit this issue after writing about the idea.)

[fantasai]

This sounds like a straightforward solution to a reasonable problem! Copying terminology from border-image I'm gonna suggest outset rather than offset, though. :)

Side note: pointer-events still hasn't been added to the spec per https://github.com/w3c/csswg-drafts/issues/4438 pokes @frivoal

[smfr]

We'd need to define what happens boxes that are fragmented (split inlines etc), regarding whether the outset applies at the fragmentation edge. We'd also need to define its interaction with the various clipping mechanisms (overflow, clip, clip-path etc), whether touch-action regions are impacted, and whether the target region affects all interaction-based DOM events.

[fantasai]

@smfr Good points. Perhaps it should be a single value, like shape-margin? Then it can outset whatever the boundary line path is. Wrt fragmentation, I'd say you want to expand per fragment. I think most of the point is to impact touch? Probably should affect any coordinate-based DOM events, exactly as if the border area had been expanded--the current workarounds are effectively trying to do exactly that, just without affecting the painting area.

[bfgeek]

One additional related thing we've seem some asks for previously is defining a "shape" for the touch area as well. E.g. somebody is creating a visual effect but wants to limit the hit-test region to a circle/ellipse/arbitrary-path.

(This additional request shouldn't block progress on a "margin" property, I'm bringing it up b/c I want to make sure we don't exclude this type of request in the future).

This extension point almost fits within the existing pointer-events property, e.g. extending by:
pointer-events: none | auto | <shape-box> || <basic-shape> | <image>
One possibility for this feature for this particular request would then be:
pointer-events-margin: <length>

Ian

[c-smile]

There is a known term in UI for that entity - hit testing. See: WM_NCHITTEST as an example.

So I think hit-margin would sound reasonably well for that purpose.

If that matters, in Sciter I've implemented this functionality using that name.

[upsuper]

I like the idea, and it's indeed highly desired.

It might be worth considering that, though, how to handle such "margin" property with border-radius and clip-path. For example, if you have a circle element, would the hit area be a circle or a square (or a round-corner square)? If you have a complicated shape via clipping, how should it work? I'm not very sure about the answer here.

[c-smile]

if you have a circle element, would the hit area be a circle or a square (or a round-corner square)?

I would use standard margin production for that : up to four lengths to define rectangular hit-box.

We also can add extended form like these:

hit-margin: border 10px;
hit-margin: clip-path 10px;

[css-meeting-bot]

The CSS Working Group just discussed [css-box] increase pointer target size independently of element layout.

The full IRC log of that discussion

<dael> Topic: [css-box] increase pointer target size independently of element layout

<dael> github: https://github.com/w3c/csswg-drafts/issues/4708

<dael> fantasai: Seemed reasonable proposal. Came from someone posting on twitter, I said file and issue, they did with nice diagrams. It seems to be a nice proposal nd solving a problem

<dael> fantasai: Seems simplier. Basically hit margin with a length and it expands outward from border edge of element

<dael> astearns: Expands the not quite defined hit area

<dael> fantasai: Yep

<dael> smfr: mobile browsers do area hit testing where if you tap browser looks around touchpoint. So there's built in hit test area expansion stuff. Don't know if have to define how that interacts

<dael> chris: Woul this replace or coeist

<dael> smfr: Not sure, I guess coexist

<dael> astearns: Define what mobile browser does in UA stylesheet.

<dael> astearns: Would be good to see if what we define would suffice for ua stylesheet. If not should fiddle

<dael> smfr: Good point. Also hit test can't leak outside iframes. Cross origin you can't allow it to got o the parent iframe

<dael> smfr: Also slightly concerned about clickjacking. You can do a link that covers document. Could do same with event hanlers but slightly nervious

<dael> astearns: Can't do same with slightly opque element on everything?

<dael> smfr: Yeah, that's not new

<dael> fantasai: Could limit size, can't have margin larger then something reasonable. Can already do the same thing as you mentioned

<dael> plinss: I haven't read it but does it define how to handle overlapping elements?

<dael> fantasai: aalreayd have to define. This increases border box fo hit testing w/o painting it

<dael> astearns: It does allow touch places to overlap where wouldn't notmally. Can do it with positioning but this is new overlap

<dael> smfr: Complicates impl b/c gneerally hit testing is painting in reverse. You hit test front to back. With this you extend elements to correct order in way that only effects hit testing. Leads tocomplications

<dael> plinss: Want to make sure it's defined even if treated as overlapping [missed]

<dael> astearns: Yeah, this would be cool to have. Need somebody to write a proposal. Who would that be?

<dael> astearns: And spec?

<dael> fantasai: CSS UI 4

<dael> astearns: Who are editors?

<dael> smfr: [missed]

<florian> I am an Editor of UI-4

<smfr> s/smfr/florian me/

<dael> tantek: This is very geometry related. Related to box model. And to hit testing which is undefined and may be worth spec on own.

<dael> tantek: Not similar to other cssui properties.

<dael> tantek: I don't think we should burden cssui 4 without florian saying he can help

<dael> florian: I'm not opposed to idea but not committed to idea.This is hard, hit testing is hard

<dael> tantek: And people who have tried to spec hit testing have run away

<dael> fantasai: I don't think this is too hard. I'll take the action to make pr

<dael> myles: Question: idea is inflate touch target so people can hit with fat finger. If that's try why isn't value a bool?

<dael> TabAtkins: Agree. You just want to make sure target is wide enough without ensuring whole element is wide enough. So make this target a fingerprint wide seems reasonable

<dael> tantek: Maybe 3rd state to shrink target area to avoid errant activation. UI elements that are damaging you want to reduce accidental compared to button they're near. Length may be overdesign, I agree

<dael> chris: Intended to cover case where there's a button but it's not a code button and you have text that is a link and you want if people click in general area. Is that use case being solved?

<dael> tantek: Should be solvable with eisting markup

<dael> astearns: Whole problem is solvable with markup now but as author states it's unfortunate to change makrup to get hit testing

<florian> s/this is hard, hit testing is hard/I don't think this is partcularly hard in itself, but hit testing in general is, so that depends on whether we open that can of worms/

<dael> tantek: I meant w'o adding more markup. Text link you can add explicit directions. I think we should distunguish common author errors and use cases we want to enable. Common author errors aren't fixed with a new feature

<dael> fantasai: I don't see how existing properties solve this w/o creating fake elements. Text link where you want to increase size of link without layout impact

<dael> tantek: But its' a text link inside something htat looks like a button and the answer to that is make it a button. I agree there are use cases for button with area around it like example in issue. That's legit.

<dael> tantek: I like it being higher level so UA can decide based on device. Don't need every webdev to solve what device with which resolution...I'd hate to put that burdon on webdev and UA can solve if there's touch-target: larger

<dael> myles: even on phsycial device can have larger resolution

<tantek> I'm suggesting a trinary

<tantek> per the shrinking use-case

<dael> astearns: We've had good discussion around length or bool. Let's engage issue poster on opinion between options and work from that?

<fantasai> +1 to astearns

<dael> tantek: I agree with sentiment

<dael> astearns: Okay, let's get back to Tyler. I'll ping

[c-smile]

florian: s/this is hard, hit testing is hard/I don't think this is partcularly hard in itself, but hit testing in

I don't think it is that hard.

It is just about replacing existing [pseudo-]code

if ( point is in el.border_box() )
  ...

by

if ( point is in el.hit_margin_box() ) // or path
  ...

Yes, there are issues with overlapping elements but that can be solved by authors using existing means:

button { 
    hit-margin:1em;
    margin:1em; // to avoid overlapping with siblings
 }

or

button { 
    hit-margin:1em;
    position:relative; // to move it in front of z-order
 }

[smfr]

One reason to have a flag, rather than a length, is that these hit-test margins need to scale with page zoom; you need relatively larger hit-test margins on a page with a small scale than one with a big scale (after the user zooms in). UAs don't want to re-evaluate style on zoom, so we don't want units that change with zoom.

[smfr]

hit testing is hard

I meant for implementors, not authors.

[astearns]

@tylersticka could you look through the minutes above and weigh in with your thoughts about making this property more high-level (larger/normal/smaller instead of a particular size)?

[plinss]

Gave this some more thought, we definitely need to carefully define how overlapping hit test areas work, and it’s more than standard overlapping element logic. My concern is when you have two adjacent elements and the extended hit test area of one covers another clickable element. If the user clicks inside an element, but also inside an extended hit test area of a sibling with higher z-order, the click should still go to the clicked element, not the sibling. Especially with dynamic layouts, it’ll be too easy for elements to slip under other element’s hit test areas and become unclickable in ways authors may not anticipate.

[tylersticka]

Really quick, I'd just like to say "thanks" to everyone for giving this so much deep thought and discussion. Greatly appreciated.

@tylersticka could you look through the minutes above and weigh in with your thoughts about making this property more high-level (larger/normal/smaller instead of a particular size)?

I've re-read the transcript a few times, and I'll admit to feeling pretty skeptical.

Let's say you have a horizontal menu containing multiple buttons side by side with some space around and between…

<div class="menu">
  <button>Button 1</button>
  <button>Button 2</button>          
</div>

.menu {
  display: grid;
  grid-auto-flow: column;
  grid-gap: 1em;
  padding: 1em;
}

Now let's say we want to extend their interactive area a bit because we want them to be easier to touch. To pull this off today, we might use a pseudo element that extends outward by half of the gap (CodePen):

.menu button {
  position: relative;
}

.menu button::after {
  content: "";
  position: absolute;
  top: -0.5em;  /* half of grid gap */
  bottom: -0.5em;
  left: -0.5em;
  right: -0.5em;
}

This extends the hit area for everyone, and mouse users get a more seamless experience when moving their cursor from one menu item to the next. Hooray!

Now in a world where I have hit-margin (or whatever we might call it) and I can specify an exact size, simplifying this CSS is very simple. I can instead write:

.menu button {
  hit-margin: 0.5em; /* half of grid gap */
}

Since I defined a grid-gap of 1em, I _know_ that 0.5em is the most I can extend the hit area without overlap.

But I'm not sure how I would do that with keywords alone. How do larger or smaller relate to the white space choices I've defined in my CSS?

[c-smile]

For the note: you can try hit-margin live in https://sciter.com

<html>
    <head>
        <title>Test</title>
        <style>

.menu {
  flow: horizontal;
  border-spacing: 1em;
  padding: 1em;
  background: gold;
}

.menu > button { hit-margin:0.5em; }

        </style>
    </head>
    <body>

<div.menu>
  <button>Button 1</button>
  <button>Button 2</button>          
</div>

    </body>
</html>

Run usciter[.exe | .app] from GitHub https://github.com/c-smile/sciter-sdk

copy bin.win/x32/usciter.exe and sciter.dll to some folder and run executable
Pretty much the same for MacOS and Linux but in bin.lnx and bin.osx folders.