In today's web applications where there are inline edits, enhanced by javascript etc, how do I markup forms. Eg. in the below web application Speckle
There are
input box for add task
check boxes for task stage
inline textbox to edit task
Is there a need to have a <form> element at all? Do I wrap the whole app with <form> or maybe I have multiple <form> for each inline edit like Speckle? But I don't find any <form> warping the checkboxes
this is a good question. given the nature of web apps tendency to deal in small/discrete ajax updates, then quite often a json object (or even a plain old javascrip array) might be serialized and sent to the server. This is great for client usability.
where the form will come into play is for scenarios where such an approach is not able to be used. many folk STILL keep their javascript settings switched off (for security reasons!!). thus, it may make sense to have the progressive addition of ajax functionality without forms in an environment where javascript is available and full page posts via forms where this isn't possible.
The trend will take some time to adjust before it can be claimed that the web is 100% javascript enabled.
horses and courses - of course... :0
<form> tag always comes with submit buttons. e.g. <input type='submit'> and <input type='image'>.
It is useful when you need to submit your data to somewhere (include this page itself), in which these data such as the checkbox values are handled.
If you don't need to handle this data at all, then <form> is just optional. But adding this tag will also benefit HTML semantic.
Related
So I read a lot of articles that say that HTML 5 form validation is accessible (things required attribute which will prevent the form from being submitted is a field is left blank), yet when I tested my form on NVDA on Chrome and BackTalk on Android, if I hadn't filled in the input, it focuses back to the input field (which is good!) but both screen readers announce "Please fill in this field" which is useless to the user, since they don't announce the label of the field.
So HTML5 validation alone isn't accessible? Also, can you combine HTML5 validation and custom JS?
Do you have to write custom client site validation in order to make forms accessible?
Short Answer
Yes the standard HTML5 validation is accessible and will pass WCAG2.1 AA, but you can do a lot better with some JavaScript.
Long Answer
If you need to support Internet Explorer 9 or below then you will need to use JavaScript (which according to WebAim survey - section "Browsers" still covers around 3.6% of screen reader users).
Native HTML5 validation is a very good starting point, but there are limitations (you gave one in a comment, some screen readers (NVDA) do not announce the label again, meaning a user has to physically ask for the label to be read via controls).
The other thing is that once you leave a field it doesn't normally tell you you have made a mistake until you have submitted the form (it is meant to but this is not always the case depending on your announce speed, settings and browser).
For example updating aria-invalid is useful for immediate feedback (and provides support for older browsers, while being more robust with 'unusual' screen readers).
Using an aria-live region to provide immediate feedback onblur (or throttled / debounced) is also useful and a better solution.
One other thing is that the native validation is not actually very effective. For example fff#fff shows as a valid email and will allow a form to submit on a type="email" field, same with type="url" it will allow https://fff to be submitted (in Chrome at least).
I could go on with other things such as providing better instructions on how to fix errors (especially for things like phone numbers) but you get the idea.
Basically, use as many native HTML5 features as possible to give a solid grounding and a good fallback for JavaScript errors / people not using JavaScript. Then use CSS and JS to improve the experience for everyone.
Also, can you combine HTML5 validation and custom JS?
You can and you should but be aware that you end up doubling up validation (which isn't a bad thing as I stated for fallback).
The beauty is you can use pseudo selectors in your JavaScript to target fields by type, saving the need for adding unnecessary classes etc.
e.g. document.querySelectorAll('input[type=email]') could be used to select any email input for validation or document.querySelectorAll('input[required]') to find all required fields.
You can also use things like max="100" on slider / numeric inputs to set your validation ranges 'on the fly' and still have a fallback for no JavaScript.
As you can imagine this let's you write a library if you can't find an off the shelf one that is reusable on nearly any form.
I am thinking to use the Input Type tags in my web application like
<input type="email">
<input type="number" required="required">
I'm just curious how safe is to use them , Is there any options so the user will disable them from browser.
They are not safe.
You can never count on them being executed.
You can't skip server-side input-checking.
An HTML form is merely an interface for users to enter data. What your server receives is an HTTP request, which the browser builds with the data entered into the form. But anyone can send any sort of HTTP request to your server at any time, entirely independent of any HTML form or website.
Nothing client-side is "safe".
They are safe to use but please avoid the use of REGULAR EXPRESSION.
Some browsers don't support the tags. For example Safari does not support <input type="email">. Instead it will treat it as type="text" and it will accept abc#xyz even though it is a invalid email address. Refer to this Stack Overflow question for further information.
HTML5 is as safe as HTML4 for Input Methods, Your elements should be controlled by JavaScript or PHP and have them validate the data that the user is imputing.
If your concerned about compatibility with the new HTML5 tags then you should use HTML5Shiv which contains best of both worlds.
HTML5 is as safe as HTML4 for Input Methods, Your elements should be controlled by JavaScript or PHP.
Server-Side validation is best way to keep them secure.
They are safe to use. The user can't disable them and if the browser does not support them they will behave like a regular input type=text element
If a browser doesn't understand a type, it will be treated as text. It's impossible to say if users will be able to disable them because there could be an obscure browser somewhere used by someone that people here may not know about. Code defensively (be prepared if it's disabled), but use the features that are out there.
Any older browser that does not know those new input tags will treat them at least as text inputs thus making a server-side check indispensable.
Edit: If that was not clear with my original answer, but I did not meant that only new tags should be checked server-side. I just wanted to make clear that you can not trust the input being valid just because you have corresponding inputs on the front-end.
There are several hidden form fields on my pages that are used for passing data to server side. For debugging purposes, I feel it easier to hide all eligible input fields by just making them all a part of hidden class than setting the type=hidden attribute on each input field.
Whenever I need to debug I could easily modify that class attribute to enter debug mode. Ofcourse both the approaches work in hiding the input fields but I am not sure as to why this approach(hiding via class) isn't much widely used in real life. Can you throw some light on what should be preferred approach ?
<input type="hidden"> won't trigger input validation, auto completion, and other user interaction related events. It's designed to save raw data, without user's direct input.
But a <input type="text">, visually hidden, are still going to be considered as a user interaction component. And on some devices enabled visual aid, it will serve as not hidden, and cannot provide the consistency you expected. That's why it's not preferred to do so.
Eg. a <input type="hidden"> won't auto complete it self, or preserve the inputted data before refreshing a page, or prevent the form from being submitted for a failed type validation can't even be seen.
The CSS approach is bad for usability, and accessibility. Think of someone with CSS disabled (very old mobile phones, people with a screen reader), they won't render your CSS as you might expect, and the input with all of its glory would be displayed to the user.
A hidden input should be used for implied user input, meaning, input that would come from the user, but is implied and does not need to be manually entered.
Your question falls more onto the type="hidden" approach.
I'd recommend using <input type="hidden" /> because it is the standard way of HTML to hold a user's input value. If you use another attribute for type and hide it with css, one problem may arise is that when the css fails to load, the input control will show up.
I think your question is about the best approach for debugging form fields. I recommend keeping them as type='hidden' in your HTML. This is best for you, for your users and for semantic interpretation of the page.
Instead, use a tool like the Chrome Developer Tools to do your debugging. This will let you easily see the values of your hidden fields.
Is it valid to have <input> without it being in a <form>?
Have a process for marking up some fields in pages and just found a page with input fields that where not being marked up as I expected.
It's taken me a while but worked out that the process of getting the form elements then getting the fields is what caused these to be missed because there is no form.
<input> without a <form> appears valid, yes (at least for html 4.01, look near the end of 17.2.1):
The elements used to create controls
generally appear inside a FORM
element, but may also appear outside
of a FORM element declaration when
they are used to build user
interfaces. This is discussed in the
section on intrinsic events. Note that
controls outside a form cannot be
successful controls.
I checked the following with the W3C validator and it confirms this is valid.
<!DOCTYPE html>
<html>
<head>
<title>test</title>
</head>
<body>
<input type='text' />
</body>
</html>
Reference to a more up-to-date specification:
HTML 5.2 - W3C Recommendation (14 December 2017)
A form-associated element can have a relationship with a <form> element, which is called the element’s form owner. If a form-associated element is not associated with a <form> element, its form owner is said to be null.
According to MDN it is possible:
Note that it's always possible to use a form widget outside of a element but if you do so, that form widget has nothing to do with any form. Such widgets can be used outside a form, but then you should have a special plan for such widgets, since they will do nothing on their own. You will have to customize their behavior with JavaScript.
HTML5 introduces the form attribute on HTML form elements. It should let you explicitly bind an element with a form even if it is not enclosed within a form tag. Unfortunately, for the time being, the implementation of this feature across browsers is not yet good enough to rely on it.
I know this question is quite old, however, I have successfully built many complex data entry pages without form tags. Although it isn't considered "standard" by many, it is NOT inappropriate to use inputs without a <form>. My projects were instances where I needed complete control over how the page behaved and the default form behavior was getting in the way. Was able to perform page and field level validation ( using JS ) and "submitted" the data with Ajax calls etc...in fact, this is my preferred way these days.
Lots of JS is required, but its not that difficult and is easily done as reusable code.
There are also other instances where I def do NOT use forms with inputs such as Login Pages.
Hope this testimonial helps someone.
in my point of view , we can use input outside the form and even send data to the server without put the input in the form ,but for SEO and website readability(for visually impaired people)(just the same reason for the some
semantic content tags in HTML5 , like section ,footer, header something like that ), we have to use input in the form tag.It is important that we ensure the code we use is available to all people including the visually impaired people because it is not just about websites, it is about providing access to information for everyone.
Yes, you can have a valid input without a form.
In many prototype scripting cases, it's easier to just stick every form item (such as an input or textarea) in its own form tag. Is there anything wrong that could happen from having lots (like 1000) form tags in a page?
What do you mean by ‘prototype scripting cases’? How are the forms being submitted?
If each form is its own action, eg. you have lots of separate product listings with different REST action URLs, then, yes, a separate form per line is appropriate.
If you're just using controls on their own for scripting, and have no intention of submitting them through the normal HTML form process, you don't need any <form> elements at all, just include them bare.
(Except in the specific case of radio buttons, which require a <form> for grouping.)
Should not be a problem but why do that when you can just use one form. It will work even with 1000 forms but it would be stupid with over 50 anyway.
There is nothing particularly wrong with it, but It would be a better idea to have them all in the same or fewer.
I would say, first off, have 1000 inputs on a single screen poses a different problem that should be addressed first. That many controls will be completely unusable.
That being said, having each element in its own form will cause more overhead in processing your page. You'll have to decide whether the impact of this is too large in your scenario.
You will lose the info from other input elements when submitting any of these 1-input forms, since a form submission ONLY submits the values for input elements of that one form.
If you're OK with that in your prototype, not a big problem
The only thing wrong with this is the semantic process of what a form is. A form should only submit what the fields inside of it have. So, anything related to that "form" should have the proper fields with in it.
Technically, when using a form it'll take you to a new page, so, any of your values in any other form on that page will be lost. The only way around this is using javascript to ajaxily submit the data.
There is no issue with using the HTML markup in the way you are wondering. The only thing you will want to worry about is the more control structues you add to your HTML the more text the web server needs to serve up. This will lengthen the amount of time it takes to get your code from the server to the users browser.