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

## A native text-wrapping feature in SVG would be a quantum leap! 
I'm pretty sure that many implementers are more than willing to do so - I think Inkscape is already a good example of this.
Frankly, I think a lot of implementers are just slightly frustrated by the previous spec history around this topic (I see why `textarea` in SVG tiny had issues).   
But I think this long-standing problem (no multiline SVG text) is partly *also* caused by previous SVG working groups neglecting or underestimating the importance of this basic text-composing functionality entirely.
And I appologize if some of the following lines may appear a bit *cheeky*.

### In short: Wishlist
Please also consider to ...
* add a presentation attribute complementing CSS `inline-size` property – CSS only isn't ideal as many applications don't have great CSS support
* reintroduce something like a `<tbreak>` element for manual line-breaks

### Simple multiline capabilities first – fancy shape text-composing later (please=)
The specification should focus first on simple multiline/line wrapping capabilities – as used even before CSS and painstakingly implemented by most SVG visualisation libraries. 
Sure, SVG was designed primarily to support vector graphics, not complex text layouts, and it doesn't need to compete with HTML/CSS for all the bells and whistles.
However, the ability to have a "block-like" text composing behaviour should be the highest priority.
Text-in-shape capabilities might be nice, but algorithms are certainly way harder to implement and - highly subjective - less relevant (erm, a GUI graphic application is more suitable for this).
For instance: `line-height` should be mentioned in the first paragraph but certainly not in a caption about gimmicky text-in-shape (sorry). 

### Manual breaks for SVG
An equivalent to HTML's `<br>`, such as `<tbreak>`, would also be helpful - indeed mandatory.
* It's quite complex to calculate a text width or bounding box to get an appropriate line break. 
Sure, trivial in a browser, but incredibly hard to do in a headless/virtual DOM environment (actually requires parsing a specific font file, reading the metrics, applying scaling, interpreting letterspacing, etc).
* Manual line breaks could simplify this task, e.g. for data visualisation, to ensure that a long label text breaks at a predefined point - especially if the font is not perfectly defined (e.g. via inlined `@font-face` source definitions).

### CSS vs presentation attributes
If CSS `inlne-size` is the best candidate - fine!  
But SVG presentation attributes are still useful. 
Ideally, we should also have an SVG attribute to set the maximum textbox width.  
While I totally embrace the concept of controlling SVG more and more via CSS - **emulating a full-blown CSS engine is trickier than parsing attributes.**.  
Sure, non-browser applications will eventually have to catch up anyway - but realistically it is also much easier to write a converter based on attribute parsing than to write a full-fledged `getComputedStyle()` emulation (ask the node.js guys).

Besides, I don't think we can get the perfect CSS-only shift – at least not any time soon: 
Many crucial attributes are still not accessible via CSS like `viewBox` or even element based properties like `<polygon>` related `points` where the path data attribute `d` is stylable (... at least in any engine apart from webkit). 
So currently, we (as developers) have to guess which attribute is "stylable" by specs or by implementation or if it's likely to be ever stylable at all.  
So I definitly promote an attribute "fallback"!

### We'll need a lot of converters
Not an issue at all as we won't fix abysmal SVG support overnight, but as long as we have a reference we can write a conversion tools/scripts.
(I guess it would be poetic justice if the MS office folks may get some trouble ... ah, no they would blame SVG to be incompliant with Office ).
As mentioned before, an additional presentation attribute would certainly facilitate this task.


To be clear, it is not my intention to belittle the efforts of the current or past members of the working group. I'm just very passionate about this mysteriously confused and seemingly intractable SVG core bug concerning SVG's text capabilities.

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


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

Received on Monday, 16 December 2024 04:51:17 UTC