Re: [svgwg] Implementing CSS Text Wrapping in SVG (#942)

As mentioned in another post I'm all in for a soon finalization for the SVG 2 spec from a user/dev perspective. 

However, the lack of a proper multiline-concept is still a huge bummer (ideally it should have been implemented from the start but obviously it's more obvious in hindsight)

1. What can we do as developers to support you? 
E.g providing examples or polyfill ideas for unsupported newer features.
2. How can we users/devs help to endorse a higher prioritization?   
Not asking for CEO's contacts but if there are slightly more effective open channels than the usual feature requests ones  ... I'd appreciate any advice.  

@shepazu: you mentioned the popular Electron apps which *could* provide full-blown CSS parsing capabilities.  
But as mentioned by @martinmolema we (as devs) also have to deal with headless environments such as node.js or even web workers.  

While we have existing excellent CSS parsers – again I must object that CSS parsing is not more complex than SVG attribute parsing.
In my experience as a graphic designer and dev, graphic applications clearly tend to implement only the most basic CSS property support (and lousy svg imports/exports ...).   So let's focus on the browser vendors.  

While I trust the experience of working group members with regards to implementation »likability«

We still have quite a few presentation attributes that can't be replaced by CSS properties such as:
* `pathLength` – commonly used for diagrams pie charts
* `points` – not your fault but not comprehensible why we cannot define a `points` property – would be handy
* `offset`(gradient) – it is quite unfortunate that we have a CSS property with the same name for something completely different (offset/motion paths ... the fact that this prop was renamed and offset is probably the most ambiguous name doesn't help)

My point is, from a dev perspective – I would consider the presentation attributes to be the better bet to create a self-contained SVG. 
Or at least I cannot agree with the roadmap to prefer CSS properties for future/not-yet-implemented features.

This is admittedly highly subjective but  providing a SVG multiline text concept relying on CSS  `inline-size`  feels not ideal as it introduces a »mishmash« of features you can be achieved with attributes alone and others that require CSS. I probably have missed some already existing issues.  

### Suggestions
Since introducing new SVG attributes is usually rejected – why not take existing ones such as `width` and maybe `display`.

#### width for maximum line-width
For instance SVG 2.1/3 *could* allow a `width` attribute for `<text>` elements.  
Older (or dumb) applications would ignore it

#### display for slightly more convenient predefined line-breaks
Sure we can use `<tspan>` elements for emulated line breaks and we have the white space contextual line-break concept already working in Firefox. For the latter since most visualization API's or graphic applications return messy SVG output a minification via tools like SVGO is often mandatory – usually stripping white space so relying on white-space seems to be a bit wobbly as a candidate.

However, copying the blocks `x` values and adding `dy` is also quite inconvenient. 
Maybe, SVG could allow(repurpose) other display modes such as `block` to force a line break (or emulating a tspan with the x coordinates of the parent text element)

```
<svg viewBox="0 0 100 100">
  <text x="0" y="50">
    <tspan display="block">Hello</tspan>
    <tspan display="block">World</tspan>
  </text>
</svg>
```
would produce the same result as (traditional way)

```
<svg viewBox="0 0 100 100">
  <text x="0" y="50">
    <tspan>Hello</tspan>
    <tspan x="0" dy="1lh">World</tspan>
  </text>
</svg>
```

This certainly introduces other problems but seriously it's becoming complicated anyway=)



-- 
GitHub Notification of comment by herrstrietzel
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/942#issuecomment-4052353528 using your GitHub account


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

Received on Friday, 13 March 2026 03:36:00 UTC