This question already has an answer here:
Multiple form ID's in HTML5's input form attribute
(1 answer)
Closed 8 years ago.
I have a textarea similar to
<textarea name="mytextarea" form="form1 form2"></textarea>
When inspecting the element and viewing node attributes, it shows the form as null. This is in chrome.
Inputs can have multiple form attributes, but can textareas?
It's different from the other question because it pertains to text areas, not other inputs. Though, the result may ultimately be the same.
I received my initial apparently incorrect information from this:
http://www.w3schools.com/tags/tag_textarea.asp
See form on that page. Either way. This can stay closed. It is obviously not implemented in the browsers or ever specified in the spec.
Thanks all.
As this answer states, nowhere on the W3C Spec is stated that the form owner of an element can be a list of IDs. If for some reason, that is working for you, you're still not conforming to standards.
I suggest using jQuery if you want to submit multiple forms at the same time, or duplicate the value of input elements across different forms on submission.
Related
This question already has answers here:
What is the purpose of the html form tag
(4 answers)
Closed 3 years ago.
I am trying to design an application that takes several settings into consideration when processing (scale, height, base-height, etc.). I'm learning HTML, and from looking into it, I can take in user text input through a form. However, I think that I can pull the text from a textarea. What are the benefits of using the form as opposed to manually processing with a textarea?
In short, the <form></form> tag encapsulates the inputs needed for submitting specific information via a specific method/action without needing to define the collection if inputs/selects/textareas with Javascript.
With this ability, you can have a search feature, billing form and zip code locator - for examples - on the same page. The "submit" for that form must be inside the form tags.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
A form is the only way, traditionally, to send data back to the server from the client. Any element inside the form which has a name attribute will be sent to the server when the user clicks the form's submit button, and the server can use the value of any of those elements. The programmer may hard-code the value attribute into the element and the user would not be allowed to change it, such as for checkboxes, radio buttons, and disabled text controls, or could allow the user to change the value, such as for regular text controls. If the programmer does not hard-code the value attribute and it is not an element that allows the user to change it, I believe it gets the values "true", if it is enabled, and "false", if it is disabled. "Enabled" and "disabled" may mean different things for different elements.
HTML before 5 required all of these elements to be in some form in order for the server to obtain their values, and it only got the values of the elements in the form the submit button was associated with, whether or not the elements had a name or value attribute. HTML5 still required the elements to be associated with a form to be submitted to the server, but they do not need to be inside the form anymore. HTML5 has ways for this to happen, usually by adding a form*something* attribute to the relevant elements.
My question is, why did all this come about? What is so special about forms that they became pretty much the only way to send data to a server until recently?
I guess the simplest way to answer this is: it was needed and is still needed.
<form> is an html tag that allows you to perform GET/POST/etc. operations without writing any code in javascript/serverside.
I think that's the simple answer to this question. When there's a need... there's a way.
You can do that in 10 other ways, but the plain vanilla html version is <form>
<form> defines an easy boundary for the user agent to be able to identify all the elements to be submitted to the server. It also allows the user agent to attach convenient default behaviors to the form and the form's child elements. For example being able to hit enter and the form data is submitted. It also allowed for a place to specify where the data would go via attributes on the form element. So all this behavior is available by default without JavaScript. At the same time it also allows easier access in JavaScript via the DOM (form.elements collection)
Why it has changed is because a significant number of sites are now using AJAX to submit the data, and the need for the default behavior is unnecessary in these cases. Often form may be included only as a formality and have no relevant attributes.
So in HTML5 they've allowed the old pattern as well as expanded the capability for developers who may be using AJAX and not need the default behaviors. Or for designers who may need flexibility in where they are placing their form elements (outside of the traditional hierarchy), while at the same time creating connections and keeping semantics alive.
This question already has answers here:
Can HTML checkboxes be set to readonly?
(48 answers)
Closed 8 years ago.
In HTML, only text controls like text-box, text-area, password-box have read-only property. Why didn't they support check-box/radio-button?
I know I can achieve this feature using script by putting onclick="return false;". (I don't want any workaround, I want to know only the reason for not providing native support to achieve this)
But my question is there any specific reason for not supporting read-only in check-box/ radio button even-though it accepts input from user.
EDIT 1:
I found this but it doesn't answer my question - Why there is no native way to restrict the user to change the state without disabling it?
It's important to understand that READONLY merely prevents the user
from changing the value of the field, not from interacting with the
field. For many types of fields, READONLY is irrelevent because you
don't normally change the value. In checkboxes, for example, you can
check them on or off (thus setting the CHECKED state) but you don't
change the value of the field. DISABLED, however, actually prevents
you from using the field.
Notice in these examples that you can set the checkboxes even though
they are "read only":
SOURCE
EXAMPLE from faqs.org
HTML 4.01 allows readonly for input in general without restrictions by type. However, it seems that it was generally not implemented in browsers, possibly because the implementors did not see much need for it. In HTML5 CR, readonly is explicitly disallowed for input type=checkbox, and HTML5 CR (or some other “HTML5 spec” such as HTML 5.1 Nightly or WHATWG Living HTML) is generally what implementors use as the guideline these days.
There have been proposals to allow it in HTML5, e.g. a discussion in May 2011 at the whatwg list, as well as browser bug reports (rejected on the basis of what HTML5 says), but apparently without sufficiently good use cases. Although real use cases exist, they are probably too marginal, and reasonable alternatives can be presented, such as the use of a checkbox image (checked or unchecked as desired) with suitable associated text and, if the pseudo-checkbox is set to checked, a hidden field carrying the desired information.
Use jquery to make it disable(readonly) or enable. Only text fields are possible to make them readable at the time of rendering.
<input type="checkbox" id="chk1"/>
then by using Jquery
$(document).ready(function(){
$("#chk1").prop('disabled',true);
});
First, you shouldn't intersect the onclick event of a checkbox for the mere purpose of checking whether it is checked or not. You should use the onchange event instead. Why? Because the onclick event triggers before the onchange event, so if you intersect the onclick event you will not be able to get the actual state of the checkbox unless you do some ugly javascript acrobatics with setTimeout
If you want to make the checkbox "read-only" you have to use the disabled attribute. Like below...
<input type="checkbox" disabled/>
To answer your question, I think it's better explained by the HTML Specs in W3.Org
The difference between disabled and readonly is that read-only controls are still focusable, so the user can still select the text and interact with it, whereas disabled controls are entirely non-interactive. (For this reason, only text controls can be made read-only: it wouldn't make sense for checkboxes or buttons, for instances.)
This question already has an answer here:
Javascript, Firefox: how to disable the browser specific cell controls?
(1 answer)
Closed 3 years ago.
Is there anyway to not display the row and column modification (the 2 arrows and cross) when making a table editable. I went through the W3C draft for contenteditable and it doesn't talk anything about the specific cases of different elements.
If I understand you correctly, the following will do it in Firefox (note: apparently the document must be loaded before this command can be executed. See comments below):
document.execCommand("enableInlineTableEditing", null, false);
See also this question: Javascript, Firefox: how to disable the browser specific cell controls?
This question already has answers here:
Default html form focus without JavaScript
(5 answers)
Closed 8 years ago.
Is there a way to set the focus in a specific HTML input (a textarea control, actually), without using Javascript?
EDIT: Is possible in HTML5 but the question is about HTML < 5
You can use autofocus in HTML5 documents, but it has little support at present (see chart).
Nope. Sadly JavaScript is required, because it's dynamically modifying the browser on the client-side (what JavaScript was made for).
I don't know of any, other than tabbing to the field or clicking within it.
It depends on how and when you want to set the focus on this textarea. "tabindex" might help you.