The primary purpose for including things inside the label tag would be so that when you click them, it takes you to the relevant input as though you’d clicked it. If the input’s inside it… shrug.
Unless you did something strange involving click events and preventing defaults, there shouldnt be any particular difference.
I find the example interesting in that they chose to absolutely define the position of the label relative to an outer div (IE: The one containing the header) rather than defining a container div for the input box. Not sure i would have done that personally.
Sir, a couple of days a discussion was done where you also created many code pens, it was around those switches of on/off. You also said the same thing there. Sir, I am unable to grasp this concept. Would it be possible for you to explain it further based on some of your other pens? I could not understand sir when you say “you do not have fine control over the text unless you also wrap it in a span.”
There was a discussion done many years back I have attached the links. My question is in the above example when there is nested input under the label in that case the for property is useless because in an explicit label with input nested both label and input are bonded and for an ID property needs are not explicitly needed.
It’s redundant in that case as the label is naturally associated to the label.
However, I previously mentioned a bug with screen readers which I remembered from about 15 years ago and apparently the Dragon Speaking screen reader has no support for nested inputs and requires the for attribute to identify the input.
The example that I have shared in that case for/id, if instead of nested one I go with for/id combination, will become complicated when such things are handled by user inputs as in wp PLUGINS Where there is no limit to how many radio button options can be created. also in that case for/id combination has to be generated programmatically.
Also I do not go for nested CSS/HTML then, in this case, there are two inputs(Radio + Text) associated with the same label how can the two inputs be tied to one ID?
That’s not acceptable as a label element can only refer to one input. You cannot have two inputs inside a label.
Error : The label element may contain at most one button, input, meter, output, progress, select, or textarea descendant.
You can have two different (separate) labels pointing to the same input but you can’t have one label pointing or containing two inputs.
That structure will be very buggy as clicking on the label should activate the input but you have two inputs in there so what does the browsers do when you click the second input. Theoretically as its inside a label it should activate the first input and I believe you may find that some browsers won’t let you activate the second input at all.
I wouldn’t touch that structure with a barge pole You probably need fieldsets if you want to group things together.
Also your fiddle is already buggy anyway because if I change a value and then click on any other values only the changed value shows at the bottom. You may need to revisit your logic for that component.
Sir, My original question was not for using a nested structure under the label, but for utilizing your suggested one where the label and input as siblings. so my question was when one label and two inputs are sibling does this structure exists and will work? But as you have said that this doesn’t. I am confused about how should I proceed.
If you are using it to determine which input is selected then it seems the input is the key element. However you then allow its value to be changed!
I think you need to define the requirements for me. :).
From my point of view it looks like you are offering a predefined set of choices or a custom value. If that’s the case then I would suggest simple checkboxes with defined values and then a simple input box if a custom value is required.
That would then work without js if submitted as back end logic could determine the value.
You could then of course manipulate the front end with js as required.
On a website, there are multiple causes, each with its own dedicated page. However, all these causes are then consolidated onto a single page. Visitors can select a cause using radio buttons to indicate where they want to donate. Each cause has a predetermined fixed value for donation, but there is also an option for users to enter a custom amount if they wish to increase or decrease their donation for a specific cause.
A situation like this:
By clicking the radio button the animated bar above just shows how much target is achieved and may not have any affiliation to the markup of the radio button and custom input for each associated radio button chosen.