I am using the blueimp/jQuery-File-Upload basic plugin.
In a form, the input field for uploading files is, by default, on the right of the button.
A text is also written into.
How can I have the field on the left and how can I get rid the text ?
What you are talking about is standard browser behavior. When you use <input type='file'>, the browser chooses how to render that, and it can give it its own default text like 'Choose file'. I have used a workaround in the past which works nicely, provided in the link below (which will scroll you to Romas' answer). Basically you hide the file input, and declare another button that you style however you wish.
In JavaScript can I make a "click" event fire programmatically for a file input element?
Related
I'm looking for a way to use a script to change the text of a 'Submit' button in Google Form, as well as the helper text.
Since there is no way to select the output language of the form (it's auto generated base on browser settings) I would like to know if there is a way to create a script that will change the text of the said button as well as the text helper such as 'Your Answer' in the textboxes.
I would like to change it so it becomes bilingual "Envoyer / Submit".
The http://...../viewform?hl=fr trick is NOT working and therefor I cannot offer my user a choice of language.
I want to "prevent browsers from prefilling form inputs when hitting the "back" button". Indeed, I want the initial values to be filled in (added via jsp), not the browser's (cached) values.
Solution 1: I found out that this can be done by disabling the browser caching for the current page. This seems a rather extreme solution considering that I "only" want to disable this prefill feature for a "form" (hence disable caching for the form only, not the whole page).
Solution 2: Then, the obvious next solution is to use javascript: that is, store the initial value in a data-* attribute, then, on page load, replace the input value by the initial value if they differ.
Both solutions seem rather unperfect (these are rather work arounds) I turn to you guys hoping to hear of a better one.
Resources:
How does SO's form remember previous input values?
Disable Firefox's Auto-fill
Pressing back prefills inputs with value from right before submit
HTML form values and 'Back' button
The first thing that comes to my mind is to use a <input type="reset"> button. These aren't seen often nowadays because the user rarely actually wants to reset the form, but here it might just be what you need.
You could also do it in javascript on page load with form.reset(); instead of providing a button for the user.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLFormElement.reset
This is similar to your solution 2 and thus still a workaround of the browser behavior, but it is a(n old) part of standard forms and I think it'll do the trick with very little additional code (no need for data-* attributes), so wanted to throw it out there.
I need editable text in an Apache Wicket Application. As the text has to appear very "common-table-like", with editing only after the user double clicks on the text and so on, using normal TextFields is not really an option.
So I decided to go for the new HTML5 attribute contenteditable, which does the overall job quite fine. With the following markup and Java code I get a label that looks like static text, but after the user clicks inside the text is editable:
<div wicket:id="id" contenteditable></div>
...
item.add(new Label("id", "dummy content"));
But now I obviously need to catch some event when the user actually edits the text, as the new text should be stored back into the database. Online manuals suggest using oninput as it seems more reliable (e.g. with respect to timing issues) than onkeyup, onkeydown and so on.
Trying the event with regular HTML5 works fine:
<div wicket:id="id" contenteditable oninput='alert("oninput");'></div>
My question is now, how can I get the Wicket Label to support oninput? Overriding it and creating a custom label would be a perfectly fine solution (if I really have to), but for that I am too new to Wicket as to know where to start and how to create the correct markup and so on.
Since a div is not a form element, it doesn't get submitted when you post a form. So you have two options:
in onInput fill a hidden form element with the content and submit that using a form
send the content to the server using Ajax
Both require you to do some magic using a (Ajax)Behavior.
You can use Wicket's HiddenField to create the hidden field, and in onInput perform the update of the HiddenField's value.
You can encapsulate this by creating your own ContentEditableFormComponent by using FormComponentPanel as a starting point.
I have a text input within a custom footer. I am trying to update the text using:
$("#navbar #segment").val("blah");
I have also tried
$("#segment").val("blah");
both return objects, but neither show an updated text input. The footer the input belongs to is not shown at the time, and I think this might have something to do with it since performing the same actions works when the panel is displayed. I have also tried adding $.ui.updateNavbarElements($("#navbar #segment")) after each call and it throws an error.
Also, what is the difference between the jq.web.min.js included in the appMobi XDK and the jqMobi script located on the CDN? Are they they same, and just the CDN is the latest?
I was correct in assuming that changes are only reflected if the element is showing.
I have a ASP.Net web form that contains both text box fields and hidden fields. The hidden field values are modified dynamically using client side JavaScript. Posting the form, inspecting the values and redirecting to another page is all working as expected.
However, when I use the browser back button to display the previous page then I expect so see that ALL form fields are still populated with the values that were posted.
In IE and Firefox this is the case for both text and hidden input fields.
In Chrome this is ONLY the case for text fields. The value of hidden fields is lost.
Is it true that Chrome never repopulates dynamically set hidden form field values when navigating the browser history?
I have put a small sample together to demonstrate the problem and can provide that if required. I wanted to first ask the question to see if this is well known behaviour and something I have to accept.
This problem could be solved using a small trick.
The problem is Form fields with Type=hidden with Dynamically set values are not handled properly by the Chrome Browser.
So the solution is to change the type of the field to text and use some other method to hide the visible text boxes. This could be achieved by surrounding all the text boxes carrying values intended to be hidden by a DEV tag pair and assigning the style as display: none
Then on the page you wont see the text boxes carrying hidden values and it will work properly with JavaScript of the browser.
BEFORE
<input type=hidden name=item_no value=00001>
AFTER
<div style="display: none">
<input type=text name=item_no value=00001>
</div>
You should not rely on this behavior. It is different among browsers, even among browser versions. This behavior is not described in any standards. If you want your fields to have specific values, you can use cookies, or always make requests to the server when page loads, or use more modern methods like local storage (it is not widely supported though).
I can't seem to comment, maybe my rep too low but felt this is important to mention.
I just ran into this problem myself in Opera so borrowed Sanesh Fernando's solution which worked around the hidden fields not being reinstated (Thanks Sanesh). However what caused a problem for me was that Javascript fires before the form fields are updated so if you check values with javascript as I was doing then I had to add a setTimeout to ensure Opera updated before I checked the values.
Cookies are as stated another way but what with the ridiculous EU directive on requiring cookie usage agreement from the visitor it's not a solution for me.