Show HN: All-SVG websites with complex animation (svija.love)
I wanted to find an easy way to recreate mouseover functionality in SVG. For my first try, I labeled objects in Adobe Illustrator:
• linkSomeName: an invisible link <rect> (over the link text)
• mouseoverSomeName: a <g> mouseover decoration (usually bold or colored text, or an underline), initially hidden
Once I had used it for a bit, I thought that it might be nicer if the effects faded in and out. So, I tried animating the transitions with GSAP. It immediately became clear that there was enormous potential to manage complex animations visually, and I worked over the summer to create Svija Vibe.
It's all based on linking Adobe Illustrator object names to the GSAP script. Most basic transformations already work well but there's a lot I'll be able to do to make it even simpler to use.
I'm really excited about it! I've only just started but I have a million ideas about how to make it more capable — the big one being the ability to chain animations together.
There's a support document at https://tech.svija.love/how/animation that gives more detail about exactly what can be done.
Svija Vibe is free. It works with Svija, which is also free, but you do need to create an account to use it (Maconly, at least for the next three months).
https://news.ycombinator.com/item?id=29430368 · previous HN about Svija 2022-12-03
https://news.ycombinator.com/item?id=30454324 · previous HN about animation 2022-02-24
https://greensock.com · GSAP
137 comments
[ 4.3 ms ] story [ 254 ms ] threadI'm fond of using SVGs for richer content and always like to see them utilized in creative ways so seems like a cool concept.
Without cookies it will try to redirect to the desktop version and fail — if you visit in a tall narrow window it should show you the mobile version and not reload.
By default, the mobile version is served. If it turns out that the request came from a big screen, a cookie is set and the page is reloaded.
From then on, the cookie is used and the big-screen version is sent by default.
The point is just to have a single address for each page but to deliver appropriate content depending on the platform.
The same thing happens with Flutter Web sites which I believe uses a similar idea of render many things with canvas/svg.
The rendering of text is pixel exact between HTML and SVG in every modern browser I've tested with.
What you might be noticing is the distance between consecutive lines of text. HTML can flow text in a rectangle and automatically handle whatever inter-line settings were given in CSS (or the browser default).
SVG cannot flow text-- the user has to specify an x,y for each line. My guess is that it's difficult to figure out how to replicate whatever the HTML algo is for interline spacing of text for arbitrary fonts.
Additionally, the SVG library would need to manually handle word wrapping.
Just with those two you can easily end up in the uncanny value of SVG, especially when the user starts zooming in or out.
My hunch is that subpixel antialiasing and hinting is disabled for SVG elements. As withing SVG images you typically have some amount of vector graphics surrounding a few text elements, it could probably also look off if it was applied to the text parts of the image, but other shapes would be unaltered.
Technically you could trivially apply subpixel antialiasing for all kind of shapes within the SVG image. Possibly it's even possible to apply some hinting at limited scenarios (horizontal and vertical lines). I don't think any browser SVG renderer does any of this.
edit:
I tested this now with Edge on Windows, and I get subpixel antialiasing for both within and outside SVG. So maybe this theory does not hold up.
I do not get a pixel-perfect match however, but that could be because of subtle subpixel positioning of the text itself.
It almost certainly is because you're not putting them at the same position in the page.
There's a hack to normalize the positioning of an HTML to match the x,y position of an SVG text, but I can't remember what it is atm.
Edit: typo
> Svija pages are fully-readable by screen readers, and you can add special text for each page in Svija Admin, visible only to screen readers.
I tested the accessibility with a keyboard and screen reader. With a keyboard, when you press the tab key, focus should usually go left-to-right, top-to-bottom. On this page the first link you tab to is 'Request Access'. From there the tab key goes backwards, to FAQ, Examples etc, then up to Vibe, Blazing Speed etc. Then it jumps down to the footer, does the same reverse order, then jumps all over the place.
The buttons in the main content to trigger animations aren't focussable at all, so aren't accessible without a mouse or touchscreen.
I explored the page with NVDA (a free screen reader) and found a number of sections and links where what was read out was different to what was shown in screen. It looks like you have a hidden HTML DOM that's exposed to screen readers and I assume this is out of sync somehow with what's on screen? I also got a bunch of links that didn't appear on the screen at all.
Exploring with the NVDA elements list (Insert+F7) shows a lot of junk in the Links list - links with text like 'id1584143858', 'UCmfF3YOMVyRcd0m-WpMUZ2g' etc. The Buttons list doesn't show the animation trigger buttons (because they're not marked up as buttons) and the Landmarks list is empty, meaning no easy way to jump to nav, header, footer etc.
Browser zoom is completely broken. The page looks the same at 500% zoom as it does at 100%.
Accessibility is important, and it's really disheartening when new page-building platforms like this pop up that clearly haven't been audited by an accessibility specialist or run past a disabled person who uses assisitve technology, especially when they specifically give the impression they're accessible as the FAQ answer does
Right now I'm just trying to make an interesting platform to explore what's possible with SVG.
Please believe me that when we are able to move forward, accessibility is very high on our priority list.
It's also orders of magnitude harder to make an inaccessible product accessible than it is to build it in an accessible way in the first place
I see so many developers these days make this mistake not only with accessibility, but also with security ("We'll make it secure once it works"; and then it never happens for whatever reason, and by the time it becomes of critical importance it'd take a near complete re-write to "make it secure"), or cross-platforming ("We'll port it to other platforms after we complete the Windows version"; and then down the road they discover they've built on top of a ton of Windows-only middleware and support libraries, painting themselves into a Windows-only corner they cannot escape without a near total re-write). Planning / thinking ahead is a super-important part of the design stage for pretty much any but the simplest of software.
I could be more clear about the product being a prototype — we talked about it amongst ourselves, and decided that it would be better to be as positive as possible in presenting the product.
I seriously doubt that anybody who uses it will be confused in thinking they're building something they're not.
I have a hypothetical question — where does one draw the line when introducing a new technology? A text-based website can be fully accessible, but a movie is not held to the same standards. You don't (as far as I know) create a separate version of a movie with less flickering, or less movement, to enable more sensitive people to be able to enjoy it.
If I am creating a new type of technology that enables animation or other effects, I feel as though I am responsible to handle accessibility as well as possible, but without sacrificing the final product.
I'm probably repeating myself at this point… if I had my way, I would be writing a new editing program to produce hybrid SVG/HTML pages, where the accessibility and other text-oriented issues wouldn't even come up.
However, I don't have the time or the funding right now to write a new editor, so I'm attacking it as best I can with the only program that works, Adobe Illustrator.
IF I can get users, and IF I can get funding, then it will be relatively easy to add accessibility features. Despite what you say about orders of magnitude harder to add accessibility after the fact, these pages are relatively simple.
Right now I could write a script to convert SVG to HTML based on text size and placement on the page. I haven't done it because there are more basic issues like page resizing that need attention, and because I felt that building animation would be more likely to generate interest than saying "look, you can build boring SVG sites that are completely accessible!"
Anyway, I appreciate your taking the time to write. I will try to include more context in our future communication.
- Special text only for screen readers: This should not be a primary method of making a site accessible. Hidden text is often incorrect, or maybe it was correct and then someone updated the page and it no longer matches. Out-of-site, out-of-mind is unfortunately often true in this case, and should really be more of a last resort.
- Accessibility is about so much more than screen readers. My first concern for a platforms like this is people who struggle with animations - either feelings of vertigo or nausea, or just finding movement very distracting. Are prefers-reduced-motion settings respected? Does this encourage authors to create content in a way that has a minimal motion fallback that still works? Is it easy for users to stop animations?
Unfortunately, the accessibility challenges here are significant. I'm sure work will be done later to try and improve it, but you will be limited by previous decisions to patching in solutions as best you can. And that rarely results in a truly usable, accessible experience.
Elements that are drawn first are higher in the SVG, but that only means that they're in back in Illustrator — not that they're higher on the page.
It's pretty common to have a page where the header of the page is modified last, making it the last element in the SVG.
Right now our planned solution will require server-side analysis of text size and placement.
More long-term, we will use HTML for text and SVG for everything else. But that will require an editing program that doesn't yet exist.
The point was that this kind of page is not invisible to screen reader but you still need to think about accessibility and put some effort into it, just like a normal html page.
It will actually be pretty easy to set up.
https://imgur.com/ISKnuhT
https://news.ycombinator.com/newsguidelines.html
It would be good (and I've added it to our dev list) to get a message when JS is disabled instead of just showing a broken page.
I doubt that flash will ever get "replaced", not even https://ruffle.rs/ is feature complete.
Although there were many horrible Flash websites there were some really glorious ones too.
And if I can pursue this project using mainstream, standards compliant technology, I can replicate some of the good things without the exclusive, resource-heavy player that was needed for Flash.
https://greensock.com/gsap/
Maybe figure out a subset or a specific functionality that html elements struggle with but svg excels at, or present this as an alternative to a traditional webpage (like a page specifically for interacting with animations or playing a game or something). As far as building websites using only svg instead of html elements, that is a crazy lift to attempt.
Sure there are some rough edges — this is a proof of concept.
Long term, I would like to create an editing program that combines the best of SVG and HTML, because there are obviously many places where HTML offers a lot more.
That will be a huge project that will require funding, so right now I'm seeing how far I can push SVG by itself.
refX/refY is one example of this. These attributes were added to the SVG spec in 2015 and didn’t have support in all major browsers until a few weeks ago.
Part of what's fun about Svija is that you can design content very rapidly, since the page is an exact reflection of the Illustrator file.
I suspect that introducing responsive aspects would break that experience. However, we will be producing a page editor at some point in the future and when that day arrives we'll be looking into how best to handle these issues.
Right now, with Illustrator as an editor, it's just not possible.
Svija works by sending the smallest configured page (the mobile version) for the first request then checking the browser. If it's a bigger window, then the page is reloaded and only the correct version is sent for any future requests.
I want to be clear that I am not saying that all sites should be built this way — Svija is an experiment to see if this makes sense.
These elements are valid parts of DOM and the events on them trigger within scope of HTML DOM and not within scope of SVG DOM
But I was talking about embedding which is, I think much nicer.
The only difference between both cases I was able to find is that if SVG is loaded via src, it will be a separate `document`. If it's embedded, it's part of DOM tree of HTML document that is being viewed.
We would like to integrate HTML elements wherever possible to display text. This would enable us to preserve semantic content, make accessibility easier, and make text management easier.
The problem is that until we have funding to build our own page editor it's just not feasible. Svija is meant for designers, not coders.
- It doesn't work properly if I resize the page after the page loads. E.g. if I load the page and then scale the browser window, all it does is make everything super small. It kind of works again after I refresh the page though.
- It only has a couple of scaling breakpoints. E.g. If I try to have the page take up half the screen while I do something else on the other half, the page's font becomes absolutely tiny. It also becomes unusably large on widescreens.
- Zooming does nothing
As far as I'm aware, the last two problems are not easily solvable when using absolute positioning like Svija does.
Being responsive is nice for usability because then the site can adapt to any screen/window size. However, in my opinion, it is also fine if the site can adapt to the most common screen/window sizes.
Right now I see you have two artboards in the illustrator file, one for mobile and one for desktop. I think you should at least have another two for half-desktop and tablet. Widescreen should be considered too but for that you can just center the desktop artboard on the page.
I'm not sure what to do regarding zoom though. Ideally it would allow you to change the size of the content while still ensuring the content fits on the page so you don't have to scroll horizontally. However, I don't think that's achievable in this case without making artboards for each zoom level. I guess you could just do zoom and pan?
I get that responsive, in this world, means sending different layouts depending on the client.
I'm in a bind:
If I say "no Svija's not responsive", people will assume that the content doesn't change size and we'll immediately get written off as not addressing the question.
If I say "Svija is responsive" then, as you remark, people say "no, because the content doesn't adapt to the platform".
But, Svija adapts to the window: if you want bigger text, make the window bigger or zoom (currently broken, see my other comment).
So when someone says "is it responsive, yes or no?", the real answer is: it's different.
The main thing I want to emphasize (this is roughly my 20th comment like this) is:
We are committed to making accessible content. It's OBVIOUS that a platform that can't offer accessible content can't be a serious alternative to current technology.
How exactly we implement it remains to be seen. The first thing is to get some users and establish that the basic premise is interesting.
The user can support whatever screen/window sizes they want, and set increments as they wish.
I just do mobile and desktop because I'm mainly doing dev work and want to spend as little time as possible on the site.
There is a bug right now where zoom is broken. It did work correctly, and it will work correctly — in general I feel it's important that the browser controls work as expected (one of the big problems Flash had).
In our case, the page should adapt to the window unless the window was zoomed — when the window size changes, I have to determine if the user changed the window manually or if he/she simply zoomed.
It's quite complicated with Apple's pinch-to-zoom, because that creates a situation where you have two completely different zoom mechanisms that can both be in play at the same time.
And, if you zoom then reload the page, the zoom is still in effect.
It did work correctly then I recently broke it while fixing a different bug. I'll get it fixed ASAP.
Thanks for sharing your thoughts, I really appreciate it.
Rome wasn't built in a day. Not everything can solve all of the problems at the same time. Not everyone has unlimited time and resources.
Is it not laudable to keep pushing the envelope of what's possible and experiment creatively?
Creating is really hard, destroying is alluringly easy.
It's obviously a prototype — I've been building websites since 1995 and believe me, I have a long list of missing features and capabilites that need to be added in.
This is the first time I've felt like the effort to learn and make something cool would be worth it. Thank you!
And, their support resources are top notch — very important for a tool that powerful.
Also, this is not really that novel. Absolute-positioning (or ECP as the author calls it) has been a thing for forever. E.g. Flash websites, Dreamweaver, Wix, Android apps using AbsoluteLayout, etc...
But there's a reason why the entire internet moved towards responsive based layouts. Because although absolute-positioning makes websites/apps super easy to create, it results in sites/apps that have many usability concerns. Most of these concerns are fundamentally unsolvable.
To be clear, I still think the framework is useful, in fact, I may even have some of my non-techy friends use it to make their websites because a website that has bad usability is better than no website at all.
Which model?
Which browser?
I assume you are using the phone in portrait mode.
This seems like an actual bug and I would like to try to reproduce it if possible.
If you're willing you can email me at andy@svija.c_m
The Web was created to have many levels of fallback rendering; “alt” attributes on images, <noscript> tags, font lists in CSS, etc., not to mention the large number of semantic tags not only present in the original HTML, but kept and increased in HTML5. This thing burns all that to the ground and establishes a new lowest acceptable level of web browser (and user able to view it).
I mean, don’t get me wrong: this thing is cool and all, and I, too, have experimented with SVG web pages. But this is not making the web any better.
Reminds me of the dreamweaver slicer days.
When someone says that SVG is just a big image — well, that is not always the case.
We have gone to great lengths to preserve text as text, to preserve images as images, and to use regular links.
That is why we require Adobe Illustrator — it's the only SVG-capable editor that allows for real text and images.
If you look at the source for a Svija page, it's a mess — but it does look like web page source.
Maybe not select the text, but images has always had “alt” and “title” attributes.
> embed links,
Even HTML 2 (RFC 1866¹ from 1995) had image maps, and HTML3.2 implemented client-side image maps (RFC 1980²).
> or reuse parts of the page.
It’s an image, anyone can just screenshot it or download the image file, and then crop it.
> And nobody could copy the source code to make the web a better place.
How is this hypothetical page using Javascript and images better, in this aspect, than an SVG-based one?
The huge drawback which this kind of hypothetical image page has, compared to a page made with SVG, is that pixel-based images do not scale well with increasing resolutions.
1. https://www.rfc-editor.org/rfc/rfc1866.html#section-7.6
2. https://www.rfc-editor.org/rfc/rfc1980
I don't think I'll be able to convince you that our idea has much merit, but I really do appreciate your willingness to share your thoughts.
If I made them instantaneous, then a quick click would be enough but it wouldn't really be an animation — it would just be a state change.
If I made the animation start with a click, then I'd have to have a reset button.
This seemed like a good compromise, although it's true that a few people were confused.
I have tested it on both the Windows and Mac versions of Firefox and didn't see any bugs.
I did notice that Firefox isn't able to handle the animation as smoothly as Safari or Edge/Chrome.
· · ·
As far as PDF's, I actually thought about using PDF's, but:
- browsers don't display them at the right size (there's a big border around the edge in Safari, Chrome displays a toolbar and a left column, and Firefox displays it much smaller than the window size
- it's difficult to link between PDF's without special authoring tools
- it's a proprietary format
- the same page as PDF is a much bigger file than as SVG
- no reusable content: the same photo on two pages has to be reloade
- no visible source code (I consider this one of the most important principles of the web)
- no animation (a complete dealbreaker for any serious web content)
· · ·
As far as printing, you will be able to print Svija pages — it's one of our favorite features.
Right now, there's a conflict with the fact that we use the Display P3 color space that messes up the colors.
I turned that off, and if you go to https://svija.love/content and print the page at 40% you will see that it looks great. It's one of our main use cases — online documentation (for a camera for example) that can be printed and look the SAME as the web page.
Obviously, with animated elements that aren't in the correct position etc., it won't work well.
I'll turn the bright colors back on tomorrow, so after 16:00 GMT on November 10th, this will no longer work.
2. OK, I guess you can (almost) print it.
However:
3. PDF is not a proprietary format. It’s actually a real standard, ISO 32000.
4. You completely ignored my main point, which was about graceful fallback rendering and semantic markup. Honestly, All-SVG websites seems like the XSL Formatting Objects fiasco all over again.
Our objective is to create a format that is sufficiently stable that it won't need a fallback solution.
SVG is incredibly consistant from machine to machine, much more so than HTML. Can you give me an example of a case where fallback would be necessary (leaving aside questions of accessibility)?
Semantic markup is an issue for search engines, but we are building websites for people to read.
Visitors to a website never see the tags. They have no idea if something is <h1> or <div> or <strong>.
Are you suggesting that semantic markup is important for people, or for Google? Is this purely an accessibility issue (I don't mean to diminish the importance, it's just a question)?
Our plan is to automatically create parallel content for accessibility requirements, including semantic information. Sort of like the <noscript> tag, an imaginary <nosvg> tag.
If you feel like I am missing the point of semantic markup, I would love to know why, (or you can just post a link).
Of course, semantic markup is also turning out to be very important for accessibility reasons, since the things people are really needing from a document is its semantic content, and its visual style can be discarded if necessary.
> Our plan is to automatically create parallel content for accessibility requirements
I don’t know. “Separate but equal” seldom works out well.
You didn't reply to any of my reasons for why PDF would be unusable for web pages.
I don't mean to sound combative — I'm trying to learn as much as possible from the feedback on this page. It's a precious opportunity to let some fresh air into our project.
PDF is unsuitable for web pages for more or less the same reasons which SVG is unsuitable. The reasons you gave are also valid, but I deem them insignificant compared to that.
The "What it does" section, with the buttons "Movement", "Rotation", etc. The behaviour of those buttons is not very intuitive. press and hold is hardly the first action someone thinks of when seeing those buttons. Instead they'll click them. They'll see some weird small movement in the corresponding square, if anything (In the last 2, nothing happens if you just click).
What's more, in the following section "No programming", the example shown says explicitly "click here" and explains that the blue rectangle "will be rotated 35º clockwise when the user clicks the trigger". "clicks" is even bolded. And yet, if you simply click it, it will only rotate a few degrees and return back instantly. Again, you need to press and hold for it to rotate completely.
I'd suggest either changing the wording or adding an explanation to tell the user to press and hold, or changing the behaviour of the examples to actually trigger on click.
The "cheat text" that says how it works is just meant to give a general idea. Most people would say they "clicked" the button, whether they were talking about mousedown, mouseup, long press etc.
The actual commands are slightly more complex — but this page is not the place to get into the details of what's a mousedown, mouseup, click, press etc.
What I meant is that most people will just click and not see the action triggered as expected. Some may then try long pressing, but many won't. The result being that a large number of people won't get the expected impression from the demo and may even think that it's not working correctly.
The page doesn't actually suggest that you click on the buttons — they're just buttons (except for one, where it says "click here").
To me it seemed natural to hold down the button until the effect finished, and now I'm wondering if it's a difference between trackpad and mouse users.
I use a trackpad, and it's a relatively slow operation to click. I don't have a mouse handy, but it seems like it would be much quicker.
I will ask some of our testers what they think.
I'd guess it depends on what you think your readers may be using and how they use it, but my bet is still that it will be confusing to a fair portion of readers.
P.S. In fact, on mobile it's somewhat more confusing, because the actions will trigger when I am scrolling and inadvertently place my finger on something. What happens in this case is that the action won't "reset" when I take my finger off. I know none of this is a critical problem, but it does make it appear confusing or even somewhat broken.
I don't know much about Android, but Apple wanted so badly to offer the "real internet" on the iPhone yhat they overrode lots of default browser events behavior.
Things like mouseup just don't get triggered if the user scrolls first, and scrollevents are sent infrequently.
Don't get me started on pinch to zoom which uses TWO invisible rectangles to show content.
Chrome on Android is much more sane.
By default, animations start and end "softly", because it's just nicer overall.
For the buttons in question, I updated them so that they have a hard start and a soft end.
The result is that if you reload the page, the animations start much more quickly and it's more obvious what's happening.
The problem with a simple click is that the transformation would be instantaneous, and it wouldn't look very good. Or, I can start the transformation with a click and let it end later — but then I'd need a reset button.
Anyway, I appreciate your feedback!
With a mouse though, I agree it's not intuitive.
This page is definitely not svg-only though, there is a lot of javascript on the page, and without javascript enabled I only see some curved shapes, and blurry things scroll by when I scroll.
[1]: https://www.pygal.org/en/stable/documentation/first_steps.ht...
I need to clean up the animation programming and make it more straightforward, then I'll be able to get into that stuff.
By SVG-only, I meant that there is no HTML. It also uses NginX, bash scripting, CSS, and Django ;-)
From what I have seen, these kinds of effects are easy to reproduce with regular Illustrator effects. It might be interesting in more advanced animation to change the lighting with other movement.
With Inkscape, the issue is that AFAIK it's not fully scriptable, making it complicated to use with Svija, and there is not a big user base (I've tried unsuccessfully to get real numbers, so I'm judging by participation in SVG forums, things like that).
> Scroll canceling enables you to animate objects that don't scroll with the page.The event is locked to the vertical scroll position, but the animation doesn't scroll vertically.It's enjoyable for the user and gives them a sense of control over their experience — always a way to keep your visitors interested. As you can see, it's a lot of fun — and we've only scratched the surface!
It's not really good for a general, informational website.
It can be very user-hostile, and reminds me of criticisms of Flash.
I obviously can't control what our users will do, but my own guiding principle is that the user should always feel in absolute control of the page. I've been to so many sites where there's essentially a small movie that you scrub through by scrolling, and it makes it impossible to navigate normally or jump to the content you want.
In general we have not had any issues like this.
If I had to guess it would say that it is the Vibe and Home pages that cause problems because they have more animation than the other pages (frequent interrupts).
Any info would be great.
I’d guess it was the gfx driver as this shouldn’t happen no matter what page is doing.