[svgwg] `text-overflow`: zero-engine support and spec inconsistencies: narrow or drop? (#1115)

karlcow has just created a new issue for https://github.com/w3c/svgwg:

== `text-overflow`: zero-engine support and spec inconsistencies: narrow or drop? ==
While reviewing implementer status for §11.10.2.10 (`text-overflow`), I found out a couple of issues.
The main question is whether SVG2's addition of `text-overflow` (§11.10.2.10 + entries in §6.6 and §6.7) should remain in the spec at all given that no engine implements the SVG-specific behavior.

### What the spec says

1. **§6.6 Presentation Attributes**: `text-overflow` is listed as a presentation attribute applying to **"Any element in the SVG namespace"**. <https://w3c.github.io/svgwg/svg2-draft/styling.html#PresentationAttributes>
2. **§6.7 Required Properties**: `text-overflow` (with a reference to css-overflow-3) is listed as a required property for SVG user agents. <https://w3c.github.io/svgwg/svg2-draft/styling.html#RequiredProperties>
3. **§11.10.2.10**: Defines SVG-specific behavior:
   - Effect triggers on a validly specified wrapping area (`inline-size`), **regardless of `overflow`**. This is an SVG-specific deviation from CSS, where text-overflow only applies when `overflow` is non-`visible`.
   - "The property does not apply to pre-formatted text or text-on-a-path."
   - "For all the DOM methods it is as if text-overflow was not applied, and as if the wrapping area did not constrain the text."

   <https://w3c.github.io/svgwg/svg2-draft/text.html#TextOverflowProperty>

### Empirical implementer status (2026-06)

Tested via WPT against Safari Technology Preview 244, Firefox Nightly 153, and Chrome Canary 150. 

I have test files locally under `svg/text/parsing/`, `svg/text/scripted/`, `svg/text/reftests/`, and `svg/styling/text-overflow-presentation-attribute-broad.html` that I can upload to WPT in case we have a resolution.

| Behavior | Safari | Firefox | Chrome |
|---|---|---|---|
| Parsing `text-overflow: clip` / `ellipsis` (CSS-OM) | ✓ | ✓ | ✓ |
| Computed value is the specified keyword | ✓ | ✓ | ✓ |
| `text-overflow` accepted as a **presentation attribute** on `<text>` | ✗ | ✗ | ✗ |
| `text-overflow` accepted as a presentation attribute on **any** other SVG element (`<rect>`, `<g>`, `<svg>`, `<defs>`, `<use>`, `<path>`, …) | ✗ | ✗ | ✗ |
| `text-overflow: clip` on overflowing `<text>` with a wrapping area actually clips | ✗ | ✗ | ✗ |
| `text-overflow: ellipsis` on overflowing `<text>` with a wrapping area actually renders an ellipsis | ✗ | ✗ | ✗ |

Source confirmation:

- WebKit: `Source/WebCore/svg/SVGElement.cpp` — `cssPropertyIdForSVGAttributeName` has no entry for `text-overflow`.
- Blink: `third_party/blink/renderer/core/svg/svg_element.cc` — the SVG-presentation-attribute list has no `kTextOverflowAttr`.
- Gecko: no SVG presentation-attribute mapping for `text-overflow`.

The rendering result needs to be read alongside `inline-size` status: `inline-size` on SVG `<text>` is also unimplemented in all three engines (the WPT tests at `svg/text/reftests/text-inline-size-00*.svg` fail everywhere). The WG already discussed this in [svgwg#1087](https://github.com/w3c/svgwg/issues/1087) and chose to keep `inline-size` on the basis that it should be relatively easy to implement.


The CSS property `text-overflow` does not in general require `inline-size` — it applies to block containers with a constrained width and `overflow != visible` — but the SVG2 §11.10.2.10 path specifically says the effect triggers on "a validly specified wrapping area", and §11.4 only defines those via `inline-size` / `shape-inside`. So in the spec's model, the SVG-specific path is coupled to inline-size; whether engines couple them the same way is open. The presentation-attribute parsing failure (Issue 2 below) is independent of this coupling and stands on its own.

### Spec issues to resolve

The first question is important: **do we keep `text-overflow` as an SVG-specific feature at all? Issues 2–5 only matter if the answer is yes.**

#### Issue 1. `text-overflow` rendering effect on SVG text is unimplemented anywhere (and not fully testable until `inline-size` ships)

§11.10.2.10's rendering behavior (clipping or rendering an ellipsis when text overflows a wrapping area) is **unimplemented in all three engines**. 
The interaction once both ship is also the tricky part: e.g. ellipsis placement when the text wraps to multiple lines *and* the final visible line still overflows.

Given the WG's existing decision to keep `inline-size` on the easy-to-implement argument (svgwg#1087), the symmetric option for `text-overflow` is reasonable. But the foundational question is still open: should §11.10.2.10 + the §6.7 required-property listing remain, or is the SVG-specific addition no longer worth the spec text?

Possible resolutions:

- **(a)** Drop `text-overflow` from §6.7 and remove §11.10.2.10. Authors would still get the CSS property's behavior on SVG content via the general "CSS applies to SVG" rule, with whatever scope CSS itself defines.
- **(b)** Keep §11.10.2.10 (parallel to the inline-size decision in svgwg#1087)
- **(c)** Keep as-is.

If the resolution is (a), Issues 2–3 below become moot.

#### Issue 2. *(if we keep it)* Presentation-attribute applicability is too broad and unimplemented

§6.6 claims `text-overflow` is a presentation attribute on **"Any element in the SVG namespace"**. That has zero implementations. Even the narrower claim (`text-overflow` as a presentation attribute on text content elements specifically) has zero implementations.

Possible resolutions:

- **(a)** Narrow §6.6 to list `text-overflow` only on the elements where it has any effect — i.e. text content elements (`text`, `tspan`; `textPath` is excluded by prose). Smaller ask of implementers.
- **(b)** Drop `text-overflow` from §6.6 entirely (leave it as a CSS-only property on SVG content). Authors would still set it via `style=` / stylesheet.
- **(c)** Keep the broad applicability and ask implementers to commit.

#### Issue 3. *(if we keep it)* "Pre-formatted text" wording contradicts the worked example

The prose in §11.10.2.10 says:

> The property does not apply to pre-formatted text or text-on-a-path.

But the worked example in the same section sets `text { white-space: pre }` on every `<text>` element and shows `text-overflow: ellipsis` working. If "pre-formatted text" here means `white-space: pre` content, the example is wrong. If it means something narrower (e.g. text-on-a-path, or multi-line-positioned text without a wrapping area), the prose needs to say so. Worth a one-sentence clarification.


I'm happy to draft a PR for whichever resolutions the WG agrees on.


Please view or discuss this issue at https://github.com/w3c/svgwg/issues/1115 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 2 June 2026 13:13:40 UTC