What happened to being able to drag an input outside of a form holding Alt on Windows???
2 Likes
Hi @danborgia, thanks for your post. The ability to alt+drag for forms has been removed, it is no longer possible to directly alt+drag.
If you need to use form elements outside of the built in Webflow form block, that can be done but you would need to use a manual html forms tag and use that with the Custom code embed feature.
Thanks in advance.
1 Like
Oh nooo! Why would they do that??
I was in the middle of building a few web applications using Custom Code and pulling HTML from my Webflow pages. I am a big fan of Webflow, it is by far the easiest tools to build the HTML, and I know the whole point of No Code, but was wrong with input fields outside of forms?
I will try that option, if not I may have to build on Webflow and export the HTML and host it somewhere. I will keep informational part of the Website on Webflow, but as for the apps, that I will have to figure out now.
Ok so far I found out that using a Forms element doesn’t force me to put a submit button, I can just use a normal button and handle input elements with my Custom Code. This may not be so bad after all.
1 Like
Have you also got rid of being able to alt-drag/click to put embeds inside link blocks? Why would you do that to us, guys? 
Hi @dram thanks for your feedback and question. The actual ability to use the alt+drag was not an official feature, it was a hidden option that some designers have known about to enable a “free” mode when placing form elements on the canvas.
With these free mode forms ability, this can in some cases result in code conflicts with other components we have in the designer so the decision was made to keep the forms functionality in line with other existing and new component architecture and support.
I would say that it is not impossible that this would be re-enabled in the future, however it would have to be something put on the Wishlist so people could upvote and comment how they feel about it at https://wishlist.webflow.com.
This decision was not made lightly, if there is a compelling reason then put that on the Wishlist, our team is always willing to listen to understand how many people are using this feature and why they are using it.
I know that any unexpected change can be frustrating, this particular change only impacts to a relatively small % of our overall users and there are still the manual embed code methods that can be used. Existing sites with form elements placed outside of form blocks also continue to work as before, this only affects to new designs.
But I wanted to ask about the embeds and links not forms at this time. Links with inline svg’s inside was a great way of using said svg’s for gfx that could change colours on hover (or with any other action ix would allow), and as icons for links. Now this ability is gone and we should rely on something else (not even sure what at this point)
Hi @dram, thanks for your message, if you are referring to html embeds within link blocks, that has not been supported for a long time, if you try to drag in an html embed into a link block a message will appear indicating this is not supported.
I might be misunderstanding what you are trying to do with the embeds and the links.
Not really. It was possible with alt-click until this recent change that affected both form elements and embed.
Hi @dram, ok thanks for clarifying that, I did not know that myself, as I mentioned, the alt-drag was not really a feature, just a hidden trick that one could previously use to manage the “free mode” for an element.
I would recommend to post on the wishlist to describe why this is needed in the projects and if enough people ask about this then it could be possible that it be returned.
Hi @dram, thanks for your patience. The embed functionality has now been allowed to allow for free mode action with html embeds, those can now be placed within a link block.
Let me know if any questions.
4 Likes
Fantastic, thank you guys!
The “no-code” space is growing but no platform covers all the bases. I’m troubled there is not a css ‘overflow-x’ which creates a div that scrolls horizontally… I digress…
Not being able to place a text input without using a form block was driving me nuts so I developed a workaround that works well for me.
I wanted to capture text input and append it to a HTML GET request without going through Zapier or Webflow.
I put a div with an HTML embed field for code in the page. The HTML looks like this:
<input id="entry" type="text" name="box" value="Click in search box" onkeypress="handle(event)" onfocus="clear()"/>
That creates the Input field you can style class=“myInputClass” Styling input in Webflow is a good way to go but then apply the class name to this one as well.
Then the JavaSript and jQuery:
<script>
// First clicking into the data entry field will clear what is there
$('#entry').on('click', clear);
function clear(){
$("input:text").val("");
}
// Then typing letters echoes them in the input field
function handle(e){
var key=e.keyCode || e.which;
// or if it's the [enter] key then do something - load the page again...
if (key==13){
loadThePageAgain();
}
}
// or if you have a button (id = myButton) for mobile devices handle that...
$("#myButton").click(function() {
loadThePageAgain();
});
function loadThePageAgain (){
// capture the value to put in a GET request below
var whats_in_the_entry = $("#entry").val();
var newSearch = '/YOUR path to this page/?search="' + whats_in_the_entry + '"';
window.location.href = newSearch;
// reloads the page
}
when the page reloads… you have to capture the new value you just sent.
var myUrl = new URL(document.location.href);
var search = myUrl.searchParams.get("search") || "NO DATA";
// the NO DATA is a flag
to forego an API call
-like when the page loads for the first time.
</script>
Enjoy