[css-color-adjust] Should forced-colors override border-image?

[tigt]

CSS Color Adjustment Module Level 1

I recently worked on a component library to make it play nice with Windows High-Contrast Mode, and I noticed HCM left its border-image styles untouched, which rendered some components visually inaccessible. I added the following CSS to fix the problem:

@media (-ms-high-contrast: active) {
  *, ::before, ::after {
    border-image: none !important;
    list-style-image: none !important; /* IE/Edge didn’t override this either at the time */
  }
}

Since border-image is specced to require a fallback border-style in order for the image to display at all (and I think Chromium patched their bug about that), it seems like it would be safe to include this as part of forced-color rendering.

I wrote some more about this at the time I encountered it:

• Writing CSS for High-Contrast Mode — what I thought when I encountered the problem
• High-Contrast Mode Styles tester pen — Reduced test case for properties I was suspicious of, like border-image, content: url(), and filter.

[css-meeting-bot]

The CSS Working Group just discussed . [css-color-adjust] Should forced-colors override `border-image`?, and agreed to the following:

• RESOLVED: forced-color does not override border-image

The full IRC log of that discussion

<dael> Topic: . [css-color-adjust] Should forced-colors override `border-image`?
<dael> github: https://github.com//issues/5469
<dael> Rossen_: For historic PoV we did preserve border-images as part of the forced colors
<dael> Rossen_: I think it's a valid expectation that forced colors don't override images for same reason why we fought to bring back bg images and added things like backing plate behind text
<dael> Rossen_: For similar reasons I think we can continue to allow images that are part of decorations like borders
<dael> Rossen_: Prop is forced-colors should not override border-image
<dael> Rossen_: Unless there's a new requirement or use case to provoke that
<dael> Rossen_: Not hearing anything
<dael> Rossen_: Prop: forced-color does not override border-image
<dael> RESOLVED: forced-color does not override border-image

[atanassov]

@tigt thank you for opening this issue. The above discussion with the broader CSS working group captures our consensus to keep the existing behavior of forced-colors, which is to not override border-image. The reason behind this behavior is similar to the reason we don't override background-image by setting it to a background-color. There is a lot of rich semantic information provided by background or border images and removing this degrades the user experience a lot. We tried to do that in early versions of IE and the results weren't good.

Hope this provides the additional reasoning you were looking for.

[fantasai]

@atanassov Did MSFT evaluate border-images separately from background-images? I imagine it's less likely for border-images to be used for semantic information.

[css-meeting-bot]

The CSS Working Group just discussed CSS Color Adjust.

The full IRC log of that discussion

<fantasai> Topic: CSS Color Adjust
<fantasai> github: https://github.com//issues/5469#issuecomment-707918323
<fantasai> TabAtkins: This is the only issue open to block us from CR
<fantasai> TabAtkins: we pinged you repeatedly for the answer, and no response
<fantasai> TabAtkins: So put it on the agenda.
<fantasai> Rossen_: Have some colleagues closer to the implementation, will tag them.
<fremy> fremy: wouldn't mind keeping the border image, just in case
<fantasai> Rossen_: hopefully close on this before the end of the week
<fantasai> Rossen_: horizontal review issue?
<fantasai> fantasai: We only have the one issue open. Horizontal review is done. We want to transition to CR, once the border-image issue is closed.
<fantasai> Rossen_: should we resolve provisionally, or resolve next week?
<fantasai> TabAtkins: up to the chair :)
<fantasai> Rossen_: Current spec doesn't override border-image?
<fantasai> TabAtkins: current spec calls for that I believe
<fantasai> TabAtkins: border-image is not on the list of properties getting overridden
<fantasai> Rossen_: That reflects current implementations. Don't see why we'd want to change it. Does anyone have a different opinion?
<fantasai> TabAtkins: We're not trying to resolve on the open question right now.
<fantasai> TabAtkins: Question is do we want to move to CR?
<fantasai> Rossen_: Current spec matches our expectations
<fremy> +1 to what Rossen_ said; also border-image is quite rare, it's tough to say why it's used because it can be creative
<fantasai> TabAtkins: Question is, do we want to resolve regardless of how that issue is resolved, or do we want to wait for that issue before deciding?
<tantek> q?
<fantasai> Rossen_: Currently we can proceed with CR. I will follow up with folks here today and have closing arguments in the issue by end of week
<fantasai> Rossen_: if we end up changing, let's handle it later
<fantasai> tantek: Is the issue linked in the draft?
<fantasai> TabAtkins: no
<fantasai> Rossen_: if we can't close this, put a link in there
<tantek> perhaps in the status section
<fantasai> Rossen_: OK, calling for provisional CR transition resolution
<fantasai> Rossen_: any last concerns to moving forward with transition?

[FremyCompany]

Now that a backplate is rendered under text, it's no longer necessary to remove images of any kind, so I would be in favor of keeping them, just in case they might carry semantics. border-image is quite rare, it's tough to say why it's used because it can be creative. Creative usages are difficult to predict.

[atanassov]

We had a chance to review the issue internally and wanted to confirm we are OK closing the issue without further discussion - per our provisional resolution from last call.

[SelenIT]

Since border-image is specced to require a fallback border-style in order for the image to display at all

Is it though? AFAIK, the latest edition of the spec implies that the border image area can be painted even when border-width is 0 or border-style is none (which implicitly sets border-width to 0), if border-image-width and border-image-outset together result in non-zero-sized box. This is expected by at least three WPT tests, and Chrome failing these tests is considered a bug which is being fixed now (the corresponding WebKit bug seems to be fixed already). Please correct me if my understanding is wrong.

[tigt]

Hm, that’s new to me. I must have meant without explicit setting of border-image-width and border-image-outset. A lot of border-image explainers on the internet warn against the implicit version, like MDN here:

Note: You should specify a separate border-style in case the border image fails to load. Indeed, this is required according to the specification, although not all browsers implement this requirement.

[SelenIT]

There was an issue about this some time ago, and, as far as I know, its resolution still stands true. So MDN should probably be edited to prevent further confusion (upd.: done).

[fantasai]

@atanassov The request wasn't for you to confirm that it was OK to close the issue. You were OK closing the issue when we took the original resolution.

The request was to justify why border-image should be treated the same as background-image here, given that (unlike background-image) they're only used for decorative images. You did not answer the follow up question in the comment that reopened the issue: “Did MSFT evaluate border-images separately from background-images?”

[alisonmaher]

There is special logic in the spec for handling background-image in Forced Colors Mode:

background-image computes to none unless the original value contains a url() function

Perhaps it would make sense to do something similar for border-image to override gradients.

(I could see the argument for overriding a url() in the case of a border-image since they're more likely to be used in a decorative capacity, although I'd also lean toward keeping those in case they carry semantics.)

[FremyCompany]

Additional food for thought: border-image with the fill keyword acts exactly as a background would, and could be used as such, so should probably be handled the same way.

without fill it's less clear, but maybe simplicity is good enough here

[fantasai]

@FremyCompany The main reason we keep background images is because they're often used to present content images. But I doubt that's true for border-image.

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust] Should forced-colors override border-image?.

The full IRC log of that discussion

<dael> Topic: [css-color-adjust] Should forced-colors override border-image?
<dael> github: https://github.com//issues/5469#issuecomment-919751233
<dael> Rossen_: My feedback before was we have not imple border-image override in the past and therefore never got feedback from authors. We have overwritten BG image in the past and got quite a bit of lover letters from users
<dael> Rossen_: For that reason we came back and introduced backplace and restored the images.
<dael> Rossen_: That's why my feedback last time is we're fine with current spec.
<dael> Rossen_: That is what I said that wasn't captured
<dael> Rossen_: Anything else to talk about here?
<dael> TabAtkins: What you said sounds opposite. Resolution in issue is forced-color does not override image. You appear to say you all did override and didn't get complaints?
<dael> Rossen_: Didn't override border image ever. Didn't get complaints. Overrode background image
<dael> TabAtkins: From perspective that no one said leaving border image was distracting. Don't know removing would cause problems
<dael> TabAtkins: Makes sense. Can keep current resolution
<dael> Rossen_: Anything else on it? If not we can close once minute spost