This is silly, but I'm about to explode - inputs, selects, textareas, checkboxes, radio buttons... what is the general name of this type of elements?
I'm creating an AngularJS set of form/input directives that wrap single form field in an object called "input", which consists of "element"-DOM, "scope"-Scope and I want to be able to extract its form element like input, select, etc., but I can't find a proper name for it...
They are called “controls” in HTML 4.01. HTML5 uses the same word, as well as the longer “form control”, but it has some more fine-grained terminology for “form-associated elements”. In practice, controls are often called “form fields”.
The use of “form” in the names is partly misleading, since controls are syntactically permitted outside any forms, too, and such controls can be successfully used when handled with client-side JavaScript.
They are called form controls or form elements or html inputs tags
Related
I have been busy making an interactive tab layout using only CSS and I've had someone tell me that this is not the intended semantic meaning of <input> tags. Now, I know that HTML5 focuses a lot more on semantics than previous versions of HTML did, so I was wondering, is something that does something like the following against the input semantics:
<label for="toggleTab" class="togglelabel">Toggle tab</label>
<input type="checkbox" id="toggleTab" class="toggleinput">
<div class="toggletab">Look at this thing hide and show</div>
CSS:
.toggletab, .togglelabel {border:1px solid #AAA;display:block;}
.toggleinput, .toggletab {display:none;}
.toggleinput:checked + .toggletab {display:block;}
(demo)
The standards[1][2] both say the same thing:
The input element represents a typed data field, usually with a form control to allow the user to edit the data.
So to me this seems like this is indeed against what the input tag should be used for (since this has nothing to do with data, but just with displaying certain things to the user or not).
And then of course my followup question would be, if this is indeed not what input tags should be used for according to the standard, is it bad to go against the semantics standards?
Well structurally this will be quite difficult. Inputs need go inside form elements, and if you are going to be using these all over the page, most of your page will be wrapped as one giant form, potentially will nested forms, for search bars, user input and the like.
As your quote says:
The input element represents a typed data field, usually with a form control to allow the user to edit the data.
The control you are suggesting isn't for editing data its for adding graphical user functionality. If you were to bing the input to a form, either by placing the input inline into a form, or using the #form attribute as your comment suggests, what exactly is the semantic of that form? If would have no action, it would have no site to post to, and if an accessibile browser were to try and render the elements of that form in a different way it would have no semantic content.
For the kind of hide/show toggle functionality, I'd recommend instead using an a link and hanging some javascript off that. As stated:
If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor) labeled by its contents.
In this context Hyperlink does not preclude the use of javascript as the acting force on the page, if it did most pages would be non-compliant to the spec. This is backed up by the first type of link suggested in the definition of hyperlink suggests that the link can be "used to augment the current document".
As a side note, in accessible browsers, inputs like these maye be rendered or presented in ways different to what you expect. Each form might be pulled out into a list of possible data editing options, and this would not fit the semantics of what a user might expect.
Semantics & custom behaviour
If the question is about which element has the least implied semantics, I reckon your best bet is the <button type="button"> element: the HTML5 spec describes it as « a button with no additional semantics» which, without scripting, « does nothing » — unlike the <a> element, which has implicit behaviour as a hypertext link and anchor.
The HTML4 forms spec refers to these as 'push buttons', which « …have no default behavior. Each push button may have client-side scripts associated with the element's event attributes ».
Furthermore, the HTML4 spec cites buttons repeatedly in its description of scripts: they are the only element referenced specifically in the introduction to scripts, although inputs also feature in the examples of DOM-event triggered scripts — however, as buttons are non-self-closing, they can contain other DOM nodes, which may make them more flexible depending on your needs.
Non-<input> solution
Using the push button, custom behaviour can be inferred by using data-* attributes for CSS selectors:
.toggleinput[ data-checked ] + .toggletab {
display:block;
}
…and scripted as follows:
// Use Array's forEach to loop through selection
Array.prototype.forEach.call(
// …of all `.toggleinput` elements
document.querySelectorAll( '.toggleinput' ),
function bind( input ){
input.addEventListener( 'click', function toggleCheckedState(){
// `dataset` is an object representation of data-* attributes
if( this.dataset.checked ){
// Remove the attribute if it exists
delete this.dataset.checked;
}
else {
// Declare it if it doesn't
this.dataset.checked = true;
}
}, false );
}
);
Forked code demo
Newbie to ASP.net MVC 4 and trying to make sense of Razor. If I wanted to just display some text in my .cshtml page, can I use
<label class="LabelCSSTop">Introduction</label>
or should I use:
#Html.Label("STW", htmlAttributes: new { #class = "LabelCSSTop" })
Not sure if one is preferred over the other or if either is okay. If the latter emits the label tag anyway, should I just stick to the former?
Again, if I just wanted to display a text box, can I just do this:
<input id="txtName" type="text" />
or should I do this:
#Html.TextBox("txtName", "")
Is there a situation when I should use the #Html over the regular html tag?
Thanks in advance!!
In the case of your label snippet, it doesn't really matter. I would go for the simpler syntax (plain HTML).
Most helper methods also don't allow you to surround another element. This can be a consideration when choosing to use/not use one.
Strongly-Typed Equivalents
However, it's worth noting that what you use the #Html.[Element]For<T>() methods that you gain important features. Note the "For" at the end of the method name.
Example:
#Html.TextBoxFor( o => o.FirstName )
This will handle ID/Name creation based on object hierarchy (which is critical for model binding). It will also add unobtrusive validation attributes. These methods take an Expression as an argument which refers to a property within the model. The metadata of this property is obtained by the MVC framework, and as such it "knows" more about the property than its string-argument counterpart.
It also allows you to deal with UI code in a strongly-typed fashion. Visual Studio will highlight syntax errors, whereas it cannot do so with a string. Views can also be optionally compiled along with the solution, allowing for additional compile-time checks.
Other Considerations
Occasionally a HTML helper method will also perform additional tasks which are useful, such as Html.Checkbox and Html.CheckboxFor which also create a hidden field to go along with the checkbox. Another example are the URL-related methods (such as for a hyperlink) which are route-aware.
<!-- bad -->
my link
<!-- good -->
#Html.ActionLink( "my link", "foo", "bar", new{ id=123 } )
<!-- also fine (perhaps you want to wrap something with the anchor) -->
<span>my link</span>
There is a slight performance benefit to using plain HTML versus code which must be executed whenever the view is rendered, although this should not be the deciding factor.
Depends on what your are doing.
If you have SPA (Single-Page Application) the you can use:
<input id="txtName" type="text" />
Otherwise using Html helpers is recommended, to get your controls bound with your model.
If you want to just display some text in your .cshtml page, I do not recommend #Html.Label and also not to use the html label as well. The element represents a caption in a user interface. and you'll see that in the case of #Html.Label, a for attribute is added, referring to the id of a, possibly non-existent, element. The value of this attribute is the value of the model field, in which non-alphanumerics are replaced by underscores.
You should use #Html.Display or #Html.DisplayFor, possibly wrapped in some plain html elements line span or p.
The helpers are there mainly to help you display labels, form inputs, etc for the strongly typed properties of your model. By using the helpers and Visual Studio Intellisense, you can greatly reduce the number of typos that you could make when generating a web page.
With that said, you can continue to create your elements manually for both properties of your view model or items that you want to display that are not part of your view model.
When it comes to labels, I would say it's up to you what you prefer. Some examples when it can be useful with HTML helper tags are, for instance
When dealing with hyperlinks, since the HTML helper simplifies routing
When you bind to your model, using #Html.LabelFor, #Html.TextBoxFor, etc
When you use the #Html.EditorFor, as you can assign specific behavior och looks in a editor view
#html.label and #html.textbox are use when you want bind it to your model in a easy way...which cannot be achieve by input etc. in one line
Why do we use the the name, id and value attributes with html elements? What are they important and how are they interpreted? What are the differences between them? I have looked at w3schools and every tutorial but I would like a simple explanation from a person.
What is the difference between just doing:
<form>
<input type="text" />
</form>
and
<form>
<input type="text" name="name" />
</form>
what are the benefits of using these attributes?
name - passed to the server in forms
id - a unique identifier to the HTML element
value - the value of an input or textarea element
The presence of a name attribute in an input element causes a name=value pair to be included in the form data, if the value is not empty. In the absence of such an attribute, the form field does not make any contribution to the form data.
The id attribute can be used to give an element a unique identifier that can be used in client-side scripting and styling. It has nothing to do with the functionality of the name attribute.
The value attribute in a text input box specifies the initial (default) content of the input field.
Each form element in your application must save some information for you. Those are value.
When you want process your forms using a server-side programming language, you must point to your wanted element. Here, you need name to fetch your form elements values.
Also, sometimes you might need to process your form client-side or do something else on elements in your HTML document, now one way to point to them can be an id.
id is usually referred to by, or used in relation to, CSS styling. name is usually referred to by data-related php or or other server-side scripting , and value is the "content" ascribed to that element, so if input value = "hello", then that is what will appear in the text input field.
One point that the other answers don't make clear, is that the purpose of an attribute can differ depending on which element it belongs to.
So while an id attribute identifies an element no matter where it is, the name attribute serves a different purpose on the iframe and object than it does on the meta element, which is again different from its purpose on the submittable elements button, input, keygen, object, select and textarea. The param element and the map element both have name attributes, each for a different purpose, while the form element, fieldset element and output element use their name attributes for a more or less common purpose, but different from the other elements.
Similarly, the value attribute on the input, button and option elements serve similar but slightly different purposes, and the progress and meter elements share a similarly purposed value attribute, but each of the param, li, and data (WHATWG HTML living standard only) elements has a value attribute with a purpose dedicated to that particular element.
To understand all the purposes properly, I recommend that you at least read the spec.
I have a form within another form:
<form id="a">
<form id="b">
<input type="submit">
When the submit button is clicked, it seems that the outer form is submitted.
Is there a way to target which form is submitted?
No, nested forms aren't supported:
There can be several forms in a single document, but the FORM element can't be nested.
-- http://www.w3.org/MarkUp/html3/forms.html
The HTML DTD specifically forbids a form element from containing another form element:
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form -->
http://www.w3.org/TR/html401/interact/forms.html#edef-FORM
Like others have said...nested forms aren't allowed.
However, that doesn't mean some browsers won't do something with such. In the example that you have presented, the browser appears to be ignoring the second <form> tag in a similar fashion to how an unknown tag (i.e. <notAValidTag>) is also ignored. Since JavaScript also doesn't allow for embedded form collections, the best way to ensure that FormB's information is submitted is to make it no longer a nested form. This will break up your markup and UI into more distinct sections which may be beneficial from a UX perspective as well.
i think this is not allowed by the html standard.
In HTML 5, yes. Each input element can have a "form" attribute signalling which form it belongs to. However, it is still invalid to nest forms in HTML and HTML parsers won't allow this to happen.
However, it is possible to construct nested forms via JavaScript. In the absence of the form attribute, the rules for determining which form an input belongs to are quite complex, but they are described in full with an example at http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#association-of-controls-and-forms
Specifically, step 5 of Reset the Form Owner says:
Otherwise, if element has an ancestor form element, then associate element with the nearest such ancestor form element.
Clearly, "nearest" would not need to be said if form nesting was impossible.
Then step 4 explains how the required form can be targeted, by associating the submit button to the required form though the "form" attribute on the button.
If element is listed, has a form content attribute, and is connected, then:
If the first element in element's tree, in tree order, to have an ID that is identical to element's form content attribute's value, is a form element, then associate the element with that form element.
I was recently corrected, and according to the HTML4 DTD, it is legitimate to use a fieldset outside of a form:
http://www.w3.org/TR/html401/sgml/dtd.html#block
Previously I had not known this, and wonder if anyone can think of a legitimate use case for doing so. I feel like using one to decorate would be frowned upon by most designers. So is there a legitimate use case, or can you link to a site where this has been found appropriate and used as such?
I used a field set to decorate sections when printing documents. For example an invoice might have a Bill To and a Ship To, and drawing the frame around them with the legend text embeded in the frame can look really slick.
I think its more than legit to use it for decoration. Its simple and elegant and with the use of tag its pretty nice.
Check w3schools example out
I don't think there is a legitimate case to semantically have a fieldset outside a form element, since a fieldset is a set of (input) fields - the clue's in the name! If you have input fields, you will likely always have a form, even if you're not posting back to the server.
I have occasionally used from a presentational aspect, because the fieldset+legend combo is impossible to replicate exactly in CSS, specifically, the broken line behind the legend.
It is acceptable to use all form field control outside of a form element, including fieldset.
This is appropriate wherever you have fields that only talk to JavaScript, instead of ever being submitted back as to the server side.
(This didn't originally used to work in Netscape 4, but that's hardly a concern this century...)
Well, using it to decorate can be frowned upon by designers AND be legitimate, so there is a legitimate use case.
A form is simply a container for the fields you wish to submit via post back. Most regular site pages may not even have one. That said, using a fieldset as a styling tag is legitimate and has nothing at all to do with whether a form tag exists or not.
You can use a fieldset to wrap multiple form controls that you need to disable together:
<fieldset disabled>
<input type="text" placeholder="disableable input" />
<button type="button">Some action that needs to be disabled</button>
<button type="button">Some other action</button>
</fieldset>