Thanks for the beautiful new Templates but please stop using inline SVG's

Feature Request
1

Hi,

Thanks for the beautiful new templates!

There is only one thing that I pointed out weeks ago: Please stop with using inline SVG’s
The new templates proof exactly my point that it becomes a code labyrinth without any reason. I don’t see any advantage in placing SVG illustrations inline on a HTML webpage.

If we want to change the SVG better use a dedicated editor like Affinity Designer (that cost peanuts!) or Illustrator (If you like to pay every month until you die) and use external SVG files. I mean I don’t use inline images as well, because the code gets so unclear that it’s not worth the benefits.

Regards,

David

2

Tastes and colors are not debatable, but having SVG in inline mode is for example a good choice to create quality animations with the interaction module.

For the rest, indeed, the code view may seem crowded and the tree view is probably more convenient at this level.

1 Like
3

To indicate that there is no advantage or little benefit to inline SVG is completely contrary to the modern web and most development. Instead it’s great to start seeing the enhanced ability to work with SVG within the app beginning with version 5.98 of Pinegrow, hopefully more will come.

You can always code fold the SVG instance(s) in the code panel.

code-fold-svg
code-fold-svg1018×922 94.7 KB

Maybe a better argument would be to #feature-request targeted code folding within the code editor for all SVG’s, along with a better code editor experience overall. Having the ability to code fold / toggle all SVG instances at once within the “Page Code Panel” through its “options dropdown” would easily clean up the code view and alleviate that aspect of frustration.

In regards to editing you can copy the <svg></svg> source. Once copied, if your design app allows you can simply paste it within your app. Otherwise you can save it as a .svg file to modify it within a visual app. You can then choose if you want to re-optimize & re-inline your edited version or instead link to the actual SVG file itself.

1 Like
4

The only reason to embed inline SVG code is if you want to animate within the SVG. More logic seems to me to keep all SVG’s external with a possibility to click a button: “Make inline SVG” that copies the code in to the HTML when needed. For the rest inline SVG’s clutters your code and doesn’t cache in your browser (performance issues) and has nothing to to with modern web development. (I work with a code editor Sublime Text it looks like a code labyrint with all that useless code).

This is a interesting article from Thomas Yip the founder of Vectra who knows what he is talking about:

Conclusion from the article:

As can be seen from comparison, it is clear we are recommending <img> tag for most use cases. The only exception is if you need interactivity, where you require dynamic changes to your SVG based on user interactions.

We do not recommend inline SVG for most cases, with the only exception being pre-loading pages. Pre-loading pages are contents shown when your application has yet to completely load, and since inline SVG shows almost immediately, it can be used to show images or graphics while waiting for your application to load.

5

@AllMediaLab In the end, without getting into a war of opinions, what is excellent in web development is that there are as many ways of doing things as there are convictions based on experience or technological evidence.

By choice, our templates now integrate inline SVGs, but fortunately, anyone who wants to modify the templates and integrate their own SVGs using the <img> tag can do so without any worries :wink:

2 Likes
6

Hi @Emmanuel,

My opinion is based on facts!

That implicates that every time you load a page with your template. All SVG’s are not cached and are loaded again and again every time you open that particular page and it is a lot of work to strip the pages from inline stuff more logic is external SVG’s with the possibility to choose inline SVG for animation or editing:

From Mozzila Developers:

Cons

  • This method is only suitable if you’re using the SVG in only one place. Duplication makes for resource-intensive maintenance.
  • Extra SVG code increases the size of your HTML file.
  • The browser cannot cache inline SVG as it would cache regular image assets, so pages that include the image will not load faster after the first page containing the image is loaded.
  • You may include fallback in a <foreignObject> element, but browsers that support SVG still download any fallback images. You need to weigh whether the extra overhead is really worthwhile, just to support obsolescent browsers.

That means ugly performance that nobody wants!

Is not the most important reason for you that yo want to make SVG’s editable in Pinegrow? Or to use it with Interactions? Then I would advise to do it the opposite and make templates with external SVG’s or icons and the possibility to make the SVG code inline when needed for a animation or editing, because using only inline SVG is bad practice for normal web design.

7

Sure, using images can have some advantages but we are not trying to claim that SVG is the best for all needs. This is just a starting point for anyone who needs a good template. Actually we expect those contents, SVGs and images to be replaced as per your needs but you are still free to use them. We are not trying to stop you to use images, as you know Pinegrow provides as much freedom as it can; and deleting SVG or adding image is not really a hard work. Only the thing is end user will have to do it and we do not.

Yes we can use images in some places but about the advantage that we’ve, is actually while developing those templates. SVG gives use freedom to just copy and paste in any page unlike images, for which we have to maintain files and folders, and another thing is we can change colors as per the template right from the Pinegrow or a code editor.

Here we are developing atleast 2 templates, one for Bootstrap and another for Tailwind. And we are only using classes provided from those frameworks so there are differences in colors. In some case we even try more colors options that is provided by the frameworks.

And also for images we are depending on unsplash.com, this way we don’t have to maintain a folder for images, because at the end we expect our user will have to replace them. And changing those SVG is very easy unlike saving image files and saving another if we don’t like it. So we are just trying to simplify our process.

Just FIY, you don’t have to depend on a premium software for extracting SVG. Just try AdobeXD or Figma, just copy and paste directly into Pinegrow and you’ll even get better optimized SVGs and even save it as images, which will also be better optimized for web.

3 Likes
8

@AllMediaLab,

Thanks for wanting to provide edification I appreciate your impassioned feedback. However I was only responding as it pertains to the app and inline SVG usage. Not the overall complete and broader topic of standardized usage for every instanced scenario or advocating singular usage of one method over another.

Regarding the idea of dynamically inlining SVG as an option, both that as well as saving an SVG from inline source in a bidirectional manner are each pretty easy via JS.

Good luck on your crusade, I will thus leave you to it. :wink:

9

@abirana,

I love your work! And made a lot of complements about the new blocks/templates (already created 3 websites with them!) on this forum. So to be clear that’s not my point!

This gets really interesting! @Pinegrow_User @Emmanuel and @red-rosefields even liked your reply!

And it has absolutely nothing to do with my post!

My post is about SVG inline vs SVG external and not about images at all. Maybe you should or read my post from the beginning or just leave it when your not interested.

And I use Sketch, Affinity Designer, Affinity Photo, Illustrator and Photoshop.

Makes me wonder what’s going on on this forum?

10

@AllMediaLab As much as I appreciate and respect your references and the super interesting links you provide here, I wish to express my own preferences without restrictions or judgment as well.

@abirana is my colleague at work, the author of the templates available in Pinegrow, I simply appreciate his work and I’m just in line with his last message here :slight_smile:

11

@Emmanuel,
Only his reply to me has nothing to do with what I have posted. He is talking about all kinds of things (like images etc.etc.) I never spoke a word of. That makes it very difficult to take it serious!
My post is only about SVG inline or SVG external, nothing more nothing less!

12

Let’s relax :slight_smile:
This is not the first or the last time that a subject moves away more or less from the original subject.

His message remains interesting from his experience and my like is certainly not a comparative judgment with your previous interventions.

13

I’m very relaxed, but for me it’s a issue when I use your blocks/templates and have to strip down all the inline stuff every time I use it.
And I have made complements all the time about the blocks/templates etc. that’s not the issue!

14

Ok, Message received :slight_smile:

15

@Emmanuel,
It must be very simple to make all SVG’s external with the possibility when you want to animate or edit to click: “make SVG inline”. or not? Compare to what it is now? That’s my idea for a future request! And that’s what my whole post is about!

1 Like
16

Very simple, I don’t know, let your suggestion make its way and we’ll see what the future will bring :wink:

2 Likes
17

Well!
This is a fabulously educational topic!
Thanks all, I’ve learnt quite a bit and would now like to try SVGs…

disclaimer Ive never bothered until now, but this is great, I now have WAY more understanding of the concepts employed and how it actually works and with regards the whole Caching thing… that’s interesting!

SO, from all the actually techie side of things, it looks like @AllMediaLab 's idea kind of wins on points, after, reading the linked content etc.

However, from the User experience point of view, ie, being a numpty , who forgets everythign, like myself, then the whole PG UI way of doing it sounds fabulous!..providing I have no clue about the data overheads and speed implications that @AllMediaLab mentions…

So, I get you both and both seem to have merit, but if I was smarter, and used them a lot… and cared about performance, It looks like Id have to end up going doing the @AllMediaLab route, gnashing my teeth and cutting and pasting, into separate files etc, but sounds like I would then also loose the PG UI sweetness.

But, in the end, the PG UI sweetness… doesn’t count for much, once the site is deployed to my server…er, which very few of them are!

SO its like the PG approach to it is fab, and all bells and whistles and flexibility,
And the @AllMediaLab approach, is entirely data economy and overhead driven.

Very enlightening.
Could you have a tick box option to cater for the later (probably with a load of hassle?

save to external svg
move inline svg to external file etc etc, AFTER creating/editing?

Edit
oh! LOL @AllMediaLab just wrote the same as my conclusion, as I was writing it!
Deja vu…

1 Like
18

Yes sometime people are on the same level, and guess what? I’m in the exotic country you were talking about last week. Belgium.

19

Hee Hee, bizarrely, half the coders on this forum seem to be in Belgium! That’s why I mentioned it …as exotic. There is definitely some PG voodoo going on over there :smiley:

1 Like
20

Yes we moved from the Netherlands to a small town in the middle of nowhere at the border of the Belgium Ardennes :wink:

1 Like