4 ms·

With great powers come a lot of people very mad about how we miuse them & that we might not be able to reimplement it all in a weekend. > This problem of SVG i

With great powers come a lot of people very mad about how we miuse them & that we might not be able to reimplement it all in a weekend. > This problem of SVG is actually just the problem of the web in general. It’s scope is huge, it’s bloated and hard to work with. > SVG is nothing you could implement in a day. Or a week. Or a month. The huge amount of specifications, that are most often only partly implemented, makes it very hard to overview what supports what, confusing the user as to what features they can actually use if they want their SVG file to be universally supported That just doesn't seem like a big problem, in fact. The webs gotten pretty good & the standard is pretty high. Yes people have some real pains but also my word, software is a world of contrived griefs, nonsense beefs. People love grandstanding against things.

bobthepanda 2y ago
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.
bobajeff 2y ago
We are in a situation today where no one can realistically make a competing implementation for Chromium/Webkit/Firefox and at the same time only a company with a large amount of money can afford from and maintain those codebases. I think that's kind of a big problem.
- JanetToolsmith 2y ago
  Have you been following Ladybird browser project? From an early (2022) post: https://awesomekling.github.io/Ladybird-a-new-cross-platform-browser-project/ https://awesomekling.github.io/Ladybird-a-new-cross-platform... > Q: Why bother? You can’t make a new browser engine without billions of dollars and hundreds of staff. > Sure you can. Don’t listen to armchair defeatists who never worked on a browser. ...fast-forward to this month: https://awesomekling.substack.com/p/forking-ladybird-and-stepping-down-serenityos https://awesomekling.substack.com/p/forking-ladybird-and-ste... > Since then, SerenityOS has grown into a large OSS community with over one thousand contributors all over the world. > Personally, for the past two years, I've been almost entirely focused on Ladybird
  - bobajeff 2y ago
    That doesn't really solve the problem. It will involve many many many many hours of development to get to the point where it's a viable alternative and if it ever does eventually reach that state, it will require lots of lots of hours of maintenance work.
    - jauntywundrkind 2y ago
      Yes. The world's most powerful incredible capable hyper-media is challenging to rebuild. Thats not a bug: it bespeaks the beneficent featurefulness.
      - bobajeff 2y ago
        That's only fine if you just care about the Web as a software platform. What about security vulnerabilities? What about having choices in browsers? What happens when Google decides they are finally ready to deprecate manifest v2?
userbinator 2y ago
That just doesn't seem like a big problem, in fact. It is a big problem when the only ones who can write browsers that will work on all the sites people care about are Big Tech.
DidYaWipe 2y ago
The Web is still a hack. The amount of effort required to present content in your intended layout is absurd, and still unreliable. We need a re-do. A lean, clean SVG might be the ticket.

bobthepanda 2y ago

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.

bobajeff 2y ago

We are in a situation today where no one can realistically make a competing implementation for Chromium/Webkit/Firefox and at the same time only a company with a large amount of money can afford from and maintain those codebases. I think that's kind of a big problem.

JanetToolsmith 2y ago
Have you been following Ladybird browser project? From an early (2022) post: https://awesomekling.github.io/Ladybird-a-new-cross-platform-browser-project/ https://awesomekling.github.io/Ladybird-a-new-cross-platform... > Q: Why bother? You can’t make a new browser engine without billions of dollars and hundreds of staff. > Sure you can. Don’t listen to armchair defeatists who never worked on a browser. ...fast-forward to this month: https://awesomekling.substack.com/p/forking-ladybird-and-stepping-down-serenityos https://awesomekling.substack.com/p/forking-ladybird-and-ste... > Since then, SerenityOS has grown into a large OSS community with over one thousand contributors all over the world. > Personally, for the past two years, I've been almost entirely focused on Ladybird
- bobajeff 2y ago
  That doesn't really solve the problem. It will involve many many many many hours of development to get to the point where it's a viable alternative and if it ever does eventually reach that state, it will require lots of lots of hours of maintenance work.
  - jauntywundrkind 2y ago
    Yes. The world's most powerful incredible capable hyper-media is challenging to rebuild. Thats not a bug: it bespeaks the beneficent featurefulness.
    - bobajeff 2y ago
      That's only fine if you just care about the Web as a software platform. What about security vulnerabilities? What about having choices in browsers? What happens when Google decides they are finally ready to deprecate manifest v2?

userbinator 2y ago

That just doesn't seem like a big problem, in fact. It is a big problem when the only ones who can write browsers that will work on all the sites people care about are Big Tech.

DidYaWipe 2y ago

The Web is still a hack. The amount of effort required to present content in your intended layout is absurd, and still unreliable. We need a re-do. A lean, clean SVG might be the ticket.