Is this seriously not possible, but updating the background color is?
$w.onReady( function () {
$w(‘#html1’).onMessage((event) => {
var data = JSON.parse(event.data);
if (data.height) {
document.getElementById(data.id).style.height = data.height;
}
});
});
It’s seriously not possible.
WixCode understands all of Javascript, except for anything that accesses the DOM. This keeps the user from inadvertently “breaking” something. Accessing document elements such as div, span, button, etc is off-limits. The way to access elements on the page is only through $w.
I understand you cant access the dom directly. Mine was just an example, but if I can use $w, then how can I update the height of an element. I mean come on, I should be able to resize an iframe dynamically. If not Wix has a design flaw if you cant update the height or widget of objects which would mess up the site structure.
@info59086 It’s not possible to change the size/location/attributes of a component on the page using code.
Feel free to post a Feature Request .
@yisrael-wix How about now? Is it possible now to access the DOM?
Is this still the case? I just added a bunch of code to have my iFrames and parent pages talk to each other so I could know an exact height to set the iFrame to.
If this isn’t possible, I’m going to try some wacky workarounds like setting a line height on a text item with one character, or something, next to the iFrame and see if that works.
Actually, I can’t do a workaround do change the iFrame height, and the more I’ve looked at the forums, I see that this is just not doable.
Frustrating. I was so excited to finally not have forms embedded in iFrames not have spacing issues on our pages.
Perhaps there is even another workaround.
It is just an idea, but perhaps could work.
You are searching for something what is some kind of moving elements / resizing elements on your page page, right? → some kind of responsivness?
Let’s say you want to place a → BOX <— somewhere on your page.
Yes, you won’t be able to replace the placed BOX by changing it’s x/y-coordinate on the page…
And no you don’t even have to ask for such an Feature-Request, it was already done years ago…
In the meanwhile the animation-api exists, which perhaps could handle this, not sure → never tried this.
There are also other very interessting requests already made, to solve the responsivness and the moving/positioning of wix-elements issue a little bit more.
This one also could be from my own, very useful!
However back to your problem.
IDEA:
-Placing an HTML-COMPONENT on your page.
-allowing it to go → FULL-SCREEN
-managing all the rest inside the HTML-Component.
-drawing/creating/generating/moving and placing your wished elements inside HTML-Component.
Since your HTML-Component is sized to your whole screen, all you would have to do is to CODE all the COMMUNICATION between PAGE & HTML-Component.
Example: Taking this CSS-CODE as example…
div {
width : 300px;
border : 15px solid green;
padding : 50px;
margin : 20px;
}
You can’t do it directly on your page, right?
But sending it into the HTML-Component would make it possible to be done.
So now you would be able to draw/generate and also do movements of your wished objec.
And since you are working on FULL-SCREEN you should be able to code some kind of RESPONSIVNESS.
But all this is just some theoretical thoughts, i do not know if all that will work, like described!
Test it on your own and let us know, if you could do some progress. 
Thank you so much for the time spent composing this, but neither moving elements nor using the full screen view work for my context. I need to change the height attribute of the iFrame component.
Maybe the full screen one if I have to, but honestly, at that point, I might as well redirect the user to another server where the forms are hosted and just replicate the header on Wix.
Another approach/idea would be to use → MULTI-STATE-BOX including different sized HTML-Components on each of the MULTI-STATE-BOX states.
Example: MSB = Multi-State-Box
MSB-state-1 → includes a html-Component sized 200x200
MSB-state-2 → includes a html-Component sized 400x400
MSB-state-3 → includes a html-Component sized 800x200
MSB-state-4 → includes a html-Component sized 600x600
and so on…
Now you can simply choose by code, which STATE of the HTML-Component to show on screen.
I might as well redirect the user to another server where the forms are hosted
Yes, perhaps this would also be a work-around solution.
@russian-dima Very clever idea, but the problem is that the height of the iFrame is often off by 20 or so pixels, making it scroll, thus capturing the scroll event for the page and messing things up. I could overshoot the height, but then I end up with a huge whitespace at the end of that page.
I really don’t get how other people deal with this. I feel like I’m missing something obvious.
@arlo You are missing Editor-X. 
I think you are clever enough to understand WHY the normal editor will never have a real 100% RESPONSIVNESS, right?
@russian-dima I don’t know that I ever used Editor-X. I started messing around with this when it was called Corvid.
I just want to set the height of an item. That’s it. 
We’ve had it on our to-do list to move off Wix forever, and I keep finding workarounds to hold us over. I have a decent amount of custom code on a lot of our pages just to deal with their shortcomings. I even have a system that’s pulling remote data instead of using Data Collections, because even they are too restrictive.
I feel like Wix has never been for professionals who know what they’re doing. It’s too restrictive and the minute someone wants to do something special it’s time to self-host. Some regulars here will always praise Wix on how advanced and great it is… sure… for a website builder for beginners, I suppose, but even the beginners I deal with find it slow and complex. So I’m glad they’ve found an audience, I guess.
Who knows… maybe they’ll figure out how to “securely” let users adjust the height of items. Its not like it’s an unknown problem on their end. When text changes with dynamic content it changes the height of the containing div. It’s not rocket science.
@arlo On other side do not forget, wix rolls out time after time new APIs, so let’s wait →
maybe patience will pay off. And in the meanwhile we do, waht we already done all the time before → searching for working workarounds 
@russian-dima I wonder if the Custom Element might be the needed workaround for this.
I was excited for a moment because I found “Match Size” in the plain editor, so I took the height of my iFrame I get via a message, and attached it to a text field where I divided the height by the line height, and filled that text item in dynamically.
Turns out match size only works when you’re laying out your page. It doesn’t apply some internal CSS to the objects. Boo.
So I’m going to look into Custom Elements tomorrow. If I don’t see a path there, I’m dropping this.
@arlo Perhaps anybody else has also some ideas for you, who knows. Don’t give up.
Alright that might be a doable workaround but the fact that simple height changes are not possible for Wix DOM elements is just wild. Especially if you consider that I followed that issue in 2019 and people are still trying to find a solution.
And this is exactly the fact, why i posted this one…
Just imagine what happens with editor-X → if…ah come on, you know the rest of my thoughts…, or at least you can imagine it by your own
