J.Deutsch: “Are you ready for Hype 5?”
“Yeah, man, High 5 !”
Frightened noob here - Is this still a problem? I think I just inserted an externally generated .svg onto a simple timeline and gave it some new opacity/size type attributes. But I can’t seem to get to the path editor in Hype. So despite being vector it can’t be morphed? If this is roughly correct I’d appreciate a keyword or two pointing at workarounds.
That is still not possible. You can only morph vector shapes that you draw in Hype. There is no workaround…
Past Hype versions have been preceded by a robust beta program. Will the next version of Hype follow the same path? If so, when do you expect that to start?
Yes, there will be a beta program (and those on the list will remain on the list). Date TBA.
I sent a email to the contact@ address.
No wishes here for Hype 5, just joyful anticipation ![]()
![]()
Well, it's kinda mixed news. After almost seven years since the last major update. (No, I don't count 4.1.1.) I was wondering if Tumult just decided to test things internally. Then, one day, they'd just say, “Surprise!” ![]()
Yet, a beta test is a really good idea. I'd probably do a better job of testing Physics this time around. I have more specific game ideas.
Also, if the beta works the same way as last time — where we can talk about the features publicly — then I could document the progress with my YouTube channel. I didn't have that when Hype 4.0 was around.
Meanwhile…
…so that's also bittersweet. We know a beta is on the way, which is good. Yet, that also means we have to wait for the beta to start and we don't know how long the beta will run.
Also, TestFlight is new this time around… TestFlight - Apple Developer …is something like that necessary?
Meanwhile, I've been playing around with CSS. I've been learning a lot. It makes me wonder if Media Queries should be a thing in Hype. Like this template…
— Free Template Tuesday #36 – Tumult Hype “Orientation” – Photics.com
…that wouldn't be necessary if Hype supported features like that. So, I'm adding it to the list, even though I'm not sure how that would work with Hype. Modern CSS is great for page layout, even across different devices, but I'm not sure how that works with Hype's elements, timeline, symbols, and groups. ![]()
Take your time! It’s not that current version is useless. Actually very useful and powerful.
+10 years now with Hype and a lot of stuff produced, delivered to happy customers.
Learned to live with some of the hiccups. For instance when an element has been moved, the z-order within Hype, and a restart of Hype is the way to discover that. Or… groups, behaving strange.
Rive.app seems to have a few interesting things. Like the state machine, the way it seems to generate code, collaboration. Have not tried Rive. Not suggesting more features at this point in time.
Looking forward to the next major release.
I work in consulting, helping companies achieve clarity in their decisions. I would like to add my two cents to the discussion about ideas for the upcoming Hype 5.
Some users here, like me, previously used Adobe Director. At the time, it was one of the most powerful tools available for creating multimedia and interactive content.
I remember reading that the engineers behind Director had a very specific philosophy. The core idea was not that Director itself should be the place where you create every asset such as drawings, sounds, or other media. Instead, it was meant to be a hub where you could bring together many different types of media and focus on defining how those elements behave and interact.
There will always be specialized external tools that are better suited for creating graphics, audio, or other assets. Director embraced this reality. Its role was orchestration.
It also used a very strong metaphor: you were the director of a film. The project’s asset library was called the “cast,” and you orchestrated how those elements performed on the stage.
Personally, I believe this philosophy could be a powerful direction for Hype as well. Hype could position itself primarily as a hub where different elements come together, and where creators orchestrate behavior, timing, and interaction like a conductor or film director.
This approach could also open the door for the future. For example, AI generated elements could eventually become part of the cast. Even prompts themselves could be treated as cast items, where a slot in the cast represents a prompt that dynamically generates or updates content as part of the project.
Nice!
The point about CSS conflicts and inline styles in the current version really resonates. When layouts rely heavily on inline positioning and container wrappers, it definitely makes external styling and overrides much harder, especially when trying to keep things responsive.
A modernization in Hype 5 would be very welcome if it could reduce those constraints and make layouts a bit more flexible with standard web practices. Even small improvements in how styles are applied or calculated could make a big difference for developers who want to combine Hype animations with custom CSS or JavaScript.
Also appreciated the mention of Matter.js developments. It’s encouraging to see progress happening there, since physics behavior like collision detection and energy loss can really affect the quality of interactive scenes.
Curious to see how Hype evolves over the next versions and how much flexibility they’ll introduce for developers who want deeper control.
While slowing working through the new web book, I got to the part involving translateZ. It requires the “perspective” property. I've used that before, but I wanted to center the perspective behind my test element. So, I moved the origin using “perspective-origin”. That's when I realized something… this could be animated!
Whoa! ![]()
So, I'm expanding on the “Camera” idea. Wouldn't that be awesome?! I'm imagining how the camera movement is related to the perspective and the perspective origin. Elements positioned three-dimensionally could be animated three-dimensionally.
Even without a camera, animating the perspective and the perspective-origin could create nice 3D effects. I'm not sure how this would work with Physics, or Z-index, but something like this could be great for adding parallax scrolling to video games — especially since this could work the z-axis.
…and a side note, maybe Tumult wants to revisit the use of transform, as “Individual Transforms” are now baseline…
— Individual transform properties | Can I use... Support tables for HTML5, CSS3, etc
(ah yes I have ben waiting for this... I really hate the transform property's syntax though I understand why it was made that way)
I updated the list to include @property Rules, the next generation of CSS Variables (custom properties).
- CSS at-rule: `@property` | Can I use... Support tables for HTML5, CSS3, etc
- @property: Next-gen CSS variables now with universal browser support | Blog | web.dev
It wasn't baseline when this thread was started. And quite frankly, I didn't even know that this technique existed. But now that I know, I'm not sure that I'd use a regular CSS variable again. ![]()
Note: Hopefully no one has the username @property or they might become pretty annoyed on this forum if Hype adds that CSS feature. ![]()
“Unless you are explicitly writing support for ancient browsers, there is no longer any reason to use var as all modern browsers have supported let since 2015.”
— https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting/Variables
Since Internet Explorer will no longer be supported in Hype 5, I'm adding the removal of “var” from the Hype runtime to the housekeeping section.
That shouldn't be too difficult. It's only used hundreds of times. ![]()
I'm not sure how this one should be added to list, but apparently using innerHTML is discouraged. The first thing on the MDN page about innerHTML is a warning about XSS.
It's a frustrating situation because it looks like setHTML is the modern approach.
“ It is recommended (if supported) as a drop-in replacement for
Element.innerHTMLwhen setting a user-provided string of HTML.”
If there's a “drop-in” replacement, where's the problem?
— "setHTML" | Can I use... Support tables for HTML5, CSS3, etc
Oh, there's the problem! ![]()
So, I looked at Tumult Hype to see if it was using the innerHTML property. It is, in two locations…
Timeline — Property
Hype Runtime
I'm not sure what's the solution here, as other suggested solutions mention “nonce” with a Content Security Policy and trusted types. Is that something Tumult wants to include? ![]()
But in general, maybe there are ways to make security improvements with Hype. The reason I mention it is the unknown-unknowns. People use Tumult Hype in many different ways, kiosks, websites, apps. So, maybe it's a good idea to update Hype with modern security recommendations as a consideration.
Also, I think a good idea is to consider adding “innerText” as a timeline property and perhaps “textContent” needs consideration too. (I don't remember ever using the latter one though.)
I've been monitoring the setHTML API myself for a bit.
In this case "user-provided" doesn't mean a Hype user, but a website visitor. Hype users are the "developer" with complete control over the content. So it doesn't quite apply the same way, and I'd say this is not a security risk.
Hype users expect <script> tags to work when they do hit the pencil icon for an element/choose 'Edit > Edit Element's Inner HTML'. setHTML does not allow for this behavior.
.innerHTML has been around for so long that it will probably take ~20 years before it could be thought of as able to be removed (and even then I suspect would just be a console warning).
There are some usages of .innerHTML in the runtime we can switch over, but realistically it just doesn't buy much. There's other places where we could inject elements via the DOM APIs as well (like when constructing iframes), but innerHTML is equivalent and simple
.
As for innerText... An argument can be made that Hype should never have allowed innerHTML ("contenteditable") editing and all text elements can only use top-level styling. Certainly it would reduce a whole class of editing bugs that we've dealt with over the years! But that seems inflexible and not where the product is at.
.
For years I've been thinking that little popup window should be improved. Now I'm thinking it shouldn't do anything but plain text. ![]()
…but that is inflexible.
So, can innerText / textContent be an additional property, or is it not possible because innerHTML exists?
If it can be only one or the other, it seems like a toggle for the app might be a nice settings option or project option. One of the tedious parts of Hype is when it adds HTML tags into the window when I don't want them there.
Well, it could be an additional property but it doesn't seem to me like it is worth UI confusion to a user whether to choose a "rich text box" or a "plain text box" when a plain text is generally just made via not pasting in any rich text.
But I do agree, unwanted tags are a constant source of frustration (and support issues) when they result in unwanted styling.
I'm not sure what I'd do if we were to remake the app from scratch, but it probably would at least be more limited on styling. I've actually wanted to give claude code a crack at some of the problems in this area since they require a ton of code/testing to get right (adding and understanding arbitrary styles) but AI could actually make quick work of this problem space. So maybe there will at least be some movement.


