thebabydino
commented
2 weeks ago From the LogRocket article:
In Chrome (Linux), it appears that the
paint-orderproperty is ignored
FWIW, I'm on Ubuntu and I've been playing a lot with both -webkit-text-stroke and paint-order this year and I have never seen paint-order being ignored in Chrome. And the CodePen demo it links to looks fine and not like in the screenshot in the article. The article is dated April 2023, so sometime between then and early this spring, this must have been fixed. Also, it's not clear to me what the Firefox problem with paint-order may be. Seems to work fine to me - am I missing something?
That being said, there are lots of problems with CSS text stroke.
- stroke corners don't look the same in all browsers (sometimes they look broken)
- depending on the font, strokes may get weirdly painted over the fill, not just along the letter outlines
- interaction with
text-shadowis weird
Detailing the above with examples/ screenshots/ live links.
Stroke corners don't look the same in all browsers. In Firefox, the outer angle stroke corners get rounded, in WebKit browsers they don't.
The example below (live demo) uses an SVG filter for a more interesting effect, but the double stroke is created with -webkit-text-stroke. The inner half of the stroke is its inner half overlapping the letter fill, while the outer half is its outer half that's outside the text fill. What I'm doing is using a semi-transparent stroke, extracting its inner and outer halves separately via a feColorMatrix and then painting them differently. You can see the outer angle stroke corners are rounded in Firefox, which looks really weird.
But they aren't for Chrome - compare the inside of the 'N' and 'W' letters.
Here's another example (live demo) - it's less obvious here since the strokes are thinner, but you can still see it - the outer angle stroke corners are rounded in Firefox and it's particularly obvious inside the letters 'W', 'A' and 'M'.
But they aren't in WebKit browsers. Look inside the letters 'W', 'A' and 'M' - there's a bevel, not a rounding.
As weird as the Firefox rounding looks, it can look better than what Chrome does at corners for certain fonts. See the example below, using the same semi-transparent stroke + SVG filter tactic. Live demo.
If you can't see it, here are problem areas for Chrome zoomed in and with circles around them.
Firefox avoids the problem by rounding the corners.
Safari has SVG filter tiling issues, but does so much better than Chrome when it comes to those stroke corners.
I've filed Chrome bug 🪲 341319152 about this, but got marked as a duplicate of bug 🪲 40944554 that got marked as WONTFIX. ¯_(ツ)_/¯
Strokes may get painted across the inside part of letters, not just along their outline for certain fonts (which includes most cursive fonts). paint-order can help hide the problem by putting the fill on top of the stroke, but it doesn't fix it and sometimes I want to have a semi-transparent stroke on top of the fill for that double stroke effect.
I came across this while wanting to recreate this Dribbble shot. I ended up using a font that doesn't have the same vibe - live demo.
But the problem isn't limited to cursive fonts. Just set a text stroke to all Google Fonts samples to see what I mean.
This makes a lot of fonts unusable with -webkit-text-stroke.
Interaction with text-shadow is weird. text-shadow is drawn relative to original unstroked text. So if you set a text-shadow and also a text stroke, the shadow gets drawn under the stroke.
robole
Description
A stroke is a border drawn along the outline of a letter.
It can be used to create a range of beautiful aesthetics:
The existing "nonstandard"
-webkitproperties that are specified in the WHATWG Living Standard have inconsistent implementations. They are:-webkit-text-stroke: this is the shorthand property for the following 2 properties,webkit-text-stroke-width,webkit-text-stroke-color,-webkit-text-fill-color.There is the W3C CSS Fill and Stroke Module Level 3 Specification that covers the same properties . The fundamental properties proposed are:
stroke-widthstroke-colorstroke-alignfill-colorThe
paint-orderproperty should be reviewed in this change also as it determines the layering of stroke and fill.The other stroke and fill properties in the specification could be implemented separately.
It is your decision if you fix interop issues for the "nonstandard" WHATWG Living Standard spec or shift towards the "standard" W3C CSS Fill and Stroke Module Level 3 Specification. The work will be complementary in the long-run.
Specification
WHATWG Living Standard, W3C CSS Fill and Stroke Module Level 3 Specification.
Standards Positions
Site Breakage and Workaround
The existing
-webkitproperties that are specified in the WHATWG Living Standard for stroke and fill are well supported, but have inconsistencies in the implementations. It can be difficult to get an accurate and attractive result with the-webkit-text-strokeproperty for stroked text.It is more common to embed a SVG or image in a webpage of the text for this instead. See IMDB Top Series of 2022 example in the screenshot below.
Size and Current State of the Feature
The existing "nonstandard"
-webkitproperties enable specifying the width and color of a stroke for text content, and its fill color. The-webkit-text-strokeproperty is currently supported by approximately 96% of modern browsers.Depending on the font and property combinations used, the stroke can be drawn with mistakes. Stroke corners don't look the same in all browsers. See bugs below.
The
paint-orderproperty controls the layering of the fill and stroke. It had issues. In Chrome on Linux, I encountered an issue using the property in the recent past, but it appears to be OK now. There is a Firefox bug related to this topic.You have no control of stroke alignment. This would make a major difference to outcomes.
Without consistent results, you are unlikely to want to use a stroke and fill together. If you use a stroke without a fill (transparent), results are much better.
Browser Bugs
There are web platform tests for -webkit prefixed filling/stroking.
Here are the specific bugs that I could find, but I have a feeling that they may be more.
Chromium bugs:
-webkit-stroke-textresults in wrong text-decoration colourtext-stroke, and therefore the propertypaint-ordercannot be applied to the::first-letterpseudo elementMozilla bugs
Developer Surveys
In the State of CSS 2023, one of the top answers to the question, What features do you feel are currently missing from CSS altogether? is "SVG-in-CSS". This covers support for SVG syntax inside CSS, of which stroke and fill properties are fundamental.
Other Developer Sentiment
The Chrome Platform Status shows that usage of
-webkit-text-strokehas doubled in the last 2 years despite its shortcomings.The article - Can you create beautiful stroked text in CSS? - outlines some of the opportunities to use stroked text on the web, and the limitations of what currently can be achieved.
Likely Compatibility Impact
It is unlikely that it would cause any compatibility issues. Effort mostly involves improving interop of existing features, or implementing new, proposed properties.
Platform Impact
The implementation of stroked text will allow developers to implement more imaginative designs. What is possible in design tools regarding stroke and fill is not possible in CSS. This can be a point of contention between designers and developers. Currently the caveats and limitations with implementing designs involving stroked text is offputting. Designs that are commonplace in print media, are quite rare on the web.
It will be an improvement for accessibility if standard HTML elements are used for stroked text rather than SVG. People often forget to consider accessibility issues when embedding SVG documents in webpages.
It will be an improvement for internationalization. People often forget to consider text embedded in SVG documents.