<Chuck_> scribe: Chuck

Silver decision policy update

<Rachael> https://www.w3.org/WAI/GL/task-forces/silver/decision-policy

<Chuck_> alastairc: Just to let people know, there will be a new CFC on this. There were a couple of issues raised in last CFC, needed to make edits. need to make another round.

<Chuck_> alastairc: Is there a dif?

<Chuck_> Rachael: No diff, I can paste in the sentences.

<Rachael> Two additions: Subgroup agreement represents consensus of the subgroup but only consistitutes a proposal to the working group.

<Chuck_> Rachael: One was to clarify about sub-groups. <reads sentence>

<Rachael> Participants who miss meetings are expected to read the minutes and raise objections to any decisions made within a week of the meeting. If participants will be out for more than a week, let the facilitators know so they can take this into account when considering objections.

<Chuck_> Rachael: 2nd part was under procedures, more clarification about when participants miss meetings <reads changes>

<Chuck_> alastairc: Unless we have any comments or concerns, now's a good time. It will come around for CFC fairly soon.

<Rachael> noting that we should likely change "working group" to "task force" in the first sentence

Meeting next week?

<david-macdonald> +1

<Fazio> +1

<DavidASx> +1

<Chuck_> alastairc: Next week's meeting, it's Thanksgiving next week. How many here are likely to attend?

<Caryn-Pagel> -1

<stevelee> +1

<Francis_Storr> +1

<Chuck_> +1

<morr4> -1

<Juliette_> +1

<sarahhorton> +1

<CharlesHall_> -1

<ChrisLoiselle> +1

<MelanieP> +1

<GN015> +1

<Chuck_> alastairc: Most would be here, we could get some useful stuff done. There should be enough of us.

<Chuck_> alastairc: We'll be down a few, but not too many. We'll run another call next week.

Target spacing https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/results

<Chuck_> alastairc: Back to target spacing, which has been through the most changes out of everything in 2.2.

<Chuck_> alastairc: In survey, question is to have a look at a new formulation, which is using lower number 24 css pixes, and a new formulation <reads>

<Chuck_> alastairc: ...that formulation was intended to get over some issues where it was focused on spacing, where you could shrink targets to pass. We are trying to not incentivize the shrinking to pass.

<Chuck_> alastairc: Instead we want a minimum size, either target or spacing. Also added an exception, that doesn't work if one target is within another target.

<Chuck_> alastairc: Looking at results... we have 2 agreeing, one thinks we should drop, and 4 think "something else".

<Chuck_> alastairc: MGower was saying if the material below could be 4th bullet.

<Chuck_> alastairc: It was added at the end because the 3 bullets are exceptions to conditions at top.

<Chuck_> alastairc: Having a minimum height and width only applies when it's enclosed, doesn't apply any other time.

<Chuck_> dm: When we say target inside another target, like an anchor inside another anchor?

<Chuck_> alastairc: It wouldn't be nested from html point of view, but a pause button inside a big play button... maybe on top of. It's visually within a larger component.

<Chuck_> dm: Maybe we should add that.

<Chuck_> alastairc: We have definition of target. Area of screen, regardless of html.

<Chuck_> dm: Went by me, might go by others.

<Chuck_> alastairc: Let's think about that one... we could go opposite way.

<Chuck_> francis: On visually thing, thinking about coding practices, whatever reason you have nested components, if we added visually it would clarify what we are talking about.

<Chuck_> alastairc: for each target, the visual distance? Something like that?

<Chuck_> dm: More the nested part.

<Chuck_> alastairc: Unless the target is visually enclosed within another target.

<Chuck_> dm: Or enclosed visually.

<Chuck_> alastairc: Need to review definition of target... it's a region of the display.

<Chuck_> alastairc: yes... we could do...

<Chuck_> dm: So many times I fail people for buttons inside buttons, links inside buttons.

<Chuck_> alastairc: This doesn't affect that one way or another. maybe we could make that more clear.

<Chuck_> dm: You'd think the relationship... in same sentence we refer to something html like...

<alastairc> Unless the target is enclosed visually within another target

<Chuck_> alastairc: I'm going to put in for myself....

<Chuck_> alastairc: is there a better word than "visually"? We'll start with that.

<Chuck_> dm: "presented as"?

<Chuck_> alastairc: possibly. Let's keep mulling and tackle some of the other things. MGower's other comment. Would parent target itself pass, is it considered adjacent during nesting?

<Chuck_> alastairc: I think in answer to mgower, the parent would not be having any measurement with nested target. would apply to adjacent targets to the parent, don't think there are any holes there.

<Chuck_> alastairc: from shorton: is the name still target size? Or are we talking target size, spacing, both? This introduces another measure.

<Chuck_> alastairc: Yes, we are trying to make it not necessarily requiring 24 pixes, but 24 pixels including spacing, that is testible, without incentive to shrink component to pass.

<Chuck_> shorton: That makes sense. Making SC confusing.

<Chuck_> alastairc: I can understand that. It's trying to make something non-confusing and also testable. It's tricky. Been through a few versions.

<Chuck_> alastairc: From mobile taskforce there was some push back from a prior "simpler" version.

<Chuck_> shorton: Maybe worth revisiting that. The neetness of the minimum vs. enhanced approach people are familiar with, because of things like color contrast. It helps with learnability.

<Chuck_> shorton: "oh, it's like color contrast". And addressing concerns about the 24x24. That is something that we can do within the understanding doc. Does that mean vertical menu's too? Things like that.

<Chuck_> shorton: sc that's well established, we do a lot in understanding docs to offer what is and isn't part of this calculation.

<Chuck_> alastairc: I don't know if we have anyone from mobile task force who remembers why we didn't do just size, and added size plus spacing...

<Chuck_> dm: There was a great reason for it...

<Chuck_> mgower: My recollection is you could get overlap with targets. If there's a measurement between edge of target to next, you could ensure no overlap.

<Chuck_> shorton: Is there another way to address this, rather than tangle up the sc? Put the clarifications in understanding doc?

<Chuck_> jake: is your question why we just don't have target size of 24 instead of area?

<Chuck_> alastairc: Yes. At the point where we are shrinking...

<Chuck_> Jake: Well, the best reason is that there are so much targets out there who are not accepted because they are in a block of text or sentence. Ones that do not have 24 pixels that...

<Chuck_> Jake: We might break half of internet. Whole intent was to not click on the wrong target. We've been back and forth so many times on sizing.

<Chuck_> Jake: Spacing, combinations. Breaks us apart every time. Minimum of 24 is just not achievable. That's the best reason from memory.

<Chuck_> Jake: There are a lot of clickable things out there that aren't 24 x 24. They will break instantly.

<Chuck_> alastairc: They wouldn't break, but they'd fail. Part of the equation, size OR spacing, a lot of those don't fail, because they have some spacing around that. That's my recollection.

<Chuck_> alastairc: There was some discussion on mobile task force on how that works. I was involved in this...

<Chuck_> alastairc: We did have a few examples. If you have 2 links, you are looking at... Link A and B next to it, in a typical sense, they wouldn't be overlapping. Nearest edge of A to furtherst edge of B.

<Chuck_> alastairc: Because you are measuring from nearest to furthest, easier to work out.

<Chuck_> alastairc: When overlapping, works in similar lay. If you have larger link with smaller link overlapping, you are still looking at size of box vs other box that's showing.

<Chuck_> alastairc: Trying to work through odd cases that brought us to that language.

<Chuck_> Shorton: By trying to address the odd cases, do we end up doing nothing? We can address odd cases in understanding doc? And still have guidance people can follow, for not odd cases? vertical menu is not odd case.

<Chuck_> Shorton: The only way we can do anything with this and others is saying that this is the minimum, and we recognize there are cases where it will be complicated. But follows 80/20 rule.

<Chuck_> Shorton: Getting caught up in the odd cases in the sc.

<Chuck_> detlev: I fear that we may be ridiculed for this language. It makes sense, I can follow this, but it's so convoluted, I don't know if we can get away with it.

<Zakim> alastairc, you wanted to say that we need to avoid the negative intentive

<Chuck_> alastairc: That's a count against that. To Sarah's point, I would agree with catching most cases and explaining each one in understanding, however if we have language we had previously...

<Chuck_> alastairc: normative text says you need this much between size and spacing, if you cram links into a space, you might end up with worse, and we need to avoid. in terms of plain language vs what we have now...

<Chuck_> alastairc: in terms of the measure, the simple one is "needs to be this size". But if you have language that will fail a lot of current things, we can't explain that away in understanding doc.

<Chuck_> gn: Several remarks, but at this point I'd like to mention one of the goals is to not add the space in the way it encourages small targets with smaller space. The way we are saying doesn't catch that.

<Chuck_> alastairc: That's not what the current text allows.

<Chuck_> gn: If you have a small target and large target, from edge of small to large, you are fine, but from large to small, it might fail. If you reduce target, increasing space... you end up with small target and comply.

<Chuck_> alastairc: I don't see that. I'm showing screen again. A and B. It doesn't matter how big A is. That distance needs to be 24 pixels regardless of size of each link.

<Chuck_> gn: Now imagine A was small. And closer, and B fails, doesn't achieve 24 pixels. Then you reduce B again, and put it further away from A, then you comply again.

<Chuck_> alastairc: The space is not shared, so it doesn't incentivize smaller target.

<Chuck_> gn: Should I paint and send? I can send it to group. Won't finish during call.

<Chuck_> alastairc: There are some good diagrams <looking>

<Chuck_> alastairc: <finds>. Language previously was having a width and height of 44 pixels. That 44 pixels can be shared between targets. When it is for each target that you need that distance.

<Chuck_> alastairc: Distance from B to furthest size of A as well... goes across same spacing. Could have a 10 pixel A, and a B... there's no incentive either way for a smaller target in space or a big target.

<Chuck_> dm: I will paint it, one has to see it.

<Chuck_> alastairc: If you can show it visually, I'll keep an open mind. Not getting it mathematically.

<Fazio> Don’t feel bad. My heads spinning too trying to visualize

<Chuck_> Sukriti: To have spacing or targets more spaced out, the incentive is not there. If not shared, it's not possible to have what's described. We went through exercise multiple times.

<Chuck_> detlev: Speaking to confirm, you are right it avoids the incentive to create smaller targets, you have to keep distance. I think it's theoretically sound, and best formulation we've found, but very difficult to understand.

<Chuck_> detlev: To put this as normative text and then explaining it, I haven't seen it.... wish there would be a simpler second sentence "this usually means...." And only for edge cases it would start working through the strange language.

<Chuck_> alastairc: We would traditionally put that in as a note at the bottom. If we come to the conclusion that this is a good approach that needs better language, we can try something in the top area that you suggest.

<david-macdonald> https://docs.google.com/document/d/1ejG_7yaCI2xbEPqFZCbJgqGuu_kplEMtsO-XYJVbTkg/edit?usp=sharing

<Chuck_> dm: Back in Jan I created that language from edge to far edge with 48 pixels. I liked it, but it made the rounds and got rejected. I understand the confusion it creates. In my mind it's the best way we can do it. Maybe take Detlev's suggestion...

<Chuck_> alastairc: I remember thinking "how can we do that...", and now having same reaction. Makes more sense now.

<Chuck_> alastairc: That's Sarah's comments. Not completely resolved...

<Chuck_> alastairc: I know Jake said our intent was for people to not make mistakes when hitting things. We've been through several intents. Trying to get to what's usable and feasible.

<Chuck_> alastairc: Distance to furthest side starts from where? Center? Closest edge? Answer, closest point of the target to the farthest edge of the adjacent target.

<Fazio> Manual dexterity impairments often accompany mental/cognitive decline

<Chuck_> alastairc: Do we need to update the wording to make that clearer?

<david-macdonald> My language back in January updated to 24..."For adjacent user interface controls, there is at least 24 CSS pixels between an edge of a control and the corresponding edge of any adjacent control on the axis of the adjacency, except when:

<Chuck_> Sukriti: I tried to simplify, "anywhere on the target", it leaves enough ambiguity. It should be anywhere from the target, it should be what we meant.

<alastairc> "For each target, the distance from anywhere on the target to the farthest side of each adjacent target is at least 24 CSS pixels, except when:"

<Chuck_> alastairc: Popping into IRC.

<Chuck_> awk: the tendency people will have will be to measure from closest spot possible, but maybe from farthest? We want to eliminate the measurements of convenience if they don't satisfy intent.

<Chuck_> alastairc: We are going on baseline. Does sukriti's language solve that for you?

<Chuck_> awk: I think so...

<Chuck_> alastairc: If we do agree, some diagrams would be in order.

<sukriti> I can do the diagrams

<david-macdonald> what about "corresponding edge of any adjacent control..."

<Chuck_> awk: This might be handled in understanding as well. There's a certain simplicity in the distance to furthest side. If we clarify that in understanding with a couple of images.

<Chuck_> awk: Reading in isolation, that question struck me. Sukriti's language helps, understanding clarification will help more.

<Chuck_> Shorton: Still wrapping my head around it. What if there is no adjacent control? Does this sc not apply?

<Chuck_> alastairc: essentially yes.

<Chuck_> alastairc: I realize that doesn't sound ideal, the original reasoning because this was coming around for touch screens, where small touch targets are difficult. The devices themselves will apply heuristics.

<Chuck_> alastairc: If you have small targets next to each other, you are more likely going to make a mistake. Less about a target size and more about preventing the errors.

<Chuck_> Shorton: So not target size, but target spacing.

<Fazio> Which is part of COGA Content USA le guise

<Chuck_> alastairc: It's about target spacing, but you could meet this with target size.

<Fazio> guide

<Chuck_> Shorton: Exceptions being same as target size sc, might be why I'm having some difficulty.

<Fazio> Content usable guide I mean

<Chuck_> alastairc: We have to be fair... flipped back between target size and spacing. In this case I think it's best to stick with target spacing.

<Chuck_> Shorton: I think I got it now.

<Chuck_> Wilco: Struggling with "anywhere" in this suggestion. It's really the closest one to the element right?

<AWK> The closest point is the most restrictive and hardest to meet

<Chuck_> alastairc: For each target, if you are measuring from a target to the furthest of the other target, it's going to be the closest point of the target.

<Chuck_> Wilco: Can we just say that?

<AWK> any other points are easier to meet

<Chuck_> alastairc: It gets wordier and less understandable. Suggestions are welcome.

<Chuck_> Wilco: Maybe let's put it out there and see who's confused.

<Chuck_> alastairc: Having a diagram will help. To be fair, like David's doc had several months ago.

<Detlev> "no point of the target should be closer than 24px to the far edge of an adjacent target"

<Chuck_> gn: I'm afraid when measuring from anywhere in the target then the sizes of both targets get in the measurement. Everyone will measure for compliance. Should be the outer edge closest to the adjacent target.

<Chuck_> gn: I sent a file via zoom.

<Chuck_> gn: Possible to share?

<AWK> Suggestion - For each target, the minimum distance from the target to the farthest side of each adjacent target is at least 24 CSS pixels, except when:

<Chuck_> alastairc: <retreiving>

<Chuck_> alastairc: <sharing>

<Chuck_> Wilco: she's right.

<Chuck_> alastairc: Trying to work out how A passes.

<Chuck_> awk: What's the width of A & B?

<Chuck_> alastairc: In this case top row A would be failing.

<Chuck_> gn: By wording of requirement, B would fail. A target fails if neighbor is too small.

<Chuck_> awk: The page fails.

<Chuck_> gn: acknowledged. But fails due to wording of SC.

<Chuck_> alastairc: The point we had before was that there was an incentive to shrink targets. I'm not seeing that here. One is failing, the other is more spacing?

<Chuck_> gn: You make the target smaller, have more spacing, and you pass. Small targets with larger space.

<Chuck_> dm: Just to deal with Sarah's concern. We could introduce a bit more complexity and introduce an "OR". Target spacing is 24 pixels "OR"....

<Chuck_> dm: Adjacency with corresponding edge... maybe is a bit too convoluted. I could show it to people.

<Chuck_> alastairc: I can pull it up on screen.

<Chuck_> alastairc: The ... it was the phrase "corresponding edge" that I struggled with. But the diagram is very similar.

<AWK> @mbgower, that works great for regular objects, but much harder if irregular

<Chuck_> dm: The "or", what's the reaction to 24 pixels OR.... introduce the rest of the sc.

<Chuck_> dm: You can meet this by having 24 pixels, and can ignore the rest. Keep size at 24.

<Chuck_> sukriti: I want to clarify, you can have small target sizes, but removes the incentive because space is shared. This is about the diagram.

<mbgower> @awk Fair enough. It also doesn't solve two large targets in close proximity

<Chuck_> alastairc: You have multiple targets with overlapping space. You can make smaller targets.

<Chuck_> gn: Image we can see the space is cut into halves for the targets. Only half the space counts. This would be fine. Then half the space counts for this target, the other half counts to the other target.

<Chuck_> gn: If you divide the space among the targets this is fine as well.

<Zakim> mbgower, you wanted to say what about 'For each target, the distance from the middle of the target to the middle of each adjacent target is at least 24 CSS pixels, except when:

<Chuck_> alastairc: Yes, but in previous language the space was shared, as in either could be used. We don't have a mechanism to say "you have half the space".

<Chuck_> alastairc: Distance from middle to middle...

<Chuck_> mgower: maybe between space and target size, but becomes very prescriptive.

<Chuck_> alastairc: ...was very attractive from a simplistic point of view.

<Chuck_> Shorton: If there have been discussions about having two SC's to address these different needs. One being target size and one being target spacing.

<Wilco> Did we look at distance between the two furthest edges?

<Chuck_> Jake: Yes we did discuss. Not so long ago, maybe 3-4 weeks ago. Because of everything we discussed today and year before, I don't recall, but there was another issue with the AAA 44.

<Chuck_> Jake: Where we have 2 separate ones. Yes we have discussed it, we rejected it for more than one reason, but would need to review minutes. Other issues popped up.

<Chuck_> alastairc: Difficult to remember the issues that came up.

<Chuck_> Sukriti: I like the suggestion of the "OR".

<DavidASx> +1 for Or

<Rachael> +1 to Or

<Chuck_> Sukriti: Offering the second portion as a good alternative.

<Chuck_> alastairc: "Should have a height and width of 24 css pixes", or go into some formulation.

<Detlev> May make it mote palatable..

<Chuck_> alastairc: At top of understanding have a diagram with lots of minimum 24 pixel sized targets.

<Chuck_> dm: There's no requirement to have 24 pixel 'x' at top. That would do it right, there wouldn't be anything adjacent. So that needs to be 24 pixels. I like the idea of the 'or'.

<Chuck_> alastairc: I think you are right the first time, if there's nothing adjacent you meet the 'or'. It would have to be an 'and' condition to eliminate the tiny thing with no adjacency.

<Chuck_> dm: Not having adjacency means what?

<Chuck_> alastairc: If it's an 'and' then ... you'd have to have a formulation to have size or spacing, but that doesn't seem to make sense.

<Chuck_> alastairc: I think we've been through everyone's comments.

<Chuck_> awk: not quite. The last part of mine... about what we're going to do with regards to mobile apps with a WCAG2ICT update.

<Chuck_> alastairc: You are thinking while that fails it's a problem? Or there's an exception for that feature?

<Chuck_> awk: I don't know, we could say this only applies to the web, but that would be counter to what we are trying to address. Small screens. I don't know. maybe the answer is that this doesn't pass.

<Chuck_> awk: I see that on IOS, you can also scroll through dozens of contacts in order to get to the same point, but the benefit of the control is you can go to the 'z' part of it, and you don't have to swipe the screen many times to get to the bottom.

<Chuck_> alastairc: Or it's treated as one control that acts as a slider.

<mbgower> divider controls are also going to be challenging to pass this

<Chuck_> awk: Want to make sure we are thinking about that.

<Chuck_> awk: I end up thinking about what that means on various platforms.

<Chuck_> awk: There are a lot of small controls out there, and not a lot of room on those devices.

<Chuck_> awk: Maybe that goes to asking for public comment.

<Chuck_> awk: I don't have a solution, just a compelling question.

<Chuck_> alastairc: Having gone through wide review, we didn't get much push back on feasibility or achievability.

<alastairc> arg, power cut??

<alastairc> Powrrcut

<alastairc> scribe: sukriti

awk: we tend not to get feedback before finalized
... 2d sliders, datepicker

<Wilco> https://codepen.io/wilcofiers/pen/bGeJpVW

wilco: there is no requirement of the size of the element?

aliastar: effectively failing the adjacent target

awk: suggested some text sometime back.

<AWK> For each target, the minimum distance from the target to the farthest side of each adjacent target is at least 24 CSS pixels, except when:

alaistar: same as failing the adjacent target

awk: page fails, not the targets per se

<david-macdonald> I like this better than mine

<Detlev> Sukriti: Might datepicker qualify as essential?

<Chuck_> sukriti: commenting on date picker and other exceptions, those COULD qualify under essential?

<Chuck_> sukriti: The minimum and at least might be redundant. We could do away with one or the other.

<Detlev> "no point of the target should be closer than 24px to the far edge of an adjacent target"

sukriti: minimum or at least redundant
... date picker etc. might be essential

ac: if achievable with scrolling, will undermine essentiality

<david-macdonald> replace "should" with "is"

<alastairc> For each target, no point of the target should be closer than 24 CSS pixels to the farthest edge of an adjacent target, except when:

<alastairc> For each target, no point of the target is be closer than 24 CSS pixels to the farthest edge of an adjacent target, except when:

<david-macdonald> delete "be"

ac: new language failing the target itself, even though more complicated

wilco: flip the direction to fail the smallest thing?
... every point of the target is at least 24 px from closest pixel of the adjacent?

<alastairc> For each target, every point of the target is at least 24 CSS pixels to the farthest edge of an adjacent target, except when:

ac: what if the target is filling up the space?

<alastairc> For each target, the furthest edge from an adjacent target is at least 24 CSS pixels, except when:

ac: Wilco's point is if we're testing A, we should try to measure A

<GN015> I sent an enhanced version of the image in the zoom chat (with measurements for size and spacing)

Rachael: We're actually measuring the relationship between two items and not the individual items

https://docs.google.com/document/d/1_EHFVE-p4jEtKFa2jMEUruSvu6iv-Vt7UxRW9SrHTCQ/edit#heading=h.ez5cwti49sai

<alastairc> For each target, the furthest edge from an adjacent target is at least 24 CSS pixels from the nearest edge of the adjacent target, except when:

gundula: still not ok with it because incentive to smaller targets

ac: not allowed shared spacing removed incentive
... intent to hit the wrong target

is reduced

detlev: point is that even if small targets exist they need to be separated enough to avoid hitting the wrong one

DF: it makes it less of an issue if there are smaller targets for people with dexterity limitations

<Fazio> The size is the lesser of the evils between size n space

DF: tapping with bigger than the size of the target in most cases

Chuck: is it making larger targets fail by making them smaller?

AC: original language said area of 44X44 with just one target. That's when there were concerns about incentivizing smaller size due to shared spacing

<alastairc> For each target, the furthest edge from an adjacent target is at least 24 CSS pixels from the nearest edge of the adjacent target, except when:

AC: In the current formulation, bigger targets are not penalized

dm: adjacent - which one is it referring to?

<AWK> replace "the adjacent" with "that"

<david-macdonald> For each target, there is at least 24 CSS pixels between any point of the target and the furthest edge of any adjacent target...

<Chuck_> sukriti: There's some consensus around previous language. We are talking about...

<Chuck_> sukriti: If prior language was clearer... maybe we can keep that.

<alastairc> For each target, the minimum distance to the furthest side of each adjacent target is 24 CSS pixels, except when:

awk: latest language requires 1 adjacent target, not all

sukriti: since we're talking about adjacent targets anyway, could we keep the previous version

<david-macdonald> For each target, there is at least 24 CSS pixels between any point of the target and the furthest edge of any adjacent target...

awk: two 'each' that need to be clarified

<alastairc> For each target, there is at least 24 CSS pixels between any point of the target and the furthest edge of any adjacent target, except when:

<david-macdonald> For each target, there is at least 24 CSS pixels between any part of the target and the furthest edge of any adjacent target, except when:

<david-macdonald> @Wilco I changed "point" to "part"

<sukriti_> wilco : what about the case when one is surrounding the other?

<alastairc> Unless the target is enclosed within another target, where it has a minimum height and width of 24 CSS pixels.

<sukriti_> ac: the last bit covers the case where this happens

<alastairc> For each target, there is at least 24 CSS pixels between any edge of the target and the furthest edge of any adjacent target, except when:

<sukriti_> ac: edge instead of point?

<sukriti_> dm: that works

<sukriti_> wilco : this is again flipping the measurement to measure the size of the adjacent target

<sukriti_> ac: still looking at the original target but failing that one

<sukriti_> wilco : could be failing a 44X44 for adjacent smaller than that

<alastairc> For each target, the furthest edge from an adjacent target is at least 24 CSS pixels from the nearest edge of the adjacent target, except when:

<sukriti_> ac: this one has the original target failing

<sukriti_> ac: more wordy and harder to parse

<sukriti_> ac: ambivalent about which one

<alastairc> For each target, there is at least 24 CSS pixels between any edge of the target and the furthest edge of any adjacent target, except when:

<sukriti_> ac: formulation that has been clearest

<sukriti_> ac: anyone feel strongly enough to go back to the previous versions?

<alastairc> For each target, the furthest edge from an adjacent target is at least 24 CSS pixels from the nearest edge of the adjacent target, except when:

<sukriti_> wilco : this feels wrong

<sukriti_> detlev: from any point of the target is simpler

<sukriti_> ac: wilco's point there is failing of elements adjacent and not the one we're looking at

<sukriti_> detlev: what's the problem with that since we're looking at the interplay between targets anyway?

<sukriti_> thank you Chuck

<Detlev> I also thin haviong each adjacent target twice in the formulation invites confusion...

<sukriti_> gundula : seems hard to understand

<Wilco> Suggestion: For each target, there is an edge that is at least 24 CSS pixels away from the closest edge of its adjacent targets, except where

<david-macdonald> For each target, the edge of this target that is furthest from an adjacent target is at least 24 CSS pixels from the nearest edge of the adjacent target, except when:

<alastairc> For each target, the edge furthest away from each adjacent target is at least 24 CSS pixels from the nearest edge of that adjacent target, except when:

<sukriti_> gundula: prefers the older version

<sukriti_> thank you

<sukriti_> leaving now

<Chuck_> alastairc: <contemplates the various examples>. Might need to go to closest edge of each adjacent target.

<Chuck_> Wilco: Sure.

<Chuck_> alastairc: Just put numbers on these. We've got...

<Chuck_> scribe: Chuck

<Chuck_> alastairc: We've got a version which is measuring the adjacent target, a version which is... Wilco's abstract but makes sense to me.

<Chuck_> alastairc: We've got a version which is...

<Chuck_> gn: Afraid that most recent wording <reads>...

<Chuck_> gn: The edge furthest away is one defined edge with maximum ... to teach adjacent target. You look at one target, one adjacent target... not expressed here. From each adjacent target qualifies the edge.

<Chuck_> gn: First you choose an adjacent target, then you choose the edge from which to measure.

<Chuck_> alastairc: Can we just say... nevermind.

<Detlev> "Any point of a target must have at least 24px distance from the farthest edge of each adjacent target"

<Chuck_> detlev: Paste an alternative ...

<Chuck_> dm: Any edge there...

<Chuck_> detlev: You don't need edge. If it's farther away, you have those 24 pixels. Since any point has to meet it, you take the closest point.

<Chuck_> alastairc: So whatever is closest to the furthest edge.

<Chuck_> detlev: Exactly. I struggle with the other formulations.

<Chuck_> dm: This formulation fails if the adjacent target is too small.

<Chuck_> wilco: You can take the bottom right corner and measure to the top left corner, and get greater distance.

<Chuck_> detlev: You would always look for the point that is closest. You must not have any distance which is closer. It doesn't matter if you take the corners...

<GN015> Another suggestion: For each target, for each target adjacent to it, the edge furthest away from the adjacent target is at least 24 CSS pixels from the nearest edge of that adjacent target, except when:

<Chuck_> alastairc: I will try and put these into a doc or email, send to group, and mention negatives on each one and see if we can narrow down to one.

<david-macdonald> 4 seems to do it for me

<alastairc> For each target, the edge furthest away from the adjacent target is at least 24 CSS pixels from the nearest edge of that adjacent target, except when:

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Yes.  Point/Yes.  At the point/
Succeeded: s/dm's only/latest language/
Default Present: alastairc, Chuck_, MichaelC, CharlesHall_, Fazio, david-macdonald, Rachael, Francis_Storr, Juliette_, ChrisLoiselle, stevelee, Caryn-Pagel, MelanieP, matt, orr, sarahhorton, Laura, Detlev, mbgower, Wilco, sukriti, kirkwood, DavidASx
Present: alastairc Chuck_ MichaelC CharlesHall_ Fazio david-macdonald Rachael Francis_Storr Juliette_ ChrisLoiselle stevelee Caryn-Pagel MelanieP matt orr sarahhorton Laura Detlev mbgower Wilco sukriti kirkwood DavidASx GN015
Regrets: JakeA JustineP GlendaS
Found Scribe: Chuck
Found Scribe: sukriti
Inferring ScribeNick: sukriti
Found Scribe: Chuck
Scribes: Chuck, sukriti

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)