I just read this post about the term "control" when dealing with forms.
However, the OP asked it in relation to Bootstrap, and I'd like know if this term has a general definition, and more importantly: Does its usage relates only to web forms, or does it have more usages in web development?
Typically, a "control" is a UI element which causes some action to occur. For example, both text inputs and submit buttons are examples of "control" UI elements.
There are special control elements implemented by specific frameworks or platform ecosystems. For example, there are many variations on calendar UI element controls.
Form controls are those elements (which you use in conjunction with a form) that the user interacts with directly. Examples include text boxes, drop down menus and buttons.
From the specification:
A form is a component of a Web page that has form controls, such as text fields, buttons, checkboxes, range controls, or color pickers.
and
Most controls are represented by the input element, which by default provides a one-line text field.
Related
I have a question about correct nesting and syntax with using form element in HTML. I understand basics but is it okay to put there divs, paragraphs, spans, etc.? Because using nice CSS need sometimes more elements and because I am front-end learner I am not sure if these elements inside form influence some data and inputs. If you have some examples of using very advanced HTML in forms I would really appreciated some already used HTML real examples. Also if you can explain how it works with data collecting from forms, it could also help me understand this nesting.
Btw: is it important to have button inside the form or it can be outside this element?
Thans for any answer.
First place to go when you want to know anything about HTML/CSS and JavaScript in the browser is MDN. In your case: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Form
As you can see there, forms can indeed include any types of elements (a <form> behaves like a <div> for all visual design purposes), except for nested <form> elements
Data collection for a form is typically (as in plain HTML/HTTP) made by sending a request to the URL given in its action property. How this request is exactly formed can be controlled through the use of attributes method and enctype.
Basically, the request body (for POST) or query string (for GET), will contain all data inside the form as key/value pairs, where the keys are the name attribute of the input fields, while the value is their value attribute.
This can vary a little depending on field type. For instance a <textarea> will send its text contents as a value instead.
The sending of this request (and browser navigation) is triggered when the user clicks a submit button on the form (either <input type="submit"> or <button>). This is called submitting the form.
is it okay to put there divs, paragraphs spans etc.
Yes, that's perfectly fine.
is it important to have button inside the form or it can be outside this element?
You can have a button outside of a form - depends on what functionality you are trying to achieve.
If you have some expamle of using very advanced html in forms
Your question is quite basic so I don't know how much of an advanced example you are looking for, but you can find examples of css classes being used with forms on this Bootstrap 5 tutorial (Bootstrap is a CSS library/framework): https://getbootstrap.com/docs/5.0/forms/layout/
In native WinForms programming there was the concept of "AutoComplete" with a mode "Append" where, as you type, the rest of the textbox would fill in with a suggestion which would be highlighted. If the user continued typing, that suggestion would naturally be replaced with the text entered, and the auto-complete suggestion would append again if available.
In web contexts, I have only seen auto-complete implemented as a selection dropdown below the input textbox (e.g. jquery autocomplete). There's also the input tag autocomplete attribute, but the options can't be controlled by javascript. Searching for "autocomplete" and "autofill" dead-end with issues relating to the autocomplete attribute.
If "AutoComplete Append" is used in a web context, does it go by a different name?
Is there a reason that this paradigm is avoided (or, doesn't even exist) in web development? (it seems particularly useful in mobile websites where screen real-estate is at a premium)
Can I use the same role attribute in different elements that share the same functionality?
For example, the same logo in different parts of a website, or multiple svg icons which are all role: button.
I read somewhere this is malpractise but I don't really know how to get around this without losing the accessibility of my website. Should I just change the roles to non-WAI ones like "button1", "button2"...?
There may be some confusion here between the id attribute, which is expected to have a value that is unique inside the HTML page, and the role attribute, which identifies the type of UI components.
If you have SVG icons that function as buttons, then role="button" is correct, regardless how many such buttons you have in a page. There is no rule that says you can only have one button in a web page. On the contrary; if you want to make accessible each SVG icon that functions as a button, then you should assign them role="button" and make them keyboard accessible.
While the list of ARIA role values is strictly speaking non-normative from the point of view of the HTML5 specification, making up your own role values does not make much sense. WAI-ARIA developed the "role taxonomy" based on what types of UI components are/were supported in existing accessibility APIs. This is the background behind the mapping between WAI-ARIA and accessibility APIs in the WAI-ARIA 1.0 User Agent Implementation Guide. "button" is a type of UI component that accessibility APIs commonly support. "button1", "button2" are not UI components that accessibility APIs support.
In short, giving your SVG icons attributes such as role="button1", role="button2" is a bad idea; use role="button" for each such icon that functions as a button.
I was recently working on styling forms. It is much harder to style the elements of the forms like for example: input, select, checkbox or radio button as it seems they are controlled by operating system (right?) And don't respond very well to CSS3.
So I went to youtube and took a look how they deal with checkboxes (for example when you add a song to one of your playlists) and... boom! they don't use checkboxes at all, instead they build everything with div elements.
So my question is: is to a common practices? It seems that it gives a lot of more freedom of how one could style the checkboxes. How about other form elements? It's really annoying that default form elements are not editable well with CSS.
My question stems from the context of a web application, rather than a web page. In that context it often does not make any sense to submitt data. You want to modify state in your application using controls.
To me, it then does not make any sense to use a form. However I still need controls/widgets to modify. Meaning I need tags such as input, which I understand is a "form control", indicating that they should always be contained inside a form. Furthermore I want to organize my controls in fieldset tags.
So I was left wondering if I now have to wrap all of my controls in form-tags, even though this to me seems symantically incorrect (since I'm not going to submit).
After a few quick searches I found the two following two breif forum discussions on topic:
http://www.webmasterworld.com/forum21/8837.htm
http://doctype.com/can-fieldset-outside-form
To sum them up, using form controls outside of a form will validate on w3c. However rendering might not work in really old browsers (like Netscape 4, which I really don't care about.)
In the first link there seems to be support for using form controls outside of forms as the symantically correct thing to do in my sort of scenario. However in the other it seems that using fieldsets should strictly be done within a form when caring about being symantically correct.
Does this mean I should feel free to use controls outside of forms, but I must wrap them in divs rather than fieldsets, or should I read this some other way?
The w3c states:
17.2.1 Control types
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.
17.10 Adding structure to forms: the FIELDSET and LEGEND elements
The FIELDSET element allows authors to group thematically related controls and labels.
17.10 doesn't make any mention of the form element, to me this means that there is no limitation on where it can be used except that it should surround controls and labels. 17.10.2 Seems to allow me to use those outside of a form. Hence I can also use the fieldset outside of a form, as long as it wraps controls and labels.
I have come across use cases where I have required to have form controls without the need for actually submitting the form.
Sometimes, enclosing within the tag only makes the things worse, because I might be interested in calling a JS function whereas the form simply submits and reloads the page. I have encountered this using PhoneGap application on a WindowsPhone.
As for me, I wouldn't be too bothered about W3C validation, given it makes life much more simpler.