Hype emits elements in DOM div order that does not match tool view

While working with turn.js, I noticed that my pages (modeled in hype element groups) were coming out in the wrong order in the client DOM (check on Chrome and Safari). My page/groups were created some by hand and others by copy/paste and drag into order. After some frustration and hacking, it seems that Hype is emitting elements in a DOM order that does not match the order the elements are shown in the Hype tool. It appears OK visually in the client because of the z-index that does reflect the order of the elements in the tool view, but the DOM order of the element divs is unpredictable and thus hazardous to any other JS frameworks that are expecting a predictable DOM order.

I believe this is a bug in Hype since the DOM output is not predictable.

I made a simple example:

Hype Tool view:

Client view (Chrome on Mac mini M1, latest Big Sur):

Elements from the client DOM:

<div class="HYPE_scene" id="hype-scene-19TURTVTF9WXUYLRG802" hype_scene_index="0" style="background-color: rgb(255, 255, 255); display: block; overflow: hidden; position: absolute; width: 600px; top: 0px; left: 0px; height: 400px; transform-origin: 50% 50%; z-index: 1; opacity: 1;"><div class="HYPE_element_container" style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; pointer-events: none; z-index: 4;"><div class="HYPE_element" id="TheRedOne" hype_scene_index="0" style="pointer-events: auto; position: absolute; border-style: solid; background-color: rgb(237, 27, 19); border-width: 1px; border-color: rgb(216, 221, 228); overflow: visible; z-index: 4; width: 95px; height: 264px; transform-origin: 50% 50%; transform: translateX(176px) translateY(32px) rotateY(0deg);"></div></div><div class="HYPE_element_container" style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; pointer-events: none; z-index: 1;"><div class="HYPE_element" id="TheBlueOne" hype_scene_index="0" style="pointer-events: auto; position: absolute; border-style: solid; background-color: rgb(52, 76, 237); border-width: 1px; border-color: rgb(216, 221, 228); overflow: visible; z-index: 1; width: 238px; height: 240px; transform-origin: 50% 50%; transform: translateX(105px) translateY(44px) rotateY(0deg);"></div></div><div class="HYPE_element_container" style="position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; pointer-events: none; z-index: 2;"><div class="HYPE_element" id="TheGreenOne" hype_scene_index="0" style="pointer-events: auto; position: absolute; border-style: solid; background-color: rgb(63, 237, 20); border-width: 1px; border-color: rgb(216, 221, 228); overflow: visible; z-index: 2; width: 298px; height: 89px; transform-origin: 50% 50%; transform: translateX(75px) translateY(109px) rotateY(0deg);"></div></div></div>

The Hype runtime DOM order is based on a top-left element location. This is to better help accessibility/assistive devices which use DOM ordering to read out the ordering of elements. We intentionally made this change in Hype v3.6.

I'd be curious as to your use case for depending on a DOM ordering?

As older versions of Hype did DOM elements by z-index; we left this behavior in the app through a hidden default which you can enable by typing this into the terminal:

defaults write com.tumult.Hype4 elementInsertionOrderSortMethod "compareByZOrdering:"

To get back, use this command:

defaults delete com.tumult.Hype4 elementInsertionOrderSortMethod

(and if using the setapp version, change the bundle identifier to com.tumult.hype-setapp)

However, this does in no way guarantee that the editor will ever be the same as the output, simply that the output is ordered in a specific way.

1 Like

Blazing response time!!!!
The use case is turn.js, a jQuery plugin that produces lovely page turning book widgets (http://turnjs.com/docs/Main_Page)

image

So they depend on the DOM order for page ordering.

I did apply your hidden default with fixed my example, so I am good to go for my application.

I understand the need to use top/left ordering for screen readers.

Perhaps this should fix should be promoted to a scene level option so its more available?

Kudos on Hype....after 40 years of coding, its one of the most delightful tools I have ever used!

Regards,
Sam

Great - I'm glad that was able to solve your problem!

That is definitely a reasonable use case for having the option. While there's always hesitation at adding new and difficult to concisely explain options in Hype's UI, I've filed this in our tracker so we can see if other needs come in that might make us re-prioritize it.

Thanks for the kudos!

Nice… new addition to Hype Cookbook unlocked.

3 Likes