Re: [csswg-drafts] [css-pseudo] Add stroke-color and stroke-width to the list of highlight properties (#2362)

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](https://www.w3.org/TR/2018/CR-SVG2-20181004/render.html#OverflowAndClipProperties) (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](https://codepen.io/AmeliaBR/pen/84c95eb4cd697f031f12487cbf239480), 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](https://drafts.fxtf.org/fill-stroke-3/) 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.

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2362#issuecomment-456253617 using your GitHub account

Received on Tuesday, 22 January 2019 02:52:51 UTC