CSS Stroked text
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 W3C CSS Fill and Stroke Module Level 3 Specification has the fundamental properties for stroke:
-
stroke-width -
stroke-color -
stroke-align -
fill-color
The paint-order property should be reviewed in this change also as it determines the layering of the stroke and fill. The other stroke and fill properties in the specification could be implemented separately.
Specification
W3C CSS Fill and Stroke Module Level 3 Specification.
web-feature
No response
Test Links
n/a
Additional Signals
Standards Positions
- Apple (Webkit): not stated
- Google (Chromium): unknown
- Mozilla (Gecko): unknown
Site Breakage and Workaround
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.
There are existing -webkit properties that are specified in the WHATWG Living Standard for stroke and fill. These are well supported, but have inconsistencies in the implementations. It can be difficult to get an accurate and attractive result with the -webkit-text-stroke property for stroked text.
Size and Current State of the Feature
Not implemented
Browser Bugs
n/a
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-stroke has 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
No impact envisaged.
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.
This comment was automatically generated based on the information you provided. Please don't edit it.
Below is additional information about the web feature (from the web-features project) which is referenced in your proposal.
If this doesn't accurately correspond to your proposal, please update your initial comment to include web-features: <feature-id>.
To find feature IDs, use the web-features explorer.
Feature Text stroke and fill (compatibility prefixes)
- ID: text-stroke-fill
- Name: Text stroke and fill (compatibility prefixes)
-
Description: The
-webkit-text-stroke-widthand-webkit-text-stroke-colorCSS properties set the thickness and color of text outlines. The-webkit-text-fill-colorsets the color within text character outlines. Both default to the text color. - Baseline status: Widely Available
- Docs: -webkit-text-stroke, -webkit-text-fill-color
- More information: See the web-features explorer
It's a little bit unclear to me what the intended scope is here. Are you looking for fixes to implementation bugs in the -webkit-prefixed properties, or implementation of the CSS Fill and Stroke Module Level 3?
If it's the former, do the existing web-platform-tests cover the bugs of interest? Looking at it, the coverage seems sparse, and most of the test failures seem to be about the interaction between text strokes and CSS Transitions/Animations. My sense is that without better test coverage this might not work as a focus area.
hi @jgraham
The intended scope is to implement the core stroke related properties. Ideally, you would implement the W3C CSS Fill and Stroke Module Level 3 Specification . The fundamental properties proposed are:
-
stroke-width -
stroke-color -
stroke-align -
fill-color
I am not dictating how you get there. There is a considerable overlap between the implemented -webkit properties based on the WHATWG Living Standard, and the properties listed above in the W3C CSS Fill and Stroke Module Level 3 Specification. What is in the browser now has been partially implemented and has been neglected. You can see it as a good start, or as something to skip. That is for InterOp to decide.
There is a general consensus that browsers should move away from -webkit prefixed properties. Improving what is there should be a step towards unprefixed properties in my opinion.
In general Interop focus area proposals benefit from being very specific about what they want to achieve. We expect to get more than 100 proposals, all of which need to be assessed for complexity, impact, etc. so they can be prioritized. That process is extremely time consuming, even when the proposals themselves are clear. Dealing with ambiguity makes this much more complex, especially as different participants might come to different conclusions about what the proposal is intended to cover.
So I think it would be very helpful to either narrow this proposal down to something specific. Or if there really are two possible paths here, to file separate proposals for each one.
@jgraham I updated the proposal to remove the ambiguity you mentioned
I think there are no WPT tests for stroke-width, stroke-color, stroke-align, and fill-color?
Chromium recently shipped paint-order (link) and the paint-order-001.html could be part of this proposal (mostly passes in all browsers; Firefox just has a wrapping difference).
Thank you for proposing CSS Stroked text for Interop 2026.
We want to let you know it was not selected to be part of Interop this year.
On behalf of the entire Interop team, thank you for submitting it for consideration. We got many more proposals than we could include in this year's project, necessitating some difficult choices. Please note this should not be taken as a comment on the technology as a whole, or our willingness to consider it for Interop in the future. We appreciate the work you put into your proposal, and would welcome your participation in future rounds of Interop.
Posted on behalf of the Interop team.