Parent container width used instead of device width for responsive breakpoints

Responsive Responsive Layouts
1

Hi, we’re using Hype now for the past year or so to generate animations on the hero element of our website @ librio.com

The hypes we create have 3 breakpoints set, mobile, tablet and desktop, which should match one of the 4 breakpoints we use on the site, mobile (hype mobile), tablet (hype tablet), small (hype tablet) & large desktop (hype desktop).

The breakpoint sizing is where the issue arises for me, because hype appears to calculate breakpoints based on the width of it’s containing element (or the HYPE_document class), rather than using the size of the window/document object?

We embed the script tag from the export of the animated content into a parent container which is set to 100% on mobile, but has a gutter on larger sizes. This means that as the device width expands approaching the tablet breakpoint, there is a point (723px) when the mobile containing element is larger than it is at the tablet size.

If we set the breakpoint in hype to switch up to the tablet scene at 768, it will completely skip the site tablet size, because through that whole breakpoint, the hype’s parent element is only 722px no matter how large the device width expands.

So my question really is;

  • why does hype use the parent container width instead of device?
  • is there anything we can do to make it correctly use the device dimensions instead?

I tried simply moving the HYPE_document class further up the DOM all the way to the body tag infact, but this causes other undesirable behaviour with the layout, so for now is not an option.

Apologies if this is confusing to read, it’s difficult to explain, and it took me quite some time banging my head against the wall to realise why the hype breakpoint resizing was behaving so strangely. Also apologies if this has been asked before or documented in the guides, I couldn’t find anything about it when searching, and I’m also not the designer, so unable to test things quickly, I’m just responsible for integrating the finished product.

Thanks in advance, would appreciate any help with this!

2

Hypes API has got an event called LayoutRequest. it offers the opportunity to show up a layout of your choice … may help …

1 Like
3

Thanks for the reply! Hmm, we already need to handle some other responsive dependent behaviour so not too big a deal if I should handle the layout switching manually in js.

Is this just how hype works? There’s not some parameter that can be toggled (may have erroneously been toggled) to change the focus of width detection from container to device? That’s ok I guess, it just seemed odd that this was the default behaviour.

4

that is definitely not possible. You can search the forum for replies of @jonathan regarding breakpoints. he did some explanation here and there.

1 Like
5

Since folks embed Hype documents into the DOM structure, Hype will look for what it is able to fit into – this would be the properties of the parent. If the Hype document can look up with loving eyes to the body or html tag as a parent figure, then it will fit into its available width and height. We understand this is a tough thing to plan ahead for since you’re working with whatever available space + breakpoints a theme library or css framework gives you. Here’s a document that might make planning for this a little easier:

SizeDetector.hype.zip (55.2 KB). It outputs the detected offsetwidth and offsetheight, which are the specific values Hype looks for when fitting into a container. Here’s how that would look within a Wordpress post:

So this will give you information like: for my theme, when viewing on a 320px wide device, the actual available space (because my post has padding on either side) is 271px.

Hype does have the ability to set viewport values when Hype controls the HTML. Check the ‘viewport width’ options in the document inspector.

1 Like
6

Thanks both for your responses and that’s exactly the issue Daniel, yup.

Unfortunately, I have to say in that case; hype’s labelling is a little strange, and the wording of ‘breakpoint’ a bit misleading. I can understand why it’s called that, but by pretty much any definition I could find, breakpoint is taken to mean layout based upon device dimensions, not the parent container. Oh well, I guess at least if anyone else runs into this they may be able to find this forum topic at least.

As for how to proceed, I’m wondering whether you have plans to change to device breakpoint layouts, or add the option? perhaps the combination of setting viewport dimensions by device-width could switch the object inspected for offsetwidth and height, to be the body instead of the parent container?
For now, we’ll continue with the broken way we are doing them, and in the meantime I’ll look into the layoutRequest / Hype LayoutKit (Layout Extension) for handling responsiveness manually.

Thanks again!

7

Element based breakpoints is a thing that makes the most sense as you would react to the space given to your Hype Widgets and not the Page as Hype isn’t a page development environment. Hence I never considered it broken and if you use Hype with 100% width you can use it with no margins like you intend. Then again using it with custom media queries is also possible and setting the needed layout based on the page width shouldn’t be a problem using the mentioned callback.

1 Like
8

Thanks MaxZieb, I didn’t necessarily mean to imply the way hype does it is ‘broken’ - after all, plenty of people are using it just fine as it is - I meant more that we had had to ‘break’ our standard breakpoint definition, in order to get the correct scenes to show with the minimal overlap of wrong layouts.
Luckily for us, we can reduce it to just a single overlap, at the very wide end of the mobile where it switches prematurely to tablet. I can imagine this would be a lot more of an issue if our design had multiple variable width content areas at each breakpoint… for example, consider a 3 breakpoint layout with a centered hype container area set to 90vw, 80vw, 70vw (or similar) for the respective mobile, tablet, desktop. With pretty standard breakpoints you could easily have 4 overlapping layouts.

Anyway, it seems using the callback and/or using your layout kit extension is the way to go as long as the breakpoints behave in their current manner. :+1:t3:

2 Likes
9

btw you can change hypes breakpoints in the scene-inspector independently from any layoutsizes … have you tried this?

1 Like