Signup form, placeholder is acting like input - html

A client of mine has come to me with an error on his website's signup form.
Please see this url for an example.
All of the fields marked with an a asterisk is required but the placeholders in some (Date of birth, Flat / House number, etc.) are acting as input and allowing the form to be submitted without and actual content being entered.
Does anyone have any idea of a solution?

You could just use "real" placeholders (+ modernizr), instead of faking it. But to solve your problem you could check the value against its defaultValue. You could also do this on the inputs instead of hard-coding the values.
if (input.value !== input.defaultValue && (otherchecks))
And for emptying the input you could use this instead of checking for a hard-coded value
onblur="if(this.value=='')this.value=this.defaultValue;" onfocus="if(this.value==this.defaultValue)this.value='';"

Related

Best accessible way to show a default for a form field

What's the best/recommended way to indicate a form field will have a particular default value if you don't fill it out? I'm especially thinking about fields that are dynamic based on other fields, and wanting it to be correctly accessible.
Think a URL slug. When creating an account, if you fill the field out then that's fine. If you don't, a value will be generated based on your username. But it won't be the same as your username, just generated from it.
Actually setting the form field seems bad because it makes it less obvious you can change it yourself.
I'm not sure if placeholder text works here, but I assume not. I could do an aria-labelledby pointing to something that says "Default value: xyz" but I'm not sure if that will work, or how well it will be understood by screen readers - especially if it's changing automatically.
Cheers
The best way to do this is to populate the input and expose the fact that it was automatically filled in via the label as an extra bit of information.
Labels on inputs are read once you focus the related input.
For this reason we can generate labels "on the fly" to contain whatever we want.
As such the best option here would be to generate the label on blur of the first input that the second input depends on.
Within the label we add the instructions that explain why this input is already filled in.
We then auto populate the second input based on the input of the first.
In the below example I have appended "URL" to the first input value in order to simulate some sort of transformation from username to URL.
I also remove the explanation in parenthesis if the user has changed the second input value.
$('#iUsername, #iUserURL').on('blur', function(){
var ElUserName = $('#iUsername');
var ElUserURL = $('#iUserURL');
if(ElUserURL.val() == ""){
ElUserURL.val(ElUserName.val() + "URL");
$('label[for="iUserURL"]').text("user url (you can change this if you want, we have set it as " + $('#iUsername').val() + "URL)");
}else if(ElUserURL.val() != ElUserName.val() + "URL"){
$('label[for="iUserURL"]').text("user url");
}
});
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<label for="iUsername">User Name</label><br/>
<input id="iUsername" /><br/>
<hr/>
<label for="iUserURL">User URL</label><br/>
<input id="iUserURL" /><br/>
<hr/>
<label for="itest">I have added this third input just so you have something to tab too, it does not add anything to the fiddle</label><br/>
<input id="itest" />

What is the correct and most safe way to check if HTML form checkboxes and such have been POST-set?

This has confused me since the early days. Maybe it's just in my head, but it seems to me as if this has varied over time, between browsers, and possibly even depending on the local language/locale.
Basically, whenever I need to check if a HTML input of type "radio" or "checkbox" has been set, I always do:
if (isset($_POST['the_name']) && trim($_POST['the_name']))
// do stuff
This just makes sure that the POST variable is sent whatsoever (which in itself doesn't mean that it was actually checked/selected, as far as I can tell, since its "value" can be an empty string) and that it's something other than '' (empty string). It seems like this has worked for a long time, but I have two problems with it:
It's ugly. I need to abstract it into a function, but then I want to know if it's a good idea in the first place, or wrong somehow.
It makes the assumption that any non-empty string value means "checked" or "selected", whereas the standard may say a specific string value such as "on", or maybe any number of such strings depending on the language/locale.
Are there cases where my above code falls apart? Do browsers ever submit POST forms where they include names which have no user input/selection in the HTTP request? Or does the existence of a name in the POST blob mean that that "field" has been actively changed/set/checked/selected?
The idea behind checkboxes is that the value is sent over to the server only if the checkbox was checked when submitting the form. The value can be anything, even an empty string. As long as the field is part of the transmitted form it means the box was ticked.
The value attribute is one which all <input>s share; however, it serves a special purpose for inputs of type checkbox: when a form is submitted, only checkboxes which are currently checked are submitted to the server, and the reported value is the value of the value attribute. If the value is not otherwise specified, it is the string on by default.
This means you could have a form like this:
<form action="" method="get">
<input type="checkbox" name="c1" value="">
<input type="submit" value="Send">
</form>
If the checkbox is not checked when submitting then $_GET will be an empty array.
If the checkbox is checked then the value of $_GET will be:
array('c1' => '');
To check whether the box was ticked when sending the form you only need isset()
if (isset($_POST['c1']) {
// The box was checked!
}
Sometimes you would like to assign a value attribute to your checkbox. In such situations you can use the shorthand operator for isset() function ??.
// Create a variable from the checkbox value or assign an empty string if the box was not checked
$nyCheckbox = $_POST['c1'] ?? '';

HTML GET Form with Fixed Predefined Values

I want to set up an HTML Form which will submit (via GET) a combination of user-entered and predefined values.
To explain with a basic example, see this form:
<form action=“/test.html“ method=“get”>
<input type=“text” name=“foo”>
<input type=“submit” value=“SUBMIT">
</form>
This form would give the url /test.html?foo=____, where the underline is whatever the user entered.
What I want to do is also have other values which are set by me and not the user, such as /test.html?foo=____&bar=presetvalue.
I have tried setting action=“/test.html?bar=presetvalue”, but that doesn’t work.
I could potentially do this with hidden fields, but that seems like a messy way to do it.
I have tried setting action="/test.html?bar=presetvalue", but that doesn’t work.
Submitting a GET form generates a new query string which replaces any existing query string.
I could potentially do this with hidden fields, but that seems like a messy way to do it.
This is exactly what hidden fields are designed for. They are the correct tool for the job.

Putting HTML in a hidden form field in Django

I'm having a problem with a template: I'm trying to display a form for changing a value, in which the user enters the current value in a textarea and the old value is kept inside a hidden field for auditing purposes. This value is generally some HTML, and when I render the page this HTML in the hidden field seems to get partially rendered: the value attribute of my hidden field gets closed by the first quotation marks inside the entered HTML, and the rest of the HTML spews out onto my page. I've tried using the escape decorator but that hasn't changed anything.
Firstly, a better solution might be to keep the audit value in a separate model field defined with editable=False. You can still perform checks against the value in a form's clean method:
def clean(self):
cleaned_data = super(SomeForm, self).clean()
if instance.the_audit_field == cleaned_data['the_editable_field']:
...raise a validation error?
You can also modify the value of the audit field from within the model's save method.
Secondly, assuming you must do it the way you are now, let me address the non-escaped value in your template. I assume you're using something like the following:
<textarea value="{{ form.the_audit_field.value }}"></textarea>
You should instead use the following:
<textarea>{{ form.the_audit_field.value }}</textarea>
Note, the value goes inside the textarea, instead of in the value attribute of it.
An even better way to do it is to simply allow Django to render the field for you like the following:
{{ form.the_audit_field }}

Mystery .x and .y form fields - where do these come from?

Take a look at this login page, specifically, the form in the section labeled Returning Members. As you can verify by looking at the HTML or by digging with a tool such as Firebug, the actual form contains four tags: one each for the email address and password, an invisible input called "memberAlready" that contains the value "yes", and a submit button in the form an image. So far, perfectly generic.
However, if you inspect the form data at the point at which the form is submitted (using Tamper Data or its equivalent on another browser, you'll see that two additional form fields have been sneaked into the response: ACTION(loginCheckout).x and ACTION(loginCheckout).y.
They both have two-digit integer values, which suggests that they're only there to verify that the submitter is an actual web browser and not a robot. Presumably, they are related somehow to the submit button, which is defined as follows:
<input type="image" name="ACTION(loginCheckout)" value="Login" src="/images/login/login.gif">
What's confusing to me is that these extra form fields appear even when JavaScript is disabled in the browser. So they presumably aren't just something inserted by an event handler somewhere.
Furthermore, if you submit the form programmatically (e.g., by running document.forms[1].submit() in the JavaScript console), the extra fields are not generated and the login attempt fails. That suggests to me that the insertion of the fields depends on something outside the basic HTML form submission mechanism. But what that "thing" could be if it's not JavaScript, I don't know.
Does anyone recognize this pattern or have a theory as to how the validation fields are inserted?
Take a look at the code you posted here:
<input type="image" name="ACTION(loginCheckout)" value="Login" src="/images/login/login.gif">
Notice that this is an image input type which is used to submit the login form. The additional values that appear to be injected on submission are simply the x and y coordinates where the you clicked on the image to submit the form. They are not additional values which are injected by JavaScript on form submission, they are added by the browser itself.
Try clicking on different areas of the images and see the values change.
When you use JavaScript to submit the form, you do not click on the image, which is why the x and y values are not included on form submission.
Replacing the image for an <input type="submit" /> element will remove the x and y coordinates.
Hope that helps.
The X and Y values you are seeing are because the submit button is an an input type=image. They correspond to the X and Y locations within the image where the cursor was when the image was clicked. They're added by the browser itself, as the HTML specification requires it. Section 17.4.1 states that for an image input type
When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.
You'll note it only mentions the use of a pointing device. If you submit by using the keyboard the values won't be created.