- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Feb 2020 17:20:00 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-box] increase pointer target size independently of element layout`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-box] increase pointer target size independently of element layout<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4708<br> <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<br> <dael> fantasai: Seems simplier. Basically hit margin with a length and it expands outward from border edge of element<br> <dael> astearns: Expands the not quite defined hit area<br> <dael> fantasai: Yep<br> <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<br> <dael> chris: Woul this replace or coeist<br> <dael> smfr: Not sure, I guess coexist<br> <dael> astearns: Define what mobile browser does in UA stylesheet.<br> <dael> astearns: Would be good to see if what we define would suffice for ua stylesheet. If not should fiddle<br> <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<br> <dael> smfr: Also slightly concerned about clickjacking. You can do a link that covers document. Could do same with event hanlers but slightly nervious<br> <dael> astearns: Can't do same with slightly opque element on everything?<br> <dael> smfr: Yeah, that's not new<br> <dael> fantasai: Could limit size, can't have margin larger then something reasonable. Can already do the same thing as you mentioned<br> <dael> plinss: I haven't read it but does it define how to handle overlapping elements?<br> <dael> fantasai: aalreayd have to define. This increases border box fo hit testing w/o painting it<br> <dael> astearns: It does allow touch places to overlap where wouldn't notmally. Can do it with positioning but this is new overlap<br> <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<br> <dael> plinss: Want to make sure it's defined even if treated as overlapping [missed]<br> <dael> astearns: Yeah, this would be cool to have. Need somebody to write a proposal. Who would that be?<br> <dael> astearns: And spec?<br> <dael> fantasai: CSS UI 4<br> <dael> astearns: Who are editors?<br> <dael> smfr: [missed]<br> <florian> I am an Editor of UI-4<br> <smfr> s/smfr/florian me/<br> <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.<br> <dael> tantek: Not similar to other cssui properties.<br> <dael> tantek: I don't think we should burden cssui 4 without florian saying he can help<br> <dael> florian: I'm not opposed to idea but not committed to idea.This is hard, hit testing is hard<br> <dael> tantek: And people who have tried to spec hit testing have run away<br> <dael> fantasai: I don't think this is too hard. I'll take the action to make pr<br> <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?<br> <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<br> <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<br> <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?<br> <dael> tantek: Should be solvable with eisting markup<br> <dael> astearns: Whole problem is solvable with markup now but as author states it's unfortunate to change makrup to get hit testing<br> <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/<br> <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<br> <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<br> <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.<br> <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<br> <dael> myles: even on phsycial device can have larger resolution<br> <tantek> I'm suggesting a trinary<br> <tantek> per the shrinking use-case<br> <dael> astearns: We've had good discussion around length or bool. Let's engage issue poster on opinion between options and work from that?<br> <fantasai> +1 to astearns<br> <dael> tantek: I agree with sentiment<br> <dael> astearns: Okay, let's get back to Tyler. I'll ping<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4708#issuecomment-588337991 using your GitHub account
Received on Wednesday, 19 February 2020 17:20:03 UTC