[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.)

[bradkemper]

How is stroke color or width different? Wouldn’t the stroke show the exact bounds of of the highlight painting area? Wouldn’t that always be a merging of rectangles?

OK, border-image would be weird if the selection went around a piece of text that was taller than other things in the line, but box shadow and border-radius could still work. Apply the border radius before merging the rectangles. Do box shadow like a filter, and then knock out the shape.

Are filters disallowed because of performance?

[AmeliaBR]

Wouldn’t the stroke show the exact bounds of of the highlight painting area?

The stroke isn't a border/box stroke, it's a stroke outline around the individual text glyphs (or SVG shapes).

[bradkemper]

Oh yeah. Of course you are right.

[svgeesus]

Confirming that stroke-width should be ink overflow. Stroke, and markers, in SVG do not affect the geometry (which is the closest analog to "layout" in SVG), only the rendered result.

[fantasai]

@svgeesus Can you also confirm about whether fill-color should be handled the same way as stroke-color? :)

[svgeesus]

yes, I can :)

[svgeesus]

So the proposed list of additional properties is

• stroke-color
• stroke-width
• fill-color
• paint-order

and rejected candidates are

• box-shadow
• border-image

[AmeliaBR]

I'd recommend describing it as stroke and fill and their longhands (when such longhands are eventually supported) instead of the still-theoretical stroke-color and fill-color.

And if stroke-width is allowed, there is no reason to disallow the stroke dashing properties.

[css-meeting-bot]

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

• RESOLVED: Add stroke-color, stroke-width, fill-color and paint-order

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_: Discussed a number of times. Seems there's some agreement on the issue
<dael> Rossen_: chris do you want to take this?
<dael> chris: Been a bit of discussion. General consensus on properties. Suggestion that they're hte long hands. Support that
<dael> chris: We've pretty much worked out what this effects.
<dael> fantasai: I think we'll look for 2 resolutions. 1 to clarify these are only ink overflow and second is to make them usable with selection
<dael> chris: Agree with first
<dael> fantasai: Question about applying all long hands. One limitation we have here is we don't want anything that will expose bounderies of box rep. element.
<dael> chris: But owuld it? Someone suggested it would but that was fairly quickly shown to be wrong
<dael> fantasai: Then we're fine
<dael> Rossen_: Prop is add stroke-color and stroke-width, fill-color and paint-order? Is that the list?
<dael> chris: I think so. It's in the issue
<dael> Rossen_: I'm reading from issue. Making sure I'm not missing anything.
<dael> Rossen_: stroke-color, stroke-width, fill-color and paint-order
<dael> Rossen_: Objections to adding stroke-color, stroke-width, fill-color and paint-order
<dael> RESOLVED: Add stroke-color, stroke-width, fill-color and paint-order
<dael> chris: And the suggestion to add the long hands?
<dael> fantasai: My understanding from last time is they need to be properties that can be handled at a high performance level. Dashing and filter and fill images and these things...
<dael> chris: Dashing has nothing to do with filters or images. It's common in animations so can't say it's not performance
<dael> fantasai: Question is would impl be up to implementing that for selections
<dael> chris: If you lookin graphical editors there's martching ants and I've seen people use stroke-offset and stroke-array to get that
<dael> leaverou: That's commonly done
<dael> fantasai: I don't know answer, but I think impl need to say yes they're willing to impl
<dael> smfr: [missed] I'm okay with dashing here
<smfr> for webkit, dashing has some painting cost, but not serious enough to justify excluding it from this list
<smfr> i’m ok with dashing here
<dael> [everyone reads]
<dael> Rossen_: smfr is okay with dashing
<dael> chris: Other implementors?
<dael> Rossen_: I'll take that as a silent no
<dael> fantasai: Next question is what about paint servers and tiling images. Is that something impl want to do on selection?
<dael> Rossen_: Ooph
<dael> TabAtkins: That's backgrounds in css
<smfr> don’t want selection to trigger an image load
<dael> fantasai: CSS only allows color, not image
<dael> leaverou: Are background images not allowed for reason of showing element boundries?
<dael> TabAtkins: Probably. We got around the issue by only allowing 0 dimensional images, aka colors
<dael> chris: I think that's the same for border images
<dael> leaverou: I don't think even borders are allowed
<dael> fantasai: Right
<AmeliaBR> For stroke/fill images, the boundaries (in SVG, anyway) are always the boundaries of the full <text>, not the given span, so it shouldn't be affected by changes in selection span.
<dael> Rossen_: So, no on this one? Soft no? To be consistent with previous soft no or weak maybe?
<dael> fantasai: Stroke and fill will be based on geometry of element so won't expose border. I don't think it's that useful. prob better not to do them. If someone wants them in the future we can add
<dael> Rossen_: Easier to add then remove.
<dael> Rossen_: Let's not add for now. THere's enough feedback from silence and pushback that this isn't comfortable at the moment. When they're more widely used we can see if shorthands are warented.
<dael> Rossen_: Sound good?
<dael> chris: Okay
<dael> Rossen_: That's this issue

[smfr]

I'm concerned about adding stroke-width here. Changes to stroke-width affect visual overflow, and engines (at least WebKit) might have to run layout code in order to update visual overflow. I don't want to have to run layout when selection changes.

[svgeesus]

@smfr I understand the concern if that was the case, but see discussion above: stroke-width is ink overflow so should not affect layout.

[fantasai]

@svgeesus Affecting ink overflow might not affect layout or scrollable area, but it still requires some geometrical calculations to figure out what needs to be invalidated, so I think smfr has an important point here. Reflagging for discussion.

[AmeliaBR]

There seem to be a few different definitions being thrown around about what should or shouldn't disqualify a property for use with ::selection. And there are some confusions about how the existing SVG properties work. Some clarifications...

1) Layout overflow for scrolling region

As I mentioned above, element geometry & styles cannot currently trigger scrollbars in SVG. There have been proposals for allowing scrollbars on elements with fixed dimensions if their content overflows. The spec text (which is likely to be removed from SVG 2 for lack of implementation) didn't define what counted as scrollable overflow. If that is ever implemented, it may be preferable to include the stroke region. We may also in future want to add a way to auto-define a viewBox based on one of the content bounding boxes, such as the stroke bounding box, which would mean that stroke could affect layout. But those are both hypothetical future additions.

When it comes to strokes and scrolling layouts, however, we do have current implementations using -webkit-text-stroke on HTML text. Based on a quick test, it seems that no current browser triggers scrollbars for overflow created from strokes on HTML text. (Note: someone please confirm for WebKit; but I'm assuming it's the same as Chromium.)

BTW, Chrome & Edge support changing the -webkit-text-stroke properties in ::selection (with some issues in Edge, in that it resets the width to zero if you only change the color). Firefox doesn't support them as highlight properties.

2) Painting area and hit testing

All the following properties can affect the painting area, including the hit-testing region in SVG:

• stroke (switching from none to any other value)
• fill (likewise)
• stroke-width
• stroke-dasharray and stroke-dashoffset

Changing stroke or fill (or any of their proposed longhands, which do not include the existing stroke-* properties) between values that do not include none wouldn't change the paint region or the hit-testing region. But I'm not sure how that restriction could be applied to ::selection styles.

Based on the current spec for the stroke and fill longhands, I'm not sure if anyone's considered how the none value gets extended into the longhands. Specifically stroke: none and stroke: transparent are currently very different as far as hit testing goes but it looks like they are being expanded into the same longhands in the proposal.

3) Dynamic geometry of paint contents

For painting SVG text, scaling and positioning the paint source (e.g., patterns, gradients) is always based on the size of the <text> block, not on individual spans. So there would be no recalculating of the paint layer itself as a selection span dynamically changes. But the proposed longhands are based on background syntax, where images are positioned according to the individual span dimensions.

---

I am therefore tempted to suggest that any formal resolution should be deferred to the Fill & Stroke module, so that all the details can be thought through.

Which would mean that ::selection painting in SVG would continue to be an inconsistent and poorly defined mess. And the behavior of the still unstandardized -webkit-text-stroke and its longhands in highlight properties would continue to be undefined (but if Firefox decided to match the other browsers and support them in highlight styles, it wouldn't make anything worse).

Which is all unfortunate, but maybe not as unfortunate as locking in a standard without considering the details.

[heycam]

I just want to mention that @smfr's comment applies in Gecko too. Any time the stroke-width property changes, we perform a reflow to recompute the painted bounds of the element. (This won't affect the layout / position of other elements, but it's still work that must be done.) It's probably not super awful to reflow during selection dragging as the selection encompasses new elements with ::selection { stroke-width: ... } styles but it's not something we do now and it would be good to avoid if we could since currently updating for selection styles only require a repaint.

[svgeesus]

OK, it seems clear that stroke-width should be excluded here. I hadn't fully understood the intermediate class of operations between "causes reflow" and "just needs repaint of changed pixels".

[smfr]

@svgeesus—it's not "causes reflow" but "requires work to compute new ink overflow" where "work" is often the same code path used for reflow (aka layout). "just needs repaint of changed pixels" is "invalidate the ink overflow you've already computed".

[smfr]

@dbaron notes that changing text decoration also requires that you recompute ink overflow, so maybe we already need to deal with this.

[css-meeting-bot]

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

• RESOLVED: specify stroke-color and fill-color are accepted in highlight styles
• RESOLVED: add stroke-width to the set of properties

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#issuecomment-456253617
<dael> Rossen_: AmeliaBR wrote a nice long overview. This is back to the WG
<chris> q+ to agree it sounds like stroke-width should not be allowed
<dael> AmeliaBR: WE talked about this previously. Question is about which properties should be allowed on highlight pseudo elements like selection
<dael> AmeliaBR: Discussion last wek was disagreement about what factors should disqualify a property from that set. WE talked about if something would trigger scrollbars, but feedback from impl is there ar eperformance impacts from recall painting dirty boxes as styles change
<dael> AmeliaBR: First question is for the group- what should be allowed in a highlight style and what should be disqualified. From there we can look at specific properties
<dael> AmeliaBR: As far as implementations go, we're talking about properties that are defined for SVG but want to extend to all CSS style text. new fill and stroke spec is not finalized
<dael> AmeliaBR: Another thing to remember is selecting styles on svg text has lots of interop issues that go beyond this issue. Solving this will not solve all svg text.
<dael> AmeliaBR: Non-svg text I don't believe there are any impl that support fill and stroke as def in new spec. We do have impl of webkit prefixed version which has different syntax and relationship between the properties.
<dael> AmeliaBR: At the end of my comment I said I'm not sure we can make a decisio on fill ands troke b/c they're not specified. Should we address interop in properties that are impl? The prefixed ones that don't have a spec. That's the question worth asking
<dael> AmeliaBR: I outlined a bunch of questions without answers. Anyone want to jump in with an opinion?
<dael> fantasai: smfr webkit has stroke and fill for selection?
<dael> smfr: Don't recall, but I think we could easily
<dael> fantasai: My inclination is for the spec in current state I would go more restrictive for now and add more as requested. WE should do subset of what is impl plus spelling and grammar error. THat's why we have text decor and color
<dael> fantasai: Other properties in that list I don't know if they're problematic. I'm happy to include if impl want to impl, but if not there's no reason to put it in the spec unless someone asks.
<dael> fantasai: I prefer color, bg color, text decoration, and whatever impl want to implement
<dael> fantasai: Then we can consider what else we want to allow. A core set would be good
<dael> chris: I previously argued stroke-width, but I withdraw that.I would like to see stroke and fill if impl interest. Makes sense for fill
<AmeliaBR> https://codepen.io/AmeliaBR/pen/84c95eb4cd697f031f12487cbf239480
<dael> AmeliaBR: as far as what's impl, for SVG text all are supported I think. Haven't tested. That's ^ the test for prefixed ones
<dbaron> I think it's also worth trying to write down principles that lead to the choices -- I think one of those principles should be that anything that triggers scrollable overflow probably shouldn't be included...
<dael> AmeliaBR: Chrome and Edge support changing stroke-color and stroke-width. FF does now. Don't have safari
<dael> myles: Why stroke-width hard?
<dael> chris: Causes additional computation so it's not just damaged pixel repair.
<dael> smfr: Have to do layout to recalc visual overflow
<dael> chris: Also heycam|away from MOzilla said problematic
<dael> dbaron: Text decorations also require recomputing visual overflow
<dael> chris: True
<dael> smfr: We used to cheat, but they can project out
<dael> AmeliaBR: We're talking about selection b/c that's where performance comes in. BUt we're using same set of properties for all highlight pseudo classes so that also means spelling & grammar error. If we restrict from performance we might need to split the category so there's flexibility for things like highlighting spelling errors
<dael> dbaron: I don't know we're far enough along on interop on this that we're at that point
<dael> dbaron: I think it is worth trying to write down principles that lead to these choices. I think anything that triggers scrollable overflow should not be on this list. Discussing ink
<dael> smfr: THings that trigger resource loads?
<dael> chris: Def. disallowed. IF you're bringing a network transfer you don't want that
<dael> dbaron: Reosurce loads are async and you see something else in the interrum
<dael> florian[m]: I don't think that's much of a problem. Triggering network since async ins't
<dael> dbaron: Worry abotu background is we have to define background position for these
<dbaron> s/interrum/interim/
<dael> fantasai: Right, this is why I'm against background images. i think stroke and fill images are pinned to geometry of element box so wouldn't have same issue. We could do that for backgrounds in theory
<dbaron> s/abotu/about/
<dbaron> s/about background/about background images/
<dael> fantasai: For these images you don't want the to reset tiling on every element. As you highlight and there's a span it breaks the tiling. Id on't know how you fix that and make it consistent, but also give controls to author. For that reason I think don't allow images. unless geometry is tagged to what's in doc and not selection area, then we can consider it
<dael> fantasai: I can come up with definition pegged to document element or controllable by author, but not both.
<dael> smfr: I'm not sure original motivation of the issue was
<dael> daniel: For completeness. I didn't think this required a re-flow at the time. I was filling out for completeness
<dael> AmeliaBR: It's worth discussing b/c we have impl of webkit-text-stroke where some imple support it. There are different decisions out there. BUt that's not a prop in a spec. WE need to discuss properties in the spec and where should images be anchored when painting a span
<dael> fantasai: That's specified in the spec now. We had to get it right to make it useful. THere's a property to control that
<dael> daniel: I must have missed something. What are we trying to decide on?
<dael> fantasai: Wht is the list of properties for section 3.2. I'm happy to include stroke-color and fill-color. THat seems straight forward
<dael> AmeliaBR: Only difficulty there is currently the shorthand stroke property which is what's impl if you're switching color to none it's not defined how it effects the stroke-color longhand
<dael> fantasai: There is a definition in fill stroke spec. I think it doesn't quite match SVG and we created a shorthand/longhand relationship and we figured it was backwards compat on existing content
<dael> fantasai: We're going with fill stroke spec, it doesn't matter if it's shorthand it will reset the longhand. CSS expands and looks at longhand, doesn't look at shorthands. If author says stroke:blue it sets stroke-color:blue
<dael> AmeliaBR: So deciding which properties apply you can use stroke shorthand in the property and some parts will have effect and some not?
<dael> fantasai: Yeah. We ignore properties not supported
<AmeliaBR> s/in the property/in the ::selection rule/
<dael> AmeliaBR: I can't remember who said it, but we can start with the more restricted set and expland it
<dael> AmeliaBR: I think it's reasonable to say stroke-color and fill-color are acceptable in the highlight styles, implementation can extend that to prefixed similar properties if they choose
<dael> daniel: for right now just exclude stroke-width?
<dael> AmeliaBR: Yes since that seems the controversial one
<dael> daniel: I'm fine with that
<dael> AmeliaBR: I do think it's prob a good longterm strat to think about and outline the underlying principles for that set of highlight styles and what should be considered when allowing/disallowing styles.
<dael> AmeliaBR: NOt sure who wants that job
<dael> fantasai: Main principles is they can't effect layout, including scrollable. Can't trigger resource load (for now). Can in some cases trigger ink overflow b/c we've got text decoration in there
<dael> fantasai: Not sure how we want to deal with that
<dael> Rossen_: Should we take that later on and try to resolve on this issue?
<dael> Rossen_: There was some agreement around having stroke-color and fill-color participlate in highlight styles
<dael> Rossen_: Anything else we need before I call for objections?
<dael> dbaron: Summary of how our prop disagrees with current impl?
<dael> Rossen_: dbaron, We need to include it as part of the resolution? Or capture it someone?
<dael> daniel: I have a patch for webkit and I'm implemented itfor stroke-color and fill-color in that patch.
<dbaron> can you hear me now?
<dael> Rossen_: I just wanted to hear from dbaron
<dbaron> reconnecting
<dael> dbaron: I was saying I thought it was useful to understand what was going to have to change as a result of the resolution
<dael> Rossen_: Wasn't that it needed to be in the resolution, but it has to be clear in the issue what the effect of this is to the current impl
<dael> dbaron: Just like to know how far from current impl is the thing we're going to resolve on
<dael> Rossen_: Sounds like webkit is implementing. Blink?
<dael> AmeliaBR: I think the only issue is we do have impl that support the width effect which we're not including.
<dael> AmeliaBR: If there's any ones that don't...FF is only one that doesn't support stroke and fill color changes. But we're talking a mix of prefixed property impl. WE don't have impl of stroke-color as spec.
<dael> fantasai: We want to make sure there's a path to change from prefix to standard. If we have features in prefix we don't allow in standard we have to revise
<dael> fantasai: We can say stroke-width is supported, but ink overflow may not recalculate
<dael> florian[m]: Not sure what effect of not recalc would be
<dael> fantasai: Glitchy rendering
<dael> dbaron: Typically glitchy rendering at future repaints
<dael> Rossen_: Let's see if we can resolve
<dael> Rossen_: Are we ready to resolve?
<dael> Rossen_: Objections to specify stroke-color and fill-color are accepted in highlight styles?
<dael> RESOLVED: specify stroke-color and fill-color are accepted in highlight styles
<dael> fantasai: What about stroke-width. If it's supported in prefixed version, what do we do?
<dael> dbaron: Does it trim scrollable or only ink?
<dael> AmeliaBR: Only ink
<dbaron> s/trim/trigger/
<dael> fantasai: Which impl support webkit-stroke and fill for selection?
<dbaron> s/it/stroke-width/
<dael> AmeliaBR: Chrome and Edge. I assume safari, but I need someone to confirm using the codepen
<dael> Rossen_: We're certainly supporting
<dael> AmeliaBR: Edge doesn't support fill and stroke on SVG text, but FF does
<dael> Rossen_: Depends on version of SVG. In last one we released that should be fixed
<dael> fantasai: If it's webkit prefix it's strong enough compat that we're going to have support the functionality that maps to. Otherwise we don't give authors ability to transition out
<dael> fantasai: We need to figure out what the functionality is and put it in the list. What do other people think?
<dael> florian[m]: Reasonable to me, but I'm not an implementor
<dael> daniel: What's the question?
<AmeliaBR> Correction to my last comment: FF doesn't support selection fill & stroke on SVG text, either. Demo of selections on SVG text: https://codepen.io/AmeliaBR/pen/15e1dec9a9f1887c904adafca7589ff0?editors=1100
<dael> fantasai: First is if safari supports webkit prefixed stroke and fill properties in selection. Second is if webkit prefixed stroke-width is supported in selection, does that mean we have to put it in the spec? If we all impl under a prefix we should do it in the regular.
<dael> daniel: I'm looking
<leaverou> AmeliaBR: codepen seems to work in Safari (and has somewhat better rendering in fact)
<AmeliaBR> HTML strokes and selection: https://codepen.io/AmeliaBR/pen/84c95eb4cd697f031f12487cbf239480
<dael> daniel: We do support stroke-width
<dael> fantasai: Then we have to do it, regardless of it's a good idea
<dael> florian[m]: I think so unless other browsers have a good reason
<dael> smfr: Might mean selection is slightly slow/choppy because we're doing relayout.
<dael> fantasai: Or are you assuming you left space?
<dael> smfr: I'll have to check
<dael> fantasai: Adding stroke-width to spec or will browsers remove?
<dael> smfr: I don't think we'll remove.
<dael> dbaron: [missed]
<dael> Rossen_: User PoV it's better behavior
<dbaron> s/[missed]/I'm fine with adding it./
<dael> Rossen_: Objections to add stroke-width to the set of properties?
<dael> RESOLVED: add stroke-width to the set of properties