What happened to the element ID information?

Elements
1

In previous versions of Hype, the Unique Element ID field was populated with a fairly long string of data.

In this version, (pro 3.0.3), that information is no longer available. All I see is the text ‘Automatically Generated’. I can enter anything I want to into this field, but the Hype docs explicitly recommend against doing that, using the program-generated version of the element ID instead.

But there is no program-generated version.

So … how am I supposed to do a getElementByID now?

2

Where does it say that ?

3

Where does what say what?

4 
var x = element.id
alert(x)

Or just give it an "id" of your own

2 Likes
5

Can you tell it’s been a long afternoon?

I was more interested in getting at it through the Hype UI, but loading it through a variable is actually better, I think. Thanks.

1 Like
6

I think it was obvious to what I was referring to.. :wink:

7

No, it really wasn’t; in my OP I made reference to a couple different things, each of which contain content of some kind or other: The ‘Unique Element ID’ field, and the Hype documentation.

Here’s the documentation I was referring to, though:

hypeDocument.getElementById(id)

Searches the current document for the specified id (entered through the Identity inspector’s “Unique Element ID”) and returns the DOM HTML Element. This is similar to the typical document.getElementById, however the API version should be used instead as Tumult Hype may reassign ids in cases of collision.

Here’s where it is online:

http://tumult.com/hype/documentation/3.0/#api-functions

The part that stands out to me in the documentation is this: ‘The API version should be used instead as Tumult Hype may reassign ids in cases of collision.’

8

What it is saying is there are two ways of getting the id using JavaScript.

outside of Hype in normal JavaScript you would use:

document.getElementById(id)

And within hype.

hypeDocument.getElementById(id)

But they recommend, that although both will work within hype, when in hype you use the hype version for the reason stated.

2 Likes
9

Ah, now that makes a bit more sense. Thanks!

10

@MarkHunte gets it right. To elaborate more on the ins and outs...

Hype 1.0.x would generate an element ID for you that was shown in that inspector field. You could then get access to the element via document.getElementById(). We changed this to its current behavior in 1.5.0 for these reasons:

  1. Animations might not work correctly due to ID collisions (more on this below)
  2. Users (rightfully!) wanted to be able to specify their own IDs instead of use the ugly UUID strings Hype made
  3. We could significantly reduce the export size by not using such long UUID strings

The element ID itself is used by Hype's runtime to manipulate the element. It isn't just for you, it is for us too :smile:.

When we generated a specific ID, even though it was really long and unique at the time of generation, there was still the possibility of collisions if you had multiple Hype exports on one page, whether it was an identical animation or due to a copy/pasted element (or duplicated document) that happened to contain that ID. That would mean that we might be animating the wrong element (#1).

We could handle this problem (and #3) by automatically generating IDs when the document is shown on the page. We simply need a small internal ID and then map this to a longer DOM Element ID that we generate. This DOM ID we can basically guarantee not to collide, because Hype's runtime calls document.getElementById() first to make sure it doesn't yet exist on the page. So with this, we just say "Automatically Generated" in the inspector, because we really don't know what the ID will be and we don't want you to know to mitigate a collision problem.

However, this doesn't solve #2, where you do want to specify an ID. For this we need another mapping - the user's intended ID to an actual element. In this case, we do the same basic steps, but instead of generate a random ID when the document is shown in the browser, we try to map it to what you said in the inspector. For the most part this will work fine, but if the global document.getElementById() returns an element because you already have something in the HTML page (either specified by your code, someone else's code, or a duplicate Hype element), we can in fact make sure there's not an ID collision and rename the ID to be safe. HTML documents shouldn't have more than one ID, and that would mess up the runtime as it still needs to use an ID!

Of course, if we rename it, then you cannot get to it via document.getElementById() with the string you expect. Not that you'd be able to otherwise - there's really no way to know what you'd be getting in the case of a collision. So, we added a hypeDocument.getElementById() API which is smart enough to return the right element by the ID you specified, even if Hype's runtime actually had to change the ID on the HTML page.

So in short, use hypeDocument.getElementById() where you can - that will return the element you want and be safe against any collisions which might have happened. If there are no collisions, document.getElementById() is going to work too. But given many of us don't have complete control of the content we're using or putting on the page, we strongly recommend using the hypeDocument variant.

And just to clarify:

Please do add IDs whenever you need to use them!

2 Likes
11

Thanks Jonathan & team tumult.

12

Thanks for the background; I thought I’d remembered ID’s being Hype-generated originally. This newer way, with user-settable parameters, is far more flexible and useful, I think.

Muchas gracias all!