3 ms·

yeah, this doesn't really touch on the beef i have with SVG. the problem I have is that SVG is complicated like the old web, but unlike the new web we also hav

yeah, this doesn't really touch on the beef i have with SVG. the problem I have is that SVG is complicated like the old web, but unlike the new web we also haven't created new standards like Flexbox and Grid that let you ignore the problems with the old ones. For example, in HTML-land we have had z-index for a while to describe the order in which elements should render on top of each other. This doesn't exist in SVG, so the order of elements is the order that they are declared in markup, which can lead to very kludgy things. In SVG land, there is no way to orient around a multiline text box's corners, you can only align the baseline of the first line of text. In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Etc., etc. These are all things solved in SVG1.2, but of course the classic issue is that barely anyone has bothered implementing SVG1.2.

felixfbecker 2y ago
> In SVG land, there is no way to orient around a multiline text box's corners, you can only align the baseline of the first line of text. In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Etc., etc. You can use <foreignElement> and just include HTML text with all CSS text layout capabilities to achieve that. It won't work in Illustrator or Figma, but it's fine for the web. I honestly am somewhat okay with that, let HTML+CSS handle what it's already best at instead of duplicating functionality into SVG. The z-index is somewhat annoying for accessibility though, because the DOM order also determines the accessibility tree order, so it's not always possible to reorder the DOM to re-arrange the z-order without breaking screen reader order.
- bobthepanda 2y ago
  to be honest i think the warts of svg aren't necessarily the worst for writing svg by hand, though it's not great. but it makes writing design programs that output svg, annoying. the need for a `textarea` element is so great it's already in what was supposed to be the next generation of the spec; and pretty much all SVG output software has a way to input text boxes to treat them like that. But I suspect the complexity of dealing with svg is why alternatives to the Adobe Suite have only become more numerous recently; it's a complex beast. to me, .ai and .svg are the equivalents to .doc and .docx, but we don't really have a great alternative a la Markdown that is significantly easier to output.
rjsw 2y ago
> In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Or to have a rectangle scale to the width of the text inside it. I have been told by a member of the standardization committee that you are supposed to use Javascript for this kind of thing.
CrimsonCape 2y ago
Do people really spend the time building specifications with no implementation in mind? I find that kind of fascinating. Like the people actually building the implementation aren't around yet to figure everything out, what works, what doesn't etc through the process of implementing; seems like a classic case of "works great in theory."
- bobthepanda 2y ago
  SVG has the added complication that there are two classes of implementer: browsers, but also the programs that produce it like Adobe and GIMP.

felixfbecker 2y ago

> In SVG land, there is no way to orient around a multiline text box's corners, you can only align the baseline of the first line of text. In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Etc., etc. You can use <foreignElement> and just include HTML text with all CSS text layout capabilities to achieve that. It won't work in Illustrator or Figma, but it's fine for the web. I honestly am somewhat okay with that, let HTML+CSS handle what it's already best at instead of duplicating functionality into SVG. The z-index is somewhat annoying for accessibility though, because the DOM order also determines the accessibility tree order, so it's not always possible to reorder the DOM to re-arrange the z-order without breaking screen reader order.

bobthepanda 2y ago
to be honest i think the warts of svg aren't necessarily the worst for writing svg by hand, though it's not great. but it makes writing design programs that output svg, annoying. the need for a `textarea` element is so great it's already in what was supposed to be the next generation of the spec; and pretty much all SVG output software has a way to input text boxes to treat them like that. But I suspect the complexity of dealing with svg is why alternatives to the Adobe Suite have only become more numerous recently; it's a complex beast. to me, .ai and .svg are the equivalents to .doc and .docx, but we don't really have a great alternative a la Markdown that is significantly easier to output.

rjsw 2y ago

> In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Or to have a rectangle scale to the width of the text inside it. I have been told by a member of the standardization committee that you are supposed to use Javascript for this kind of thing.

CrimsonCape 2y ago

Do people really spend the time building specifications with no implementation in mind? I find that kind of fascinating. Like the people actually building the implementation aren't around yet to figure everything out, what works, what doesn't etc through the process of implementing; seems like a classic case of "works great in theory."

bobthepanda 2y ago
SVG has the added complication that there are two classes of implementer: browsers, but also the programs that produce it like Adobe and GIMP.