Hi all, I’m running into issues with Webflow modifying HTML embed content. I’d thought that had been fixed, and am trying to find out what the rules and limitations are now?
The most common scenario is when I need to wrap a Webflow element (e.g. a checkbox) in surrounding code and DIVs that I need to generate literally, for a jQuery component integration. This requires putting one embed before (with opening tags), and one after (with closing tags). Webflow appears to auto-close them?
Here’s a walkthrough of what I’m trying to do and where it appears to be breaking.
Note that you can ignore my discussion of forms validation and required field alerts- I now realize those indicators are browser-generated, and not Webflow-generated. I suspected it once I couldn’t find them in the javascript.
Webflow recently said they were stopping to auto close your elements, leaving you with the reponsibility to input clean and valid code. I just tested adding non closed divs and they’re closed by Webflow, still.
Anyway, what you describe — opening an element in a custom code component and closing it later with another custom code — can’t be done with Webflow. The custom code component is an element itself, it’s a div. You can’t open an element inside of a div and closing it inside of another div. So even if Webflow was actually not auto closing your elment, you wouldn’t be able to do so.
Thanks a lot @vincent for clarifying how custom code works!
The custom code component is an element itself, it’s a div.
As you say, the embeds require at least an opening and closing div, so the minimum embed (an empty one) will looks like <div class="w-embed"></div>. Unfortunately, I can’t think of any ways to make this kind of wrapping work with embedded elements and forms as they exist today.
I just tested adding non closed divs and they’re closed by Webflow, still.
One clarification about non-closed divs and other custom code: we still don’t update the code inside the embed elements today. We changed that behavior a few months ago (when that post was published) and that continues to be the case.
If you’re seeing closing tags that weren’t originally in your custom code, and you are looking in the browser HTML inspector, it might be your browser trying to “fix” the HTML of the page. Browsers try to auto-close tags, fix attributes, and a lot of other actions in order to improve the user experience.
To be sure you’re looking at the actual HTML being rendered before the browser “patching” takes place, you can open the DevTools (View->Developer->Developer Tools in Chrome) and go to the Network tab. You can click on the first item in the list, which will show the actual HTML that is being rendered from Webflow:
@vincent, the custom-code-is-an-element perspective clarifies things a lot. I can see that in action in other places in my page design too, such as where I’m generating jQuery chunks to insert ComboBox items from the CMS. Every chunk is wrapped in a DIV.
@javi yes I was using Chrome’s View Source, directly from the right-click menu. I thought it was unadulterated since it’s pre-script, but I’ll compare it to the Network view, or Fiddler next time I need to verify what WebFlow is actually generating. That raises some interesting questions, regarding which HTML variation my jQuery code is acting on.
