[css-pseudo] Add stroke-color and stroke-width to the list of highlight properties

[dbates-wk]

It seems reasonable to amend https://drafts.csswg.org/css-pseudo-4/#highlight-styling to allow a web author to set stroke-color and stroke-width for a pseudo element.

[svgeesus]

Yes, it does

[fantasai]

We probably need to clarify that these properties only affect ink overflow, not layout overflow, then. :)

[css-meeting-bot]

The Working Group just discussed Add stroke-color and stroke-width to the list of highlight properties, and agreed to the following resolutions:

• RESOLVED: add stroke-color and stroke-width to the list of highlight properties
• RESOLVED: clarify stroke properties effect ink overflow and not layout

The full IRC log of that discussion

<dael> Topic: Add stroke-color and stroke-width to the list of highlight properties
<dael> github: https://github.com//issues/2362
<dael> Rossen: What do people think?
<dael> ChrisL: I agree they should be added, as I said on the thread.
<TabAtkins> +1
<dael> Rossen: Other opinions?
<dael> Rossen: Objections to adding stroke-color and stroke-width to the list of highlight properties
<dael> myles: Does stroke-width effect layout advances?
<dael> ChrisL: No, that's what fantasai added for clairification.
<dael> myles: When you highlight some tex with super big stroke-width it could go outside of the highlight?
<dael> ChrisL: Yes
<dael> fantasai: Yes.
<dael> myles: That's okay. Thumbs up.
<dael> RESOLVED: add stroke-color and stroke-width to the list of highlight properties
<dael> fantasai: We should also resolve that strokes add ink overflow not scrollable overflow.
<dael> myles: I thought that was the case.
<dael> fantasai: It's a separate resolution that they shouldn't apply
<dael> myles: So why not put that with the width property and not highlight styling.
<dael> fantasai: Ye, I think it's not clear.
<dael> Rossen: Prop: clarify stroke properties effect ink overflow and not layout
<ChrisL> +1
<dael> RESOLVED: clarify stroke properties effect ink overflow and not layout
<dael> dbaron: When do the properties effect anything when used on one of these highlight pseudo elements?
<dael> dbaron: Most of these pseudo elements style text. Does stroke by default apply to text?
<dael> fantasai: Yes.
<fantasai> https://drafts.fxtf.org/fill-stroke/ applies it to text
<dael> dbaron: Is that impl today or something you're imagining will work?
<dael> myles: Webkit is impl
<dael> Rossen: Edge shipped a long time ago.
<dael> ChrisL: There was a webkit specific property that did that which people used before standardization.
<dael> ChrisL: So it derives from earlier experience.
<dael> dbaron: Sure, Iw as worried pages would do unexpectedd things, but if edge is shipping that's not the case.
<dael> ChrisL: Initial value means you shouldn't get a surprise unles syou set it.
<dael> Rossen: And I don't believe there's much uptake on the web currently.
<dael> Rossen: Anything else on that topic dbaron or myles ?
<dael> myles: Not from me.
<dbaron> s/Webkit is impl/Webkit is implementing it/

[fantasai]

I was about to edit these resolutions in, but I'm no longer sure that stroke-width should be ink overflow, at least not in SVG. Ink overflow would be fine for CSS, where it's just text decoration, but in SVG it seems a little more fundamental, and maybe it should be layout overflow. And it'd be a bit weird to allow it for CSS but not SVG ::selections.

Also if we're doing stroke-color shouldn't we also be doing fill-color?

Agenda+ to confirm, would like to hear back from @AmeliaBR @smfr @svgeesus

[AmeliaBR]

I'm not sure that "layout overflow" is a meaningful concept in SVG. There's currently no way that a stroke size on one element can affect the layout of another rendered element, although it can affect marker sizing (Markers being "decorations" on the same element as the stroke property -- from a rendering-tree perspective they'd be like child content.)

Chrome already supports the stroke and fill properties on ::selection in SVG. (https://codepen.io/AmeliaBR/pen/VqMrPV) although not paint-order, which I would add to the list.

In general, selection styling and SVG is a mess, because there is no official support for background color on SVG text spans, yet it's still part of the default selection styles in most browsers. But that's a separate issue that shouldn't hold up these changes.

[frivoal]

I'm not sure that "layout overflow" is a meaningful concept in SVG.

In CSS, the key distinction is whether that overflow can trigger scrollbars (layout overflow) or not (ink overflow). That's just not a thing in SVG?

[AmeliaBR]

In CSS, the key distinction is whether that overflow can trigger scrollbars (layout overflow) or not (ink overflow). That's just not a thing in SVG?

Ah, I see. No, it's not a thing: SVG elements other than the document root currently never have scrollbars, and scrolling for the root element is defined by viewBox/width/height dimensions, not rendered content.

In SVG 2, we proposed adding scrolling mechanisms for certain elements, but never defined the exact dimensions of the scroller region. However, since only elements with defined width/height dimensions would get scrollbars, it would presumably follow the same rules. (https://www.w3.org/TR/2018/CR-SVG2-20181004/render.html#OverflowAndClipProperties)

[bradkemper]

box-shadow and border-image should also be added to the list.

[fantasai]

@bradkemper We can't add anything that would illustrate the boundaries of the selection area, since that's up to the UA (it's complicated, and not necessarily rectangular). So the list of properties we can add here is much less than “anything that doesn't affect layout”.

(Specifically, the list of requirements here are a) Doesn't affect layout b) Not dependent on the exact bounds of the highlight painting area c) Can be applied performantly in a highly dynamic environment--perf requirements are much higher for selection than CSS in general.)