Yes I do that.
Here's the file.
After two seconds, I would lile to change the text from ÉTOILE to STAR.
And why not change its Y position:
text class="st1 st2" id="text92" x="142" y="269" where y becomes 250.
But it does not save the changes.
star.hype.zip (20.9 KB)
Ah -- I see what's going on. The element would need to be in a regular rectangle:
star.hype.zip (23.8 KB)
(This is a bug where it appears as though you can set frames on HTML widgets)
So instead of using “Insert HTML”, we draw a rectangle and add the code in it?
Is that the standard practice or do you plan to fix it so that with ‘Insert HTML’ it works too?
a so called widget produces an iFrame, which is an independent html-document.
I think we would disable inner HTML keyframing for HTML Widgets, since changing the src of a HTML widget would flash the content and look bad. (We can't dynamically change the innerHTML of a iframe in the same way we can do that for a rectangle)
btw: will the change of innerHTML change the whole innerHTML or just the changed parts? considering performance ...
I was thinking about that and I thought: “Maybe where we change the code, Hype will just make a copy of that line to ‘animate’ it so it doesn't need to duplicate the whole code”.
In the case of <div>-based elements, Hype does a simple element.innerHTML = newValue;.
We can't do a text diff, as browsers do not store innerHTML as text data and there's no way to transmit such a diff.
We could do a DOM diff, where we would build a structure of the new Inner HTML, compare it to the current browser DOM structure, and then only replace nodes that have changed. However, Hype's runtime would then need to fully understand how to parse HTML, and it would be gigantic in size. It would likely not result in performance improvement either in most if not all cases, since we're doing a lot of work that is done anyways with a full innerHTML replacement, and in JavaScript to boot.
React and its kin have a similar idea of diffing the "Virtual DOM." This is faster than what we could do because a) they are not parsing HTML, instead working with their own structured data from the get-go and b) they are reading from their own in-memory contents and not making DOM queries - they assume their view on the DOM is uncorrupted from what they have in their own memory. In fact, despite performance claims about React, it really isn't very fast in a lot of cases (they are doing work a browser still has to do), and most certainly is much slower than javascript code that surgically alters the correct property.
Therefore if you know what you are changing and there are performance problems in changing it through an entire innerHTML substitution, then you should use JS to change the specific part yourself.
Anyhow, to the original point, we've definitely seen confusion about HTML Widgets vs. Rectangles and have long wanted to clarify the distinction of div vs. iframe-based elements in some way.
Very technical side note (not for the OP but for nerds): You can do some stuff with Hype Handlebars
It could be done by defining any arbitrary inner HTML containing the Handlebars notation, and Handlebars actually turns it into a function generating a string. Its pretty fast. Hence, updates do render the whole branch but by executing the dynamically prepared function based on the Handlebar syntax. The Only missing thing for this is the ability to hook up arbitrary animated properties in Hype as it currently needs code to update the values and that is the moment you lose no code people. Certainly, there isn’t only one way to Rome… another could be the "modern" custom elements…
There are even more ways like using anime.js (animation library etc.). The most obvious… key frameable SVG animations would be the best, though.
If it is mandatory to put the code of an SVG into a Rectangle, then it means that a JavaScript can manage the content of that SVG, right?
Let's say that I have groups in the document.
Can I call with a JavaScript to hide/make visible a group of the SVG?
Here's an example attached. STAR-2.svg.zip (4.5 KB)
As you can see, there are two groups: BASE and COULEURS.
The attribute to show/hide is display.
But I wonder if a JS can play with this.
The displayproperty for svg works the same as for html-elements.
Also the selectors in js do ...
To change an elements attribute the first step to do is getting it.
in your case you've set id's, so here is a on how to get an element by id:
https://www.w3schools.com/jsref/met_document_getelementbyid.asp
one possibility to change its style:
https://www.w3schools.com/jsref/prop_html_style.asp
Hi, thank you, I'm not a developer and from what I understand these codes listed on the sites you mentioned call for an ID. Is this the ID of each group?
Did it! But realized why it didn't work. A double-click on the button is necessary to make the JS work the first time. I have inverted the logic in the JS so that it inherits the hidden status. Now it works great.
testLayers.hype.zip (18.7 KB)
great!
another approach to achieve the same could be to toggle a css-class to remove/apply its styles:
https://www.w3schools.com/howto/howto_js_toggle_class.asp
That's level 2, but more complicated for designers as they need to create Graphic Styles in Illustrator. With duplicated objets on layers, it's much easier to play with IDs.
Bonjour
un premier appel de la fonction "layers" with onLoad ou sur le timeline évite le deuxième appui sur le bouton.
a first call to the "layers" function with onLoad or on the timeline avoids the second press on the button.
Yes, I just solved the problem by inverting the logic in the JS as the items were first hidden.
Not it works on the first click.
I'm not a developer but here I drew everything in Illustrator by optimizing the elements so the SVG code is clean and accessible.
Then wrote all the JS functions.
And edited the texts and their positions without a roundtrip to Illustrator.
Welcome to the club of „scripting“. Not really developing but applying some logic in a syntax led language instead of the sequential action stack you find under interaction. It comes down to a similar logic, but an open syntax is more powerful (but sometimes confusing to look at). I really love this about Hype that people actually cross this threshold occasionally. That said, there is much more coming for the stackable actions sector very soon. Congratulations on the map looks really nice!