I'm trying to understand a problem that has been bugging me for a while, now.
I am wondering why checkboxes would be targeted by the pseudo element :read-only, even when not having the disabled attribute.
See the snippet below :
input:read-write + label {
background-color: green;
}
input:read-only + label {
background-color: red;
}
<!-- an active ( not disabled ) checkbox -->
<input type="checkbox" id="checkbox" />
<label for="checkbox">the checkbox</label>
<br />
<br />
<!-- a disabled text -->
<input type="text" disabled id="text"/>
<label for="text">the text</label>
<br />
<br />
<!-- an active ( not disabled ) text -->
<input type="text" id="text-active"/>
<label for="text-active">another text</label>
As you can see, both the checkbox and the first text input are targeted by the input:read-only, even though only the first text input has the disabled attribute.
I've done some research and came across this article on the subject which stated :
:read-only is a CSS pseudo-class selector that matches any element that does not match the :read-write selector.
Naturally I followed with a research on the :read-write pseudo selector and ended up on the mdn web docs page, which stated :
The :read-write CSS pseudo-class represents an element (such as input or textarea) that is editable by the user.
I feel like, since I can toggle the value of the checkbox, it should be considered "editable by the user" ?
I've made some test in some browser, Both Firefox ( 90.0 ) and Brave ( v. 1.27.109 Chromium: 92.0.4515.115 ) seams to have the problem.
I also tested in an old version of chrome ( Version 89.0.4389.90 ) and the behavior was not the same. Both element were unaffected by the :read-only pseudo-element, and the second text field was affected by the read-write pseudo element, even with the disabled attribute. Weird.
Maybe I'm missing something obvious ?
I've found why this behavior is occuring.
According to the HTML standard
The :read-only pseudo-class must match all other HTML elements.
Here, the all other HTML elements refer to the html elements on which the :read-write property does not apply.
On the same page, we can see what define an html element that is :read-write-able.
The :read-write pseudo-class must match any element falling into one of the following categories, which for the purposes of Selectors are thus considered user-alterable:
input elements to which the readonly attribute applies, and that are mutable (i.e. that do not have the readonly attribute specified and that are not disabled)
textarea elements that do not have a readonly attribute, and that are not disabled
elements that are editing hosts or editable and are neither input elements nor textarea elements
The relevent part, here, is input elements to which the readonly attribute applies. If we check the HTML standard page for checkboxes, we can see that the readonly attribute, indeed, does not apply.
The following content attributes must not be specified and do not apply to the element: accept, alt, autocomplete, dirname, formaction, formenctype, formmethod, formnovalidate, formtarget, height, list, max, maxlength, min, minlength, multiple, pattern, placeholder, readonly, size, src, step, and width.
Which makes the checkbox falls into the categories of html elements on which the :read-write property cannot be applied. Hense the behavior of the original question's snippet.
While this does not explain how to bypass the behavior ( see Aditya's answer ), It explains why it is occuring, which was the part I was originaly interessed in.
As an aditional note, I'm still not sure as why it the background-color was not working of the :read-only element in Chrome 89.
Try this out
input:read-write + label {
background-color: green;
}
input:disabled + label {
background-color: red;
}
<input type="checkbox" id="checkbox" />
<label for="checkbox">the checkbox</label>
<br />
<br />
<input type="text" disabled id="text"/>
<label for="text">the text</label>
<br />
<br />
<input type="text" id="text-active"/>
<label for="text-active">another text</label>
Instead of using read-only you can use disabled in your css
According to your question you need to change the style of a disabled input but as you're using :read-only this means the input which is set to readonly is changed!
input:read-only { background: #121212; color: #fff; }
input:disabled { background: #555; color: #00aeff; }
<input type="text" value="ReadOnly" readonly><br>
<input type="text" value="Disabled" disabled><br>
<input type="text" value="ReadOnly & Disabled" readonly disabled>
Check this WebPage Read more about Readonlys
Conclusion? Well there's a Difference between Read-Only and Disabled inputs.
Related
I'm having trouble with the CSS pseudo-class :read-only.
Working with Firefox the pseudo class is applied while the input is not in read-only state. I looked at the MDN doc :read-only and seems to compatible with Firefox.
Any idea what's going on with this?
input[type="radio"]:read-only {
-webkit-appearance: none;
-moz-appearance: none;
background-color: red;
width: 30px;
height: 30px;
border-radius: 50%;
}
<input type="radio" name="radio-1" value="false" />
Support
The CSS pseudo-class :read-only is well supported.
Only IE won't support it and as you know, Microsoft dropped IE support.
You can check the support for :read-only on MDN.
Two mistakes
List of HTML elements supporting the readonly attribute:
The readonly attribute is supported by text, search, url, tel, email,
password, date, month, week, time, datetime-local, and number
types and the form control elements. If present on any of
these input types and elements, the :read-only pseudo class will
match. If the attribute is not included, the :read-write pseudo class
will match.
Quote from the HTML attribute: readonly page on MDN
Therefore, it won't work on a <input type="radio">
HTML element would need the readonly attribute
For the CSS pseudo-class :read-only to work, you would need to add the readonly="readonly" attribute to your html element.
e.g.:
<div class="group">
<input type="textbox" value="Some value" readonly="readonly"/>
<label>Textbox</label>
</div>
Consider the following:
<label>Range from
<input name='min_value'/> to
<input name='max_value' />
</label>
Is this semantically correct since the W3C recommendations state that a label is associated with exactly one form control?
Clicking into the second input shifts focus immediately to the first input? Can this be prevented?
How would one markup a min/max input combination to show that two inputs belong together?
No, it's not correct (since, as you note, a label is associated with exactly one form input).
To label a group of inputs that belong together, use a <fieldset> and a <legend>:
<fieldset>
<legend>Range</legend>
<label for="min">Min</label>
<input id="min" name="min" />
<label for="max">Max</label>
<input id="max" name="max" />
</fieldset>
References:
<input />HTML 5 spec.
<fieldset>HTML 5 spec.
<label>HTML 5 spec.
<legend>HTML 5 spec.
As the accepted answer states, that's not correct, however I think there are better ways to do it.
Accessible alternatives:
Option 1 (using the aria-label attribute):
Range:
<input ... aria-label='Range start' />
<input ... aria-label='Range end' />
Option 2 (using hidden label tags):
<label for='start'>Range start</label>
<input type='text' id='start' />
<label for='end' class='hidden'>Range end</label>
<input type='text' id='end' />
Where the .hidden class is only readable by screen readers.
Option 3 (using aria-labelledby attributes):
<label id='lblRange'>Range</label>
<input type='text' id='start' aria-labelledby='lblRange' />
<input type='text' id='end' aria-labelledby='lblRange' />
Advantages of option #1: Each input has a good description that other suggestions (such adding a "to" label) do not. Options #2 and #3 might not be the best for this specific case, but worth mentioning for similar cases.
Source: http://webaim.org/techniques/forms/advanced
I see many answers saying it is wrong to put 2 inputs inside a label.
This is actually a wrong statement in html5. The standard explicitly allow it:
http://www.w3.org/TR/html5/forms.html#the-label-element
If the for attribute is not specified, but the label element has a labelable element descendant, then the first such descendant in tree order is the label element’s labeled control.
If a label element has interactive content other than its labeled control, the activation behavior of the label element for events targeted at those interactive content descendants and any descendants of those must be to do nothing.
However, Safari does not respect the html5 standard here (tested on iOS 11.3). So, someone that wants to be compatible with Safari must use workarounds here or wait until Apple fixes its browser.
According to this - label can contain only one input as it should be associated with only one control. Putting input inside the label means elimination of for attribute (automatic linking).
So you should either put single input into label or specify for attribute which points to input id and don't put input into label.
How about this:
<label> Range from <input name='min_value'> </label>
<label> to <input name='max_value'> </label>
1 LABEL = 1 INPUT !!!
If you put 2 INPUTS inside a LABEL, it will NOT work in Safari (and iPad and iPhone)... because when you click inside LABEL it automatically focuses the first INPUT... so the second input is impossible to type to.
I see many answers saying it is wrong to put 2 inputs inside a label. This is actually a wrong statement in html5. The standard explicitly allow it: http://www.w3.org/TR/html5/forms.html#the-label-element
<label id='dobRange'>DOB between</label>
<input type='text' id='start' aria-labelledby='dobRange' />
<input type='text' id='end' aria-labelledby='dobRange' />
in haml:
= f.label :dob_range
= f.search_field :dob_gteq, 'aria-label': 'dob_range'
= f.search_field :dob_lteq, 'aria-label': 'dob_range'
i don't think you should be putting the input field inside the label control.
<label for="myfield">test</label><input type="text" id="myfield" name="myfield />
the label is just that, a label for something.
I'm wondering if there is a CSS selector to select any label which refers to an input type checkbox.
<label for="checkbox_1">First checkbox</label>
<input type="checkbox" name="checkbox_1" value="1">
so what works easily:
label[for='checkbox_1'] { /* styles */ }
but then I have to repeat this for every label which refers to a checkbox.
I would like to do something like:
label[type='checkbox'] { /* styles */ }
Any thoughts?
You can use the selector that selects all LABELS with the type attribute starting with the word "checkbox":
label[type^='checkbox']
More information about attribute selectors here: http://www.w3.org/TR/css3-selectors/#attribute-substrings
This is currently not possible with pure CSS, as far as I know. You do have a couple of options for workarounds, though:
The [attribute^='value'] selector
This will work if your labels actually start with the same identifier/word when associated with checkboxes, similarly to the code example you provided.
Example:
HTML
<label for='chckbx'>Foobar</label>
<input type='checkbox' name='chckbx_1' value='1' />
CSS
label[for^='chckbx']{/* styles */}
Writing your HTML in a certain way
This will work if you already have your <label>s and their associated <input />s in their own container, or if you can modify your HTML to be that way. The trick is to select the checkbox element's container via CSS, and then style it's child <label>s.
Example:
HTML
<div class='checkboxContainer'>
<label for='foo'>Foobar</label>
<input type='checkbox' name='foo' value='1' />
</div>
CSS
.checkboxContainer > label{/* styles */}
Using JS
I can write a simple code example to do this with JavaScript(/jQuery), if you want me to.
Consider the following:
<label>Range from
<input name='min_value'/> to
<input name='max_value' />
</label>
Is this semantically correct since the W3C recommendations state that a label is associated with exactly one form control?
Clicking into the second input shifts focus immediately to the first input? Can this be prevented?
How would one markup a min/max input combination to show that two inputs belong together?
No, it's not correct (since, as you note, a label is associated with exactly one form input).
To label a group of inputs that belong together, use a <fieldset> and a <legend>:
<fieldset>
<legend>Range</legend>
<label for="min">Min</label>
<input id="min" name="min" />
<label for="max">Max</label>
<input id="max" name="max" />
</fieldset>
References:
<input />HTML 5 spec.
<fieldset>HTML 5 spec.
<label>HTML 5 spec.
<legend>HTML 5 spec.
As the accepted answer states, that's not correct, however I think there are better ways to do it.
Accessible alternatives:
Option 1 (using the aria-label attribute):
Range:
<input ... aria-label='Range start' />
<input ... aria-label='Range end' />
Option 2 (using hidden label tags):
<label for='start'>Range start</label>
<input type='text' id='start' />
<label for='end' class='hidden'>Range end</label>
<input type='text' id='end' />
Where the .hidden class is only readable by screen readers.
Option 3 (using aria-labelledby attributes):
<label id='lblRange'>Range</label>
<input type='text' id='start' aria-labelledby='lblRange' />
<input type='text' id='end' aria-labelledby='lblRange' />
Advantages of option #1: Each input has a good description that other suggestions (such adding a "to" label) do not. Options #2 and #3 might not be the best for this specific case, but worth mentioning for similar cases.
Source: http://webaim.org/techniques/forms/advanced
I see many answers saying it is wrong to put 2 inputs inside a label.
This is actually a wrong statement in html5. The standard explicitly allow it:
http://www.w3.org/TR/html5/forms.html#the-label-element
If the for attribute is not specified, but the label element has a labelable element descendant, then the first such descendant in tree order is the label element’s labeled control.
If a label element has interactive content other than its labeled control, the activation behavior of the label element for events targeted at those interactive content descendants and any descendants of those must be to do nothing.
However, Safari does not respect the html5 standard here (tested on iOS 11.3). So, someone that wants to be compatible with Safari must use workarounds here or wait until Apple fixes its browser.
According to this - label can contain only one input as it should be associated with only one control. Putting input inside the label means elimination of for attribute (automatic linking).
So you should either put single input into label or specify for attribute which points to input id and don't put input into label.
How about this:
<label> Range from <input name='min_value'> </label>
<label> to <input name='max_value'> </label>
1 LABEL = 1 INPUT !!!
If you put 2 INPUTS inside a LABEL, it will NOT work in Safari (and iPad and iPhone)... because when you click inside LABEL it automatically focuses the first INPUT... so the second input is impossible to type to.
I see many answers saying it is wrong to put 2 inputs inside a label. This is actually a wrong statement in html5. The standard explicitly allow it: http://www.w3.org/TR/html5/forms.html#the-label-element
<label id='dobRange'>DOB between</label>
<input type='text' id='start' aria-labelledby='dobRange' />
<input type='text' id='end' aria-labelledby='dobRange' />
in haml:
= f.label :dob_range
= f.search_field :dob_gteq, 'aria-label': 'dob_range'
= f.search_field :dob_lteq, 'aria-label': 'dob_range'
i don't think you should be putting the input field inside the label control.
<label for="myfield">test</label><input type="text" id="myfield" name="myfield />
the label is just that, a label for something.
Is there a best practice concerning the nesting of label and input HTML elements?
classic way:
<label for="myinput">My Text</label>
<input type="text" id="myinput" />
or
<label for="myinput">My Text
<input type="text" id="myinput" />
</label>
From the W3's HTML4 specification:
The label itself may be positioned before, after or around the
associated control.
<label for="lastname">Last Name</label>
<input type="text" id="lastname" />
or
<input type="text" id="lastname" />
<label for="lastname">Last Name</label>
or
<label>
<input type="text" name="lastname" />
Last Name
</label>
Note that the third technique cannot be used when a table is being used for layout, with the label in one cell and its associated form field in another cell.
Either one is valid. I like to use either the first or second example, as it gives you more style control.
I prefer
<label>
Firstname
<input name="firstname" />
</label>
<label>
Lastname
<input name="lastname" />
</label>
over
<label for="firstname">Firstname</label>
<input name="firstname" id="firstname" />
<label for="lastname">Lastname</label>
<input name="lastname" id="lastname" />
Mainly because it makes the HTML more readable. And I actually think my first example is easier to style with CSS, as CSS works very well with nested elements.
But it's a matter of taste I suppose.
If you need more styling options, add a span tag.
<label>
<span>Firstname</span>
<input name="firstname" />
</label>
<label>
<span>Lastname</span>
<input name="lastname" />
</label>
Code still looks better in my opinion.
Behavior difference: clicking in the space between label and input
If you click on the space between the label and the input it activates the input only if the label contains the input.
This makes sense since in this case the space is just another character of the label.
div {
border: 1px solid black;
}
label {
border: 1px solid black;
padding: 5px;
}
input {
margin-right: 30px;
}
<p>Inside:</p>
<label>
<input type="checkbox" />
Label. Click between me and the checkbox.
</label>
<p>Outside:</p>
<input type="checkbox" id="check" />
<label for="check">Label. Click between me and the checkbox.</label>
Being able to click between label and box means that it is:
easier to click
less clear where things start and end
Bootstrap checkbox v3.3 examples use the input inside: http://getbootstrap.com/css/#forms Might be wise to follow them. But they changed their minds in v4.0 https://getbootstrap.com/docs/4.0/components/forms/#checkboxes-and-radios so I don't know what is wise anymore:
Checkboxes and radios use are built to support HTML-based form validation and provide concise, accessible labels. As such, our <input>s and <label>s are sibling elements as opposed to an <input> within a <label>. This is slightly more verbose as you must specify id and for attributes to relate the <input> and <label>.
UX question that discusses this point in detail: https://ux.stackexchange.com/questions/23552/should-the-space-between-the-checkbox-and-label-be-clickable
If you include the input tag in the label tag, you don't need to use the 'for' attribute.
That said, I don't like to include the input tag in my labels because I think they're separate, not containing, entities.
Personally I like to keep the label outside, like in your second example. That's why the FOR attribute is there. The reason being I'll often apply styles to the label, like a width, to get the form to look nice (shorthand below):
<style>
label {
width: 120px;
margin-right: 10px;
}
</style>
<label for="myinput">My Text</label>
<input type="text" id="myinput" /><br />
<label for="myinput2">My Text2</label>
<input type="text" id="myinput2" />
Makes it so I can avoid tables and all that junk in my forms.
See http://www.w3.org/TR/html401/interact/forms.html#h-17.9 for the W3 recommendations.
They say it can be done either way. They describe the two methods as explicit (using "for" with the element's id) and implicit (embedding the element in the label):
Explicit:
The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element.
Implicit:
To associate a label with another control implicitly, the control element must be within the contents of the LABEL element. In this case, the LABEL may only contain one control element.
Both are correct, but putting the input inside the label makes it much less flexible when styling with CSS.
First, a <label> is restricted in which elements it can contain. For example, you can only put a <div> between the <input> and the label text, if the <input> is not inside the <label>.
Second, while there are workarounds to make styling easier like wrapping the inner label text with a span, some styles will be in inherited from parent elements, which can make styling more complicated.
3rd party edit
According to my understanding html 5.2 spec for label states that the labels Content model is Phrasing content. This means only tags whose content model is phrasing content <label> are allowed inside </label>.
Content model A normative description of what content must be included
as children and descendants of the element.
Most elements that are categorized as phrasing content can only
contain elements that are themselves categorized as phrasing content,
not any flow content.
A notable 'gotcha' dictates that you should never include more than one input element inside of a <label> element with an explicit "for" attribute, e.g:
<label for="child-input-1">
<input type="radio" id="child-input-1"/>
<span> Associate the following text with the selected radio button: </span>
<input type="text" id="child-input-2"/>
</label>
While this may be tempting for form features in which a custom text value is secondary to a radio button or checkbox, the click-focus functionality of the label element will immediately throw focus to the element whose id is explicitly defined in its 'for' attribute, making it nearly impossible for the user to click into the contained text field to enter a value.
Personally, I try to avoid label elements with input children. It seems semantically improper for a label element to encompass more than the label itself. If you're nesting inputs in labels in order to achieve a certain aesthetic, you should be using CSS instead.
As most people have said, both ways work indeed, but I think only the first one should. Being semantically strict, the label does not "contain" the input. In my opinion, containment (parent/child) relationship in the markup structure should reflect containment in the visual output. i.e., an element surrounding another one in the markup should be drawn around that one in the browser. According to this, the label should be the input's sibling, not it's parent. So option number two is arbitrary and confusing. Everyone that has read the Zen of Python will probably agree (Flat is better than nested, Sparse is better than dense, There should be one-- and preferably only one --obvious way to do it...).
Because of decisions like that from W3C and major browser vendors (allowing "whichever way you prefer to do it", instead of "do it the right way") is that the web is so messed up today and we developers have to deal with tangled and so diverse legacy code.
I usually go with the first two options. I've seen a scenario when the third option was used, when radio choices where embedded in labels and the css contained something like
label input {
vertical-align: bottom;
}
in order to ensure proper vertical alignment for the radios.
I greatly prefer to wrap elements inside my <label> because I don't have to generate the ids.
I am a Javascript developer, and React or Angular are used to generate components that can be reused by me or others. It would be then easy to duplicate an id in the page, leading there to strange behaviours.
Referring to the WHATWG (Writing a form's user interface) it is not wrong to put the input field inside the label. This saves you code because the for attribute from the label is no longer needed.
One thing you need to consider is the interaction of checkbox and radio inputs with javascript.
Using below structure:
<label>
<input onclick="controlCheckbox()" type="checkbox" checked="checkboxState" />
<span>Label text</span>
</label>
When user clicks on "Label text" controlCheckbox() function will be fired once.
But when input tag is clicked the controlCheckbox() function may be fired twice in some older browsers. That's because both input and label tags trigger onclick event attached to checkbox.
Then you may have some bugs in your checkboxState.
I've run into this issue lately on IE11. I'm not sure if modern browsers have troubles with this structure.
There are several advantages of nesting the inputs into a label, especially with radio/checkbox fields,
.unchecked, .checked{display:none;}
label input:not(:checked) ~ .unchecked{display:inline;}
label input:checked ~ .checked{display:inline;}
<label>
<input type="checkbox" value="something" name="my_checkbox"/>
<span class="unchecked">Not Checked</span>
<span class="checked">Is Checked</span>
</label>
As you can see from the demo, nesting the input field first followed by other elements allows,
The text to be clicked to activate the field
The elements following the input field to be dynamically styled according to the status of the field.
In addition, HTML std allows multiple labels to be associated with an input field, however this will confuse screen readers and one way to get round this is to nest the input field and other elements within a single label element.