i'm still unclear what that second part actually means in practice...how would I imagine a link on a single line? it's a bit cryptic

this also makes it confusing when considering targets that are fragmented on purpose somehow...would the "pretend it's all together" approach apply to them too?

ah, as you were, I see you answered this in the email

The second sentence about wrapping targets should not apply to target size because, by the definition of target, it is “a region” rather than multiple regions.

It should also not come up due to the inline exception.

however, are you re-applying this second sentence here in the PR? or am I getting confused?

It is applicable to focus-appearance, and yes, if the link were not wrapped, that's the size.
It is not applicable to target-size, both due to the inline exception, and because a target is defined as a region (not multiple regions).

This note is wrong. A 2px border around the perimeter isn't 2 * width + 2 * height. You're missing the corners in that. Instead its 2 * (width+2) + 2 * (height+2). And for a circle it's not 4𝜋 * radius. It's 2𝜋 * (radius+1) + 2𝜋 * (radius+2).

Wilco, the example is 2h+2w-4, not 2h+2w. You are measuring the internal width and height in your calculation, which I guess we should be clear on which way is correct. I thought that we had settled on the original form (2h+2w-4).

For the circle, you are saying the same thing, except perhaps making it less clear since you do part of the math. The perimeter of a circle is 2𝜋r (or 𝜋d as I learned it) so if we want to clarify the computation for different border thicknesses we should use 2𝜋r*border thickness. And again, we need to clarify if the border is inside or outside the circle itself.

I think that we might need to just mention that authors and evaluators need to start with the basic formula and make adjustments if the border extends beyond the bounds of the shape.

In my opinion, it makes no sense to count the actual pixels for a rectangle and therefore subtract the corner pixels, but for a circle take the theoretical pixels and subtract nothing. The actual pixels for a circle can deviate considerably from 4 x PI x radius, especially for small circles.

Hi Wilco,

See the comment above. Drawing the perimeter outside the component would lead to odd fails, by a few px.

Drawing it with 1px inside, 1px outside leads to the simplest calc as 2w + 2h - 4 and the outer of 2w + 2h + 4, giving total of 4w + 4h.

Drawing both pixels of the perimeter inside would be the most conservative, with the exact calc being 4w + 4h – 16.

does this need a new definition somewhere for "bounding box"?

probably something very high-level like https://developer.mozilla.org/en-US/docs/Glossary/Bounding_box (rather than that definition of "minimum bounding box" that used to be used for focus appearance)

Well, seeing as focus-appearance doesn't use that definition any more, I think we can re-use it here. The latest push includes that change.

I do think the definition on https://developer.mozilla.org/en-US/docs/Glossary/Bounding_box is quite nice and concise. also, not quite sure what "For components which wrap onto multiple lines as part of a sentence or block of text (such as hypertext links), the bounding box is based on how the component would appear on a single line." part of the minimum bounding box definition actually means/shakes out to, so if we ARE going with that definition, this may need some clarification

I agree that the Mozilla bounding box is definition seems sufficient. We have the wrinkle that our bounding box for hypertext is to based on the bounding box formed when linked text is unspooled to a single line.