Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: All-SVG websites with complex animation (svija.love)
188 points by AndrewSwift on Nov 8, 2022 | hide | past | favorite | 121 comments
I created a system for building SVG-only websites called Svija. But, though the content was nice, the sites felt too static — a bit flat and lifeless. Even a basic HTML website has mouseover effects, but SVG doesn't have them for free the way HTML does.

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
The two objects are connected by "SomeName", and a javascript event listener attached to the link object would change the mouseover object's CSS display from "none" to "block".

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




This is sick but replacing html elements with svg is going to be a huge tangled mess and you will be playing catchup forever. Look at huge companies with teams of engineers constantly trying to make sure their browsers render all html elements to spec. You are going to need to do the same with svg or users will get frustrated.

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.


One of the things I like about SVG is that it's the same everywhere. You can look at our site on any major browser and it's exactly the same down to the pixel.

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.


For the common use-cases, SVGs do render consistently across browsers, but there are differences in feature support and rendering behavior outside of those.

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.


Until you start using responsive design in your SVGs, since it supports CSS with media queries :)


Our plan is not to do responsive design — Svija is really meant for designers, and for any content that requires real design, there will need to be separate versions for mobile and desktop anyway.

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.


Bear in mind that SVGs CAN be embedded within HTML so you can have ``` <p> <svg><circle></svg> Some content <svg><rectangle></svg> </p> ```

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


Svija SVG's are embedded in HTML — it's necessary to get the page to resize correctly.

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.


Likewise, SVGs can embed HTML with <foreignObject>. It's DOM trees all the way down


I'm confused by this comment, because I'm not sure how else they would be included in a webpage


Not sure what they meant, but my only guess is they mean via an img tag.

  <img src="some.svg">


Yup. You can also do <svg src="some.svg"/>

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.


Derp.. I've been rendering svgs in JSX for so long, I forgot about the obvious things like <img>, <link>, even adding an svg in CSS with background-image


Personally, I think this is incredibly impressive! It feels much more like reading a magazine than a fixed info-port. Given, there's a time and place for both, but it's always nice to remember the web can be about creative expression.


Thank you so much.


Curious if anyone actually agrees with the supposed benefits of scroll hijacking. I find it jarring and always hate this effect when I come across it.

> 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 acceptable to scroll jack if the site curates that experience specifically for a specific purpose that the user would enjoy.

It's not really good for a general, informational website.


I agree, and in fact I only added this feature because a client requested it ;-) but I'm glad it did because it can be fun if it's done right.

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.


I have personally not seen one single case where the website managed to do that. Ever.


Why does text rendering in svg elements always look slightly off? As in, I can tell that this website isn't native.

The same thing happens with Flutter Web sites which I believe uses a similar idea of render many things with canvas/svg.


> Why does text rendering in svg elements always look slightly off?

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.


If you're confident that you'll always be dealing with a browser environment, this is a situation where embedding HTML in SVG via <foreignObject> is a pretty reasonable approach, IMO.


what do you mean by "pixel exact". svg definitely renders differing amounts of pixels on my different devices. one with dpr 2.0, one with dpr 3.0, one with dpr 1.25


They mean that a specific browser version on a specific device renders text the same regardless of whether you use html or svg.


Possibly different subpixel antialiasing and hinting settings in the SVG renderer and for text outside of SVG elements.

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.


> 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


Probably because there hasn't been a ton of browser-level work on their SVG engine, as opposed to CSS rendering at least. Like the SVG2 spec has been lingering for years. Personally I'd love to see more activity there - SVG is awesome and it has more potential than is currently being utilized (IMO).


Just so you know:

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.


Weirdly I did tap and hold those buttons first and I just realized that has become my default for a lot of UI elements on mobile, because it often emulates hover behavior.

With a mouse though, I agree it's not intuitive.


I actually cheated a bit — you are right that it's not clicking, it's pressing. I tried various things, and this felt the most fun. You obviously feel differently.

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.


Ok. But I didn't mean that as a discussion on what is a click or a mousedown, or what is fun. That's your decision, of course.

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.


I understood that — my answer was a bit clumsy.

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 admit I was indeed using it with a mouse. I tried it on mobile later and... my first intuition was still to tap buttons, not hold them down. I don't like or use trackpads frequently so I can't say much on that.

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 made a change that should help.

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!


Mobile is a mess. Are you Android or iPhone?

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.


There's no way this is accessible right? Imagine someone with a screen reader opening this website and seeing nothing


See my reply to whylo: I agree wholeheartedly that accessibility is important, but I can't devote engineering resources to it until I have a product that's compelling in its own right.


SVG is XML, a screen reader would be able to access it.


Just being XML doesn't make something accessible - I tested with a screen reader and found a lot of issues: https://news.ycombinator.com/item?id=33520364


It's actually worse ;-) because the pages are constructed in Illustrator, the order of text is all messed up.

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.


You can set the tabindex property on SVG elements just like you can do on HTML, then you could setup an understandable navigation.

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.


Thanks for the tip, I will look into it. I didn't know that was the case.

It will actually be pretty easy to set up.


I don’t doubt it, that kind of issue with navigation sequence is easy to mess up if you don’t prioritize it. I just meant that it being SVG is not inherently invisible to screen readers in the way that Flash was. It still means that they need to put some effort into organizing the navigation.


Unfortunately, this is definitely not "responsive". It's effectively just displaying an image and then scaling it to fit as you resize your browser.

- 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.


Why does it have to be responsive?


It doesn't, but if it isn't, then it shouldn't claim to be responsive.

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?


(OP here)

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.


Whoops, for some reason thought you were OP. Please s/you/they.


Sorry, one other point about the term responsive.

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.


From the FAQ:

> 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


I agree wholeheartedly that accessibility is important, but I can't devote engineering resources to it until I have a product that's compelling in its own right.

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.


For a prototype, sure, accessibility might not be top of the list. But everything about the way this is advertised makes it sound like a production-ready product ('it's a stable, rock-solid product') and your FAQs are actively misleading people by implying that it produces accessible output.

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


> "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 understand your point. From my point of view, people who visit our site are mostly people whom I've had some contact with or who read about us in a context like HN, so I don't feel people are being misled.

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.


Along with the "What about accessibility?" FAQ answer being misleading about the current state, I have two additional concerns:

- 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.


Thankfully not _quite_ as broken as the days of Flash


This is like the successor to flash.


That's true. I used to build Flash websites and I started this project because I couldn't see myself building HTML/CSS for the rest of my life.

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.


GreenSock used to be a Flash library!

https://greensock.com/gsap/


I didn't know that — thanks for the info!


https://upload.wikimedia.org/wikipedia/en/8/83/Strong_Bad.pn...


Hehe, yeah forget wasm, let's all use SVG :-)

I doubt that flash will ever get "replaced", not even https://ruffle.rs/ is feature complete.


I imagine wasm and all-svg pair really well.


If all goes well we'll be using WASM to produce our own SVG/HTML hybrid pages in a couple of years ;-)


I kinda love how these generally give off a early 2000s Flash site vibe (in a good way, Flash, dear flash, how I miss the aesthetic, creative freedom, lightheartedness that you brought to the interwebbes)


Thanks, I feel the same way.


Just some test feedback: On my phone I have to scroll horizontally to read the text on the website. A part is always cut off. (Same problem on the linked example sites.)


Are you on Android or iPhone?

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


What I love about this is how the design looks different from what you'd get if you designed a site in a more common way. Every tool has different affordances. And I love that you can see that in the site. It's immediately obvious that something about the creation of the website is unique


Thanks for taking the time to visit!


It's fantastic! Just wish it could be used with open source editors like Inkscape or Krita, instead of AI.


We would love that. The problem is that only Illustrator leaves text as text and images as images — all the others except Inkscape convert text and images into data that's no longer searchable.

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).


Woah, locked up my computer like it hasn't in about ten years. Luckily had sshd running, but still couldn't get it to do much. Had to resort to magic sysreq keys to sync and reboot safely.


Would you be willing to share which computer, Linux version and browser you are using?

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.


Linux Mint 21, latest Firefox, 12th gen intel gfx.

I’d guess it was the gfx driver as this shouldn’t happen no matter what page is doing.


Intel 12th gen is probably too "fresh" for the kernel and drivers of Linux Mint 21.


Thanks for the info. Sorry for crashing your computer.


Does it support lighting effects?


It does not. Right now, Svija only supports effects that can be created within Adobe Illustrator.

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.


The text is not SVG...


It is SVG — it's in <tspan> elements:

  <tspan  class="stVibe-CP1"> lets you take any element or </tspan>


So many comments about how this is missing feature X or Y, isn't responsive, or isn't accessible... It would be nice to have people focus on its achievements rather than its pitfalls, unless the author has claimed it is a built-in replacement for HTML/CSS (which I don't think they did)

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.


I mean, I would not be criticizing it's lack of responsiveness if the author did not claim it was responsive. But they did: https://svija.love/faq#inpage1

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.


Thank you. I really poured my heart and soul into this project, and I think that the idea of creating animation by naming objects in a graphical interface has a lot of potential.

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.


I've been building websites for about the same amount of time, and have never done JS animations and stayed away from GreenSock because I was scared of it, even though I was always curious.

This is the first time I've felt like the effort to learn and make something cool would be worth it. Thank you!


Greensock is really great. It's pretty easy to use if you know a little JS, and it's very powerful.

And, their support resources are top notch — very important for a tool that powerful.


These sorts of meta comments end up being just noise because the discussion changes over time. If you want to move the thread in a direction you think is better, be/write the change/comment you want to see in the world/thread.


[deleted]


I’d honestly prefer an inline PDF. At least then I would probably be able to print it. This thing has all the drawbacks of a Flash-only site, except instead of just requiring a browser plugin, it requires Google Chrome to browse (I found multiple things which did not work in Firefox).

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.


If you can be specific about what is broken in Firefox, I would be grateful.

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.


1. OK, it does seem to work in Firefox.

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.


It's true that I didn't answer your main point.

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).


The reason to use semantic markup is precisely because you don’t know what you want to do with the data after the fact. If you, for instance, make all quotes italic, and also emphasize words using italic, how would you later find all the quotes (maybe to verify their authenticity or create source links)? You can’t, since you have hidden the semantic meaning (emphasis or quote) behind a visual style (italic). Non-semantic markup loses information which you originally had when creating the document, and you might need that information later.

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.


Thanks for taking the time to answer, it means a lot to me.


I didn't know that PDF is a real standard — thank you.

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.


> You didn't reply to any of my reasons for why PDF would be unusable for web pages.

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.


I didn't notice any problems in Firefox but the layout is totally broken in Safari for Mac.


The “Transparency” and “Combination” buttons are not working for me.


All the buttons in that area require not just a click but holding mousedown for effect to occur, Transparency and Combination work for me in Firefox if I do that.


Oh, right, I see. They do work. It was not obvious that you have to hold down the button.


I modified the animation so it starts much more quickly.

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.


JPGs/PNGs are not making the web any better either. We still use them. SVGs are slightly better. They have readable content and don't pixelate. Plus they react.

Reminds me of the dreamweaver slicer days.


If you made an entire web page be a JPEG or PNG image with Javascript to handle clicks, I would not like that, either.


If it was JPG or PNG, you could not select the text, embed links, or reuse parts of the page. And nobody could copy the source code to make the web a better place.

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.


> If it was JPG or PNG, you could not select the text,

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


By reuse parts of the page, I meant more that on a website where each page has the same 20 images, they don't have to be loaded by the browser after the first page because they're cached.

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.


That web page looks… interesting without JavaScript

https://imgur.com/ISKnuhT


Honestly doesn't look that different compared to a lot of "modern" oversized gridless webpages people peddle nowadays.


Please don't post shallow dismissals, especially of other people's work.

https://news.ycombinator.com/newsguidelines.html


I think it’s a fair point when it comes to accessibility as discussed in another comment.


It's about the form rather than the point. The point is fine.


Please don’t gaslight me.


I prefer to think of it as gasenlightening.


Yes, Svija requires javascript to work.

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.


To be fair so does any website made after 2000.


I was hoping this was something interactive using only svg. For example, one can do interactive charts with moving tooltips and a vertical cursor etc. fully in svg, using only hover states. (I thought Pygal [1] did this, but now that I check it again, it seems to require javascript for the tooltips.)

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...


Here’s an example of what I mean, an interactive svg-only graph: https://gist.githubusercontent.com/ruuda/b84e94c3394f740d05b...


I would love to add interactivity, and there are also a lot of SVG effects that we haven't even touched.

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 ;-)


And in a Flash, Shockwave is back :) This approach is going to have a lot of same accessibility issue.


Does the site require cookies btw? As it appears to be in an infinite reload loop in two browsers I tested.

I'm fond of using SVGs for richer content and always like to see them utilized in creative ways so seems like a cool concept.


It does require cookies — did your loop occur with cookies on or off?

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.


I see. Yeah I had cookies disabled in both browsers I tried. Trying using a narrow viewport does load fine, although it's possible to have dual-purpose desktop and mobile styling in a single SVG using media queries, which I've done before (not sure how your desktop version differs though).


The reason why we need cookies is to deliver different versions depending on the platform.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: