[HN Gopher] Show HN: All-SVG websites with complex animation
___________________________________________________________________
Show HN: All-SVG websites with complex animation
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
Author : AndrewSwift
Score : 114 points
Date : 2022-11-08 13:45 UTC (9 hours ago)
(HTM) web link (svija.love)
(TXT) w3m dump (svija.love)
| [deleted]
| zagrebian wrote:
| That web page looks... interesting without JavaScript
|
| https://imgur.com/ISKnuhT
| nr2x wrote:
| To be fair so does any website made after 2000.
| [deleted]
| pvg wrote:
| _Please don 't post shallow dismissals, especially of other
| people's work._
|
| https://news.ycombinator.com/newsguidelines.html
| zagrebian wrote:
| Please don't gaslight me.
| pvg wrote:
| I prefer to think of it as gasenlightening.
| nr2x wrote:
| I think it's a fair point when it comes to accessibility as
| discussed in another comment.
| pvg wrote:
| It's about the form rather than the point. The point is
| fine.
| sibit wrote:
| Honestly doesn't look that different compared to a lot of
| "modern" oversized gridless webpages people peddle nowadays.
| mNovak wrote:
| 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.
| nashashmi wrote:
| This is like the successor to flash.
| excitednumber wrote:
| https://upload.wikimedia.org/wikipedia/en/8/83/Strong_Bad.pn...
| sandreas wrote:
| 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.
| AndrewSwift wrote:
| 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.
| adamredwoods wrote:
| GreenSock used to be a Flash library!
|
| https://greensock.com/gsap/
| AndrewSwift wrote:
| I didn't know that -- thanks for the info!
| ericmcer wrote:
| 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.
| AndrewSwift wrote:
| 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.
| xtian wrote:
| 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.
| eithed wrote:
| 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
| pcthrowaway wrote:
| I'm confused by this comment, because I'm not sure how else
| they would be included in a webpage
| itslennysfault wrote:
| Not sure what they meant, but my only guess is they mean
| via an img tag. <img src="some.svg">
| pcthrowaway wrote:
| 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
| ouija wrote:
| 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.)
| nulld3v wrote:
| 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.
| [deleted]
| thebeastie wrote:
| Does it support lighting effects?
| airstrike wrote:
| 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.
| nulld3v wrote:
| 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.
| [deleted]
| AndrewSwift wrote:
| 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.
| ghostbrainalpha wrote:
| 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!
| AndrewSwift wrote:
| 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.
| pvg wrote:
| 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.
| Springtime wrote:
| 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.
| [deleted]
| AndrewSwift wrote:
| 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.
| Springtime wrote:
| 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).
| AndrewSwift wrote:
| 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.
| [deleted]
| webmobdev wrote:
| It's fantastic! Just wish it could be used with open source
| editors like Inkscape or Krita, instead of AI.
| Ptchd wrote:
| The text is not SVG...
| ruuda wrote:
| 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...
| [deleted]
| AndrewSwift wrote:
| 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 ;-)
| ruuda wrote:
| Here's an example of what I mean, an interactive svg-only
| graph:
| https://gist.githubusercontent.com/ruuda/b84e94c3394f740d05b...
| genezeta wrote:
| 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 35o 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.
| esperent wrote:
| 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.
| AndrewSwift wrote:
| 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.
| genezeta wrote:
| 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.
| tylerfoster wrote:
| And in a Flash, Shockwave is back :) This approach is going to
| have a lot of same accessibility issue.
| [deleted]
| teddyh wrote:
| 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.
| [deleted]
| nashashmi wrote:
| 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.
| kevmo314 wrote:
| 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.
| jancsika wrote:
| > 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.
| mhink wrote:
| 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.
| planede wrote:
| 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.
| jancsika wrote:
| > 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
| danielvaughn wrote:
| 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).
| whylo wrote:
| 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
| Lorin wrote:
| Thankfully not _quite_ as broken as the days of Flash
| AndrewSwift wrote:
| 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.
| whylo wrote:
| 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
| blooalien wrote:
| > "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.
| AndrewSwift wrote:
| 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.
| [deleted]
| kalensh wrote:
| 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.
| [deleted]
| warent wrote:
| There's no way this is accessible right? Imagine someone with a
| screen reader opening this website and seeing nothing
| Tagbert wrote:
| SVG is XML, a screen reader would be able to access it.
| [deleted]
| whylo wrote:
| 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
| [deleted]
| AndrewSwift wrote:
| 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.
___________________________________________________________________
(page generated 2022-11-08 23:01 UTC)