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.
Related
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 2 years ago.
Improve this question
It is my understanding that anything that is clickable on a web page must be a link or a button. If on click, you want to take the user to a different page or a new context, you should use a link, If you are triggering an action while staying on the same page, you should use a button.
Does this understanding exclude any use cases?
I am trying to understand when is it all right to use div or span with click handlers? why wouldn't you rather use a button (and style it properly).
Why does the role="button" exist (apart from the toggle button use case, may be), if we may never need to use it on div or span or other elements, because we could instead use a button and style it properly? What exactly are the use cases where this is not possible?
EDIT: keeping the question closed as is, but adding some more findings here
role="button" is anyway useful outside of HTML, as an aria role
div without the button semantics can be used to enhance some functionality only for mouse users, if the functionality has already been exposed in some other way for the keyboard and screenreader users. This usage, in turn, also validates that not every thing that is interactive needs to be a button or a link
Natively, div and span elements aren't keyboard focusable and weren't meant to respond to mouse clicks or keyboard input. However, when people started creating rich Internet applications (RIAs) or rich web applications, they needed user interface components that HTML did not provide natively. Examples include(d) sliders, rich text editors, spreadsheets (see Google Sheets) and drag-and-drop functionality. These allowed user interfaces and interaction types that people were familiar with on the desktop but that were not provided natively by existing HTML elements.
Developers started building such user interface components using the available HTML elements (div and span were used a lot because they don't have any specific native "semantics"), JavaScript and CSS. These UI components responded to mouse input in the way that sighted users expected, but were meaningless to blind users, who cannot use a mouse and need to rely on the UI semantics conveyed by a screen reader.
This lack of semantics for those new components required a type of markup that would convey a component's role (e.g. gridcell, slider, tabpanel or menubar), state (e.g. aria-checked or aria-disabled for certain controls) and properties (e.g. min and max values for a slider).
Button and link elements don't fit all of the above use cases, which is why div and span elements were often used to create UI components.
use case for a clickable div
One use case is to make a div container clickable while there is already an interactive element inside like a button or a link.
This will improve mouse navigation to make a whole area clickable while only the link text would be focusable with the keyboard.
But this div must have no role as you can not have an interactive element inside another interactive element.
use case for button role
the only valid use case would be an already activable element where we would want to override the default native role.
This definition seems to match the <input type="checkbox" /> element used with the aria-pressed attribute
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 6 years ago.
Improve this question
I'm currently placing some ID's on elements for UI Test automation. These ID's are only being used for testing. Should I be adding data-attributes instead possibly making it more readable to future developers(data-testHandle="mybutton") or should I stick with ID's.
w3.org says:
Custom data attributes are intended to store custom data private to
the page or application, for which there are no more appropriate
attributes or elements.
I'm leaning towards keeping ids but some part of me thinks that future developers would think the ID's aren't used and remove them.
Any best practices here. Thanks.
This is close to being opinion-based, by here is the summary that should help to make a choice.
Why would you use an ID attribute:
this is a common and familiar to everybody doing test automation way to locate elements
this is generally the fastest way to locate elements on a page because selenium gets it down to executing document.getElementById() which is optimized by the modern browsers (though, usually performance of the end-to-end UI tests is not critical)
it is a built-in locator in every selenium language binding
if you would use Firebug or Chrome Developer Tools - the CSS selector and XPath generation tools would generally provide more robust locators using the ids of the element whenever possible
you would build shorter CSS selectors and XPath expressions. E.g. #myid .someclass as opposed to [automation-id=myid] .someclass.
Why would you use a custom attribute:
if you would add, say, automation-id attributes to all the desired elements, you would somewhat namespace/scope it to the test automation - everybody would know what is this for just from the attribute name. Meaning, you would dramatically decrease chances of a developer changing the attribute intentionally as opposed to an id attribute, which can and is usually used for application client-side logic as well (reference to this and this answer)
Also, here are some relevant threads:
Is adding IDs to everything standard practice when using Selenium?
Which is the best and fastest way to find the element using webdriver? By.XPath or By.ID or anything else? And why?
Something Better than IDs for Identifying Elements in Selenium Tests
I would go with the data attribute instead, as you (or someone else) might need to use an ID for targeting the element for JS later. No one is ever going to need to target your custom data attribute for anything other than testing.
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:
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.
This question already has answers here:
Is it OK to have an empty anchor tag?
(5 answers)
Closed 8 years ago.
Is this valid HTML?
Home
I'm using the ID to call a jQuery function with an id of "whatever." I can't find anything that says whether this is valid. I'm having a debate as to whether it is.
Also, is it valid HTML to have a radio button group without one selected?
It's valid, and necessary to have something in the href attribute in most browsers to activate the link behaviour of the <a> element. (although href="" would cause the browser to open the index page of the current 'folder'.)
IF the link represents some change of state, then it's better to put more (e.g. '#home') so if the user presses back/forward/refresh, you can restore the state on page load - this is a boon during development too if you tend to refresh the pages a lot whilst developing them.
--
Unselected radio groups are trickier, HTML 4 validators will let it pass, but the HTML 4 specification says one must always be checked (Since user agent behavior differs, authors should ensure that in each set of radio buttons that one is initially "on".). HTML 5 has relaxed this as far as I know since I cannot find any equivalent wording in the HTML 5 specification.
However, such a group of radio buttons is in an invalid state, so it should not be used for capturing optional input (if the user checks one, they cannot uncheck it).
It's better for the user if a default value was selected (usually the most frequent choice), or if it is optional, to have an explicit option for null (e.g. 'None of the above')
Your HTML is completely valid.
Just as a suggestion, your jQuery function should prevent the default behavior of your anchor tag:
jQuery("#whatever").click(function(evt) {
evt.preventDefault(); // Prevent the default anchor tag behavior
// Do what you need here
});
This way you will prevent the common "scroll-to-top" behavior when using href="#".
The HTML markup is valid and conforms to HTML specifications, which cite URI specifications regarding the values of the href attribute. The current authoritative specification is RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, also known as Internet-standard STD 66. According to it, as well as older URI specifications, # is a same-document reference. The relevant clauses in the spec are 3.5 and 4.4.
Following a link with href="#" thus means staying in the current document, with no reload, but positioning the document at its start (“jump to the start”). Thus, it is not a no-op as such, even though href="#" has been used to make the element a fake link, more or less.
On the other hand, an a element without any href attribute is valid, too. It will then not be regarded as a link in visual renderings, scripting, link analysis, etc. If it’s not meant to be a link, don’t make it a link.