What problem are you trying to solve?
Fieldset supports the disabled attribute.
Setting the disabled attribute disables automatically all it's children.
<fieldset disabled>
<legend>Choose your favorite monster</legend>
<input type="radio" id="kraken" name="monster" value="K" />
<label for="kraken">Kraken</label><br />
</fieldset>
Demo
this is a useful Feature when creating a form manager together with form association.
The form controls support the readonly attribute too, it would make sense to propagate the readonly attribute from the fieldset controls as it's done with the disabled attribute.
Use Case: In a form disable a whole part of a form or make it readonly
<fieldset readonly>
<legend>Choose your favorite monster</legend>
<input type="text" id="kraken" name="monster" value="Readonly value" />
<label for="kraken">Kraken</label><br />
</fieldset>
Expected behavior: All descendant controls that support readonly become read-only.
What solutions exist today?
Setting disabled on a fieldset automatically disables all controls that support it. A very similar attribute readonly needs to be set manually on all controls.
How would you solve it?
Add support for the readonly attribute on fieldset that would work in a similar way as disabled - propagate readonly to all its children
Anything else?
Only concern is not all controls support readonly, but neither do all html elements disabled.
This would make sense to use for web components that have form association implemented to be handled through a form manager - for example dynamic forms / form builder.
Adding readonly propagation to <fieldset> would:
- Reduce boilerplate
- Improve consistency
- Simplify integration with
form-associated custom elements
- Align
readonly behavior with disabled
Prior Art / Precedent:
fieldset disabled already propagates to descendant controls (except <legend>).
- Similar ideas have been implemented in component libraries (e.g., FieldGroup wrappers), but lack standard support.
Considerations:
- Only form controls that support readonly (like
<input type="text"> and <textarea>) would be affected.
- readonly would not apply to
<select>, <button>, <input type="checkbox">, etc.
- Propagation semantics would need to exclude (as with disabled) and avoid shadow DOM leakage.
- Developers expect symmetry with
disabled behavior.
Next Steps:
-
If this feature aligns with the HTML standard's goals, I’d be happy to prepare a formal PR.
-
Alternatively, I can incubate the feature via WICG if that is preferred.
What problem are you trying to solve?
Fieldset supports the disabled attribute.
Setting the disabled attribute disables automatically all it's children.
Demo
this is a useful Feature when creating a form manager together with form association.
The form controls support the readonly attribute too, it would make sense to propagate the readonly attribute from the fieldset controls as it's done with the disabled attribute.
Use Case: In a form disable a whole part of a form or make it readonly
Expected behavior: All descendant controls that support readonly become read-only.
What solutions exist today?
Setting disabled on a fieldset automatically disables all controls that support it. A very similar attribute readonly needs to be set manually on all controls.
How would you solve it?
Add support for the readonly attribute on
fieldsetthat would work in a similar way as disabled - propagatereadonlyto all its childrenAnything else?
Only concern is not all controls support readonly, but neither do all html elements disabled.
This would make sense to use for web components that have form association implemented to be handled through a form manager - for example dynamic forms / form builder.
Adding readonly propagation to
<fieldset>would:form-associatedcustom elementsreadonlybehavior withdisabledPrior Art / Precedent:
fieldset disabledalready propagates to descendant controls (except<legend>).Considerations:
<input type="text">and<textarea>) would be affected.<select>,<button>,<input type="checkbox">, etc.disabledbehavior.Next Steps:
If this feature aligns with the HTML standard's goals, I’d be happy to prepare a formal PR.
Alternatively, I can incubate the feature via WICG if that is preferred.