Re: FW: Pointer target size

On 02/11/2020 16:37, Alastair Campbell wrote:
>  > For target within target, this essentially makes it a minimum size 
> requirement (since the edge of the target is also the "opposite" edge of 
> sorts for the parent target).
> 
>  > If that's intentional / lucky side effect, it should be 
> documented/clarified as well.
> 
> Hmm, I'm not sure. The simple case (non-overlapping) is straightforward:
> 
> Two boxes, A and B. B is to the right of A, and there's an arrow from 
> the right edge of A, to the right edge of B.
> 
> But for the overlapping case that logic creates a minimum within the 
> larger target, but not the nested one. I think?
> 
> Box A is within Box B. An arrow indicating 24px goes from the right edge 
> of A to the right edge of B. A double-headed arrow is within box A with 
> a question mark.
> 
> We could accept that and keep it simple, or update to something like:
> 
> “The distance from each target’s edge to the to the furthest edge of any 
> adjacent target is at least 24 CSS pixels, and any nested target is at 
> least 24 CSS pixels high and wide, except when:”

Ah, turns out I misunderstood the original wording "the distance to the 
  closest edge of the nearest target on the opposite side is at least 24 
CSS pixels" - thought the "opposite side" was in reference to the first 
target, not the adjacent one. as in for each target's edge, go to the 
target's opposite edge, then start measuring from that to the nearest 
edge of the adjacent target (i.e. go through the width/dimension of the 
original target, and then carry on until you reach the adjacent target's 
closest edge".

Is that not what was intended? I'm lost now...

"closest edge of the nearest target on the opposite side" sounds 
eminently confusing. closest edge immediately makes me 
think...well...the edge closest to my first target. Hence I thought in 
the contained case, that closest edge is the same as the original first 
target's edge.

This wording is a bit of a brain twister, and very difficult to 
visualise as describing it in words becomes fraught with misunderstanding...

If the meaning isn't what I thought it was, then yeah, this would not 
magically make a minimum size for the contained target. But yes, it will 
essentially be pointless as an SC to prevent small targets contained 
inside a target.

I'd also start thinking how/if this can be applied to overlapping targets.

P
-- 
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Monday, 2 November 2020 18:17:10 UTC