Xiaocheng: Still reading Matt's comment in the brainstorming thread, which is one minute old. ... My concern here is that the design is very centric to the behaviour of Chrome and Firefox and it might not work on Safari. The proponents also said that they do not expect Safari to implement. I wonder what this means. No interoperability?

Martin+Lola: Not really acceptable.

Lola: Anything from Safari on this?

(Tess says that this is not possible.)

Lola: Negative?

Martin: Interop is voluntary, but no point if there is no hope of interoperability.

Marcos: Igalia is implementing on Blink. Interesting that they didn't see WebKit as a problem.

Christian: This is tough. The use case (sort of) makes sense. Interest from implementers. Not having interoperability is not great.

Lola: There are CSS highlight things going on elsewhere. Firefox did something in the recent release; Firefox exposes this to a11y, but Chrome doesn't. Interoperability for this stuff is already called into question. To have a major browser not be able to implement might make this worse than better.

Matthew: There have been discussions about the semantics of highlights. This case is separate to those. These do need to be exposed to a11y. Like to +1 to Christian about the use case and an opportunity to improve a11y. The proposal might not work, but it is nicely consistent with other highlighting APIs, so it would be nice if it was possible.

Lola: Can we ask that they work with Safari? So that we get interoperability. The other highlight isn't necessarily the same feature, but because this is highlights in general, I'm concerned about lack of adoption from developers, because brittle features won't be used. Also, I'm not won over, just because developers want this. Need to consider the impact on users being inconsistent or negative.

Martin: That's what we do.

Lola: I'm not in favour of saying satisfied for this reason.

Matthew: We all want the problem solved, but we know that solving the problem would mean no interoperable solution. The issue that I've linked from my comment talks about Safari. That might be because their colours are fixed. Possibly something to do with system colours might provide a way to smooth this out. Right now we can't say that it needs to happen this way.

Lola: Does that help, Xiaocheng?

Xiaocheng: Are we going to suggest that they investigate other alternatives that are interoperable? Something like "we acknowledge the value of the use case"... There are good parts of the proposal. The consistency with other highlight pseudo-classes. How many of us thinks we should raise this non-interop concern.

(Virtually unanimous concerns with interop.)

Xiaocheng: I'll draft a comment with two points: the use case is legit and we like the consistency with existing highlight patterns BUT we don't like that this isn't interoperable.

Martin: What about Safari and the other highlights? Because if that has shipped, an alternative design here might make it impossible to have consistency across those highlight types, which is unfortunate.

Matthew: Think Xiaocheng has a proposed comment, looks good. Think we should post it.

Hadley: Up for doing that?

Matthew: Will post it.

Hadley: Give Xiaocheng credit when posting the closing comment.

Marcos: Probably not needed, TAG should speak as one voice.

Hadley: But we also shouldn't take work from others. Let's balance that.

Matthew: I'll need to look at this more. Touches on how browsers should present things to people. If Safari guarantees no contrast issues, question is if author provided styles and didn't use @supports, is this a problem? But don't want you to have to do that. I'll ask the CSS people.

Martin: We were talking about the response here. Not sure we need to get into details but I don't find response satisfactory. @supports isn't really for feature-detecting forever. I am overloaded with issues.

Matthew: Maybe Marcos? It changes the presentation. Would you need to use @supports? Maybe Safari would overload and ensure good contrast. If you don't, is it acceptable outcome?

Lola: I'd like to avoid getting in the weeds of these issues, there are 11 to get through. Let's assign and get into the weeds in the breakouts. Matthew are you OK being the only assiggnee to this?

Matthew: We'll need some CSS input. Do we want an associate specifically for CSS? Maybe Peter, but not sure how busy he is.

Hadley: Peter is unlikely to be associate given demands on his time, but he could probably help with an issue.

Lola: Unless we have a specific person in mind, we should move forward with people like Peter. Maybe we can ask Peter to look at urgent things, the rest we can split amongst ourselves.

Hadley: Other CSS-focused TAG alumns, Tess, Lea...

Matthew: Let's look at the other issues, I can be the only person on this for now.

Lola: I was looking at this earlier. Matt posted comment 2 weeks ago, no resolution. Asked them about Safari, they responded.

Matthew: They allude to it being detectable with @supports. But it overwrites what author does. So I'm not sure you acutally need to query it as an author. I think it's OK that Safari won't implement it because they don't need to.

Jeffrey: Concern in blink-dev thread is that this shouldn't be a feature.

Matthew: From a11y perspective I'd have to agree. But seems to violate cardinal principle that you don't tell browsers how to do their UI.

Jeffrey: We probably wouldn't standardize what happens. But if devs forget to do this, it's bad for users. So we should do the right thing for users

Matthew: Not sure I agree with this, but brainstorming: should you be able to impart a personality for this, like with a dark-mode? But maybe you shouldn't have to do that, UAs should do it for light-sensitive users. Could make same argument.

Lola: I have concerns from a11y perspective but haven't fleshed those out. There are a11y issues with highlight in general. If Safari UI is better for a11y,

Jeffrey: different from dark mode, that's the whole page, all colors need to work together. But this is one chunk of text. So browsers' problem is easier.

Matthew: I agree, just want to make sure reasoning is sound. It's about a small portion of content at one time. Bad if inaccessible. Not covering keyboard interactions, right? Cooperating iwth existing browser UX.

Dan: Yes

Matthew: So browser is doing most of a11y effort here. Just for colors...probably preferable for browser just to do it.

Lola: What's the concern? I'm using non-Chrome chromium browser, browser already does this. When I search, it highlights search text.

Dan: Bro2wser UI might have lack of contrast with site content.

Lola: We can rely on UA for this, but don't need to. Different from dark mode, but similar enough. If I control the design of the website, I want to control the design of things and make sure the colors work. Why would we want to default it to the UA?

Matthew: It takes control away if we say the UA should do it. It would also guarantee sufficient contrast. In theory user could change in UA settings, like a theme. With Safari you don't have the control of theming, but they provide a consistent and clear look and feel. You're taking control from the site in exchange for it being consistent across sites. You're relieving the developer of the burden to get the constrasts right.

Jeffrey: Dan also pointed out authors can attack users with this by disabling find on page, which is reason not to do this.

Lola: Do we want to resolve unsatisfied?

Matthew: I propose to draft comment that puts it to them, why not just expect UAs to do this? Plus other points we discussed. Would like to hear their response even if we disagree.

Matthew; I proposed a comment last week and had a response from Jeffrey. He is asking to substitute something. I am fine with changes he proposed. If you are happy with mine and Jeffrey's sugegstion, then I can post it. I put a link to it.

Lola: yes please.

Matthew: just did.

Martin: JEffrey's comment is to recognise the background colours.

Lola: I think this is fine.

Matthew: so I will post it.

Dan has been going back and forth on the blink-dev thread on this one.

Are devs asking for this because browsers are doing the wrong thing? If so, browsers can fix bugs. If not, then what are the developers needing from this.

Jeffrey: I suggest we just endorse Dan's feedback.

Martin: Interoperability ... depends what you're trying to do. If you meant to highlight the line instead of just the text, Safari won't do that.

Marcos: Might be platform-wide ability to do it.

Martin: Might be things you can't do with it, like override color. You've done a find, and there's color, and you can't override that. But could be the case that there's value in having Safari implement some of this, so when you do find-in-page, the website knows what parts are found, and do other styling around it.

Jeffrey: That sounds like a recommendation that Safari look harder at certain parts of the use case, in particular "highlight things around the match".

Martin: Or draw big arrows pointing to it.

Jeffrey: I think I just volunteered to draft a comment. Argh.