Layouts feature for Banner building (more options)

Feature Requests
1

  1. What do you want to see in Hype?
    I would like to see a split in the Layouts feature, so us Banner-creators can set a minimal scale size: eg. @media {min-width: 200px;}
    While setting these values it would help if we don't have a full duplication of all the HTML-Tags while adding a new Layout. It is frustration. If you need to set a CSS ID's, so that a AdServer can change its innerHTML oder img, we are forced to go with another route and set CSS Classes. But that should the case.
    It also makes the Banner heavier in size and it downloads a second set of assets for the duplication made by the secondary Layout.
    ...
    My second issue is that in the UI one cannot set an image inside its Parent-DIV to object fit: contain; and set the img width and height to 100%. In Hype it is always forced size with: px.

  2. Have you found a workaround for this problem?
    Don't use Layouts and if we are forced to do so, work with CSS Classes.

  3. Are there examples of other apps with this feature? Or, have you seen examples of this elsewhere on the web? (Please include a URL)
    Here is a preview link where one can see a img grab from an the Website true the AdServer.
    ...
    In the above link you can imagine if the picture injected is not 1:1 to the set size in Hype it will be distorted and not visible right. For a distorted preview see the image below.
    It would be nice we have some more Flexibility in the Hype UI. I don't know how to change it directly inside of Hype.

  4. How high of a priority is this for you?

    [ ] Nice to Have
    [X] Important
    [ ] Can't use Hype without it

Images:

image002
image002924×605 44.3 KB

2

This is true. I mainly don't use layouts because of Portrait vs Landscape orientations. Layouts are good if you have a long scrolling page. But if you have a fixed size, or working on something full screen, Layouts doesn't really help.

I usually end up using Media queries. It seems like Layouts is half the picture. Maybe it should detect orientation too?

3

Will give that a try. Does not give me the solution in setting the images to auto fit if they have different dimensions.

4 
background-size:cover !important;   background-position: center !important;

doesn't that bit of css for the elements with background-images fit your needs¿

4 Likes
5

Like @h_classen said, you can set the CSS to behave like you need it. Either with a CSS class or by assigning it through JavaScript. In the second case, you can supply the important tag as follows:

yourElement.setProperty('background-size', 'cover', important');
yourElement.setProperty('background-position', 'center', important');

Reference:

Also check out the experiments concerning a focal point (in reply to another request you had). In that case, you can play with the focal point using:

yourElement.setProperty('background-position', '10% 50%', important');
2 Likes
6

Thanks guys, I will give that a try.

But do you agree, that it would be nice for non-coders, being able to set these values with HYPE UI?

7

:+1: of course

1 Like
8

Agreed!

1 Like
9

I wanted to chime in and get a little more perspective - is the above the primary reason for the request?

I've been debating some ID behavior that would coincide with some other changes -- specifically it could be the case that we can allow ID reuse in layouts, but this would mean that layout DOMs will get destroyed when not shown or used. (We can't really do this for scenes because transitions show multiple scenes at once).

10

Yes my main reason. I would not mind on a repaint the old layout gets destroyed.

1 Like
11

Cool, thanks!

12

Not sure I like the sound of that.
What happens to persistent symbols. I rely heavily on them especially where a layout may change and a streaming audio is playing during layout change without interruption.

I do assume they will not be touched but I worry they will be affected?

Also would any native js document level code get broken.

I personally dont see the benefit of this.?
I would think to solve some of these issues, better access and use of classes would make more sense.

Also I think id reuse would muddy the waters for not only coders who understand the normal DOM convention but non coders who would use them where they really shouldn’t

2 Likes
13

There would be no change in persistent symbol behavior.

First, this behavior would be optional - turned off for any existing documents and on for any new ones. So it won't "break" documents, but there may be some basic changes required:

  1. If you target an element by ID but this element is not in a current scene/layout (or a "prepare for display" one), it may result in an error. If you have a reason you target unseen scenes/layouts... let me know the use case.

  2. Changes that you make to a DOM element, that wouldn't otherwise be overwritten by Hype anyways, would need to be recreated On Scene Load/On Prepare for Display.

Significant memory usage reduction for Hype documents, and probably far fewer crashes on iOS.

The reason isn't really for layout ID reuse, it is more of a side benefit. I agree that better use of classes is almost always generally a good thing!

14

Thanks,
As an optional user setting makes sense.

I am sure I have done something like that for one reason or other in the past, probably some sort of iteration over elements. Will let you know if I do it again.

Does this also mean that the runtime will have some new APIs like reset current scene or layout etc.

15

showSceneNamed with the current scene name would result in such a reload.

16

Lol. Knew you would say that. :grinning:

1 Like