Provide a way to have disabled form controls to be submitted (was: readonly attribute)

[ilisepe1]

Hello,

As I understand, HTML "readonly" attribute applies only to text based form elements (ie text, textarea).
At least that's how firefox/chrome behaves.
Wouldn't it be nice to work on every form element ((multiple)selectbox, checkbox, radios, etc)?

(Just like the "disabled" attribute that works to all form elements.)

Thank you.
Ilias

[zcorpan]

See https://html.spec.whatwg.org/#the-input-element:attr-input-readonly-3 for which types it applies.

What would it do for the other types? Why would it be nice? What problem are you trying to solve?

[ilisepe1]

The url basically verifies what I said: that "readonly" applies only to text based form elements.

What would it do for the other types?

The important thing is to prohibit the users from changing the value. For example, if it's a multiple select, let them scroll in order to see which values are selected (just like readonly works with textarea).

Why would it be nice?

Because it already exists in text based form elements and in terms of squared logic it should be also applied to other form elements as well.

What problem are you trying to solve?

Imagine a form where a user should be able to change only certain fields, while others must be "readonly". You could say that I could just use "disabled" instead of "readonly". The problem with disabled is that it doesn't post the value. And there are cases where the value must be posted (ie the value is calculated in the front-end, and the back-end can't calculate it). There are workarounds, but it would be way easier if the browser could do it.
So, in one sentence: I don't want to let the user change a value, but post the value on submit.

[zcorpan]

Previously:
https://lists.w3.org/Archives/Public/public-whatwg-archive/2011May/0010.html

[ilisepe1]

Well, everybody can have his own opinion.

I believe that there is valid business behind it to support this feature (as explained above).
And it appears that so does a lot of other people too. Google returns more than 38 million entries on this feature (html readonly but post).

Is there any workaround? Sure there is, but it requires extra code and depending on the project this might be easy or very difficult (imagine a generic form builder platform for example).

So, since it's do-able with one or another way, why not just do it with a single word: "readonly"?
We can debate for years about it, or we can sit down and fix it. It will save much energy and time:)

Thank you

[zcorpan]

@othermaciej makes good points in the email cited above that I think you would need to address if you want to have any success in convincing implementors to change this. (Maciej's opinion is very relevant in terms of what is likely to be implemented or not in WebKit.) In particular a new attribute like submitanyway for the behavior to submit a disabled control seems strictly better because it avoids confusion/expectations about UI, it is feature-checkable, and has less problems during the transition period until all browsers have implemented the feature.

https://bugzilla.mozilla.org/show_bug.cgi?id=88512 shows that readonly for checkboxes has been considered and rejected for Gecko.

[ilisepe1]

Hello again,

Mozilla obviously dropped this bug, because it's not a bug.
The spec states that readonly is only for text fields:

"readonly (readonly) #IMPLIED -- for text and passwd --"

ref: https://www.w3.org/TR/html4/interact/forms.html#edef-INPUT

It might not be in the BFN of the spec, but it has the comment "-- for text and passwd --" next to it.
Is the spec ambiguous? Looks like it might be, because it's not 100% clear:

"The following elements support the readonly attribute: INPUT and TEXTAREA."

ref: https://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#adef-readonly

Looks like the whole readonly feature is a textbook case of resistance to change to me.

As I said before, we can debate years on a simple feature, but that's just pointless.
Readonly is a perfectly valid concept and therefore has to be added in the HTML spec for all editable fields (so obviously I don't mean the buttons). Looks like there is great demand on this feature, so many people as asking for it. As mentioned before, google returns more than 38 million entries on this feature (html readonly but post).

In particular a new attribute like submitanyway for the behavior to submit a disabled control seems strictly better because it avoids confusion/expectations about UI, it is feature-checkable, and has less problems during the transition period until all browsers have implemented the feature.

• submitanyway works for me, but seems like a semi-measure. If I were to choose between readonly and submitanyway, I would choose the former. As I understand it, submitanyway is supposed to be used along with disabled. By doing that, the user won't be able to copy something, or even worse, he won't be able to scroll on a text field if the value exceeds the field's length. Fortunately textarea suffers only from the copy problem (scrolling works).

• I don't see any kind of UI confusion when a field is readonly. The end-user will see it grey, just like with disabled, but it will post the data. End-users don't even know what post is. They only care about what they see.

• I also don't understand the problem with the transition period that you mention. Both solutions will have this issue since it's a new feature. Perhaps I'm missing something on your point.

To those that advocate against readonly feature, because they claim that we should not rely on UI to restrict access on certain fields, I say that everybody need to focus on his/her own work. Sure, we need both front-end and back-end solutions. But HTML is only about the front-end. So, you (@othermaciej et al) need to deal with the fact that we need this feature at the front-end. What we'll do as full stack developers is our choice and we'll deal it at the back-end if needed.

I think my arguments are fairly reasonable. Please do let me know otherwise.

Thank you for your time

[zcorpan]

Mozilla obviously dropped this bug, because it's not a bug.

Right. The reaction could have been "Oh, let's change the standard" (like you propose here), but it wasn't.

Let's ignore what HTML4 says, it's not relevant.

As mentioned before, google returns more than 38 million entries on this feature (html readonly but post).

The first page of results is mostly relevant, but it seems to me most of the hits have nothing to do with the feature you're asking for. So it's an irrelevant number.

submitanyway works for me, but seems like a semi-measure. If I were to choose between readonly and submitanyway, I would choose the former. As I understand it, submitanyway is supposed to be used along with disabled. By doing that, the user won't be able to copy something, or even worse, he won't be able to scroll on a text field if the value exceeds the field's length. Fortunately textarea suffers only from the copy problem (scrolling works).

For controls where readonly already applies, you can use readonly if you want to let the user be able to select and copy text. This issue is about controls where readonly does not apply, and for those there is no text to copy.

I don't see any kind of UI confusion when a field is readonly. The end-user will see it grey, just like with disabled, but it will post the data. End-users don't even know what post is. They only care about what they see.

The point is that <input type=text readonly> is not gray like a disabled one is.

I also don't understand the problem with the transition period that you mention. Both solutions will have this issue since it's a new feature. Perhaps I'm missing something on your point.

Assume one browser has implemented the new feature, and the others have not yet. To use it, you still need to have some sort of fallback (like a polyfill) to get the right behavior in the other browsers. How would you check for support for <input type=checkbox readonly>? You would have to submit a dummy form with such a control and see if its value was submitted, which is an async and annoying operation, to the point that it seems easier to not bother with detecting if it is supported and applying the workaround for everyone.

With a new attribute, feature-checking is simple:

var supportsSubmitAnyway = 'submitanyway' in document.createElement('input');

[ilisepe1]

Right. The reaction could have been "Oh, let's change the standard" (like you propose here), but it wasn't.

I guess that they didn't care, since it was not their responsibility.

The point is that is not gray like a disabled one is.

Right: the appearance between disabled and readonly is not exactly the same (at least with firefox). With readonly the background is grey, so the user is still hinted. The developer can always change it with css to fit his/her needs. Anyway the appearance is not defined by HTML specs. Right? It depends on the implementation. So, I guess the looks is out of our scope.

With a new attribute, feature-checking is simple

That's a good point indeed.

The thing is that businesswize, disabled with submitanyway differs with readonly, because we need the copy/scroll (at least on text fields).
So why not introduce a new attribute like ro (and possibly depreciate readonly) or change the type of readonly to string (so if it's boolean you know that it's the old way to do the feature-testing)? The latter is more tricky but favors the squared logic. Regardless of which of these two solutions we choose to add in the spec, the result should be the same: allow them to copy/scroll, don't allow the user to change value(s) and post on sumbit.

[zcorpan]

Hixie participated in that bug, and he was revamping the forms standard at that time to add new features. He took on responsibility to fix the standard, but did not add this feature.

Rendering is defined in https://html.spec.whatwg.org/#rendering although it is lacking for form controls in general and doesn't say anything about disabled per se... Filed #2320 Anyway, the current state of the standard doesn't invalidate Maciej's argument that readonly carries web developer expectations about UI which should not apply to this feature (since you want these checkboxes to be gray).

The thing is that businesswize, disabled with submitanyway differs with readonly, because we need the copy/scroll (at least on text fields).

You don't have to use disabled + submitanyway on your text fields just because it exists. readonly will continue to work. So that is not an issue?

So why not introduce a new attribute like ro (and possibly depreciate readonly)

That seems to confuse matters even more...

or change the type of readonly to string (so if it's boolean you know that it's the old way to do the feature-testing)?

I suspect that is not web compatible.

[zcorpan]

I think what this issue needs is stated interest from a browser vendor to solve this problem at all. Bikeshedding about the syntax isn't going to get us forward.

[ilisepe1]

Hixie participated in that bug ...

This is Hixie's only useful-on-the-topic post that I found from the bug report that you mentioned and I quote it here:

The user can always change the DOM on the fly and resubmit the form with those
radio buttons changed. So that's not something to rely on anyway.

I think I've made my argument about this idea on my previous posts:

• "You need to deal with the fact that we need this feature at the front-end. What we'll do as full stack developers is our choice and we'll deal it at the back-end if needed."

• "And there are cases where the value must be posted (ie the value is calculated in the front-end, and the back-end can't calculate it)"

What I'm trying to say is that Hixie didn't add the readonly feature simply because he was not convinced that it was needed. But this rises another question: should this responsibility be appointed to just a single person or to a group of people? I vote for the latter.
Just because one person decides to do or don't do something, it doesn't make it right by default.
I'm certainly not judging Hixie here, I'm just trying to figure out the setup behind the decision making.
And if this is just one person's burden, well, then I sincerely urge you to rethink your decision making strategy.

You don't have to use disabled + submitanyway on your text fields just because it exists. readonly will continue to work. So that is not an issue?

So you basically say that for input type=text and textarea elements I will continue to use readonly and for all the rest (ie radio, checkbox, select) I will use disabled + submitanyway?
Fortunately scrolling on multiple select is working with disabled:)
That's a viable solution, although it breaks the squared logic.

That seems to confuse matters even more...

Why? You introduce a new attribute that has a new function. It happens all the time:)

[ilisepe1]

I think what this issue needs is stated interest from a browser vendor to solve this problem at all.
Bikeshedding about the syntax isn't going to get us forward.

I'm not sure I quite follow you.
Don't you have to update the standard first?

[zcorpan]

My bringing up Hixie was in response to your comment:

I guess that they didn't care, since it was not their responsibility.

I had in mind this comment in particular: https://bugzilla.mozilla.org/show_bug.cgi?id=88512#c28

That is, I claim that somebody cared and took responsibility. That is all. It does not need to affect what we do today. 😊

So you basically say that for input type=text and textarea elements I will continue to use readonly and for all the rest (ie radio, checkbox, select) I will use disabled + submitanyway?

Correct.

I'm not sure I quite follow you.
Don't you have to update the standard first?

No. See https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F although actually steps 7, 8 and 9 should happen more in parallel. We need stated interest from 2+ implementors and tests before landing changes to the standard. Also see https://blog.whatwg.org/improving-interoperability

[ilisepe1]

So, I basically have to contact firefox and chrome developers and convince them that this is a hot topic to start working on it? :)

[othermaciej]

For the specific use case of making a control disabled to the user, but still submitting the contents, it seems like this can be achieved by having a parallel that contains the same data. Your client-side logic would have to update both of course.

I am not saying this is a super elegant way to do it, but the use case seems very narrow, and I am not sure it is worthwhile to add a new feature for it. The use case, as described, is that some state is calculated on the client side, must be shown to, but not edited by the user, and can't readily be recalculated by the server. That seems pretty rare. And there is a workaround. Admittedly a clunky one, but for a rare case, is that not good enough?

[ilisepe1]

Do you remember blink or strong or small tags? I'm sure almost nobody has ever used them. Yet, there are available.

I believe a good standard shouldn't consider only just how popular a feature is, in order to incorporated it or not. Instead, it should help as much as possible the users to work as better as possible, and adding a bunch of extra unnecessary boilerplate in their code to do something that is basically the responsibility of another's layer (the browser), given also the fact that it's 2017 (and not 20 years ago), certainly isn't much of a help.

By definition, workarounds exist because something else doesn't work as it should.
I think that's how you should address features.

There is always the option to continue arguing about this for the next 20 years, or fix it in just a few days. Logic and evolution votes the latter. Resisting to change is pointless, just embrace it:)

[chaals]

Hi @othermaciej, in my 10.0 version of Safari, readonly attributes work on input type="color", input type="range".

Has that changed in 10.1?

[othermaciej]

@chaals Pretty sure that's a bug in both cases.

[chaals]

Quite possibly.

For range Safari matches behaviour in blink. color is because it is not implemented, so behaves as a plain text input, which is according to spec…

Currently it means that there is no interop for these input types - which was the case a year ago when I was looking, so there doesn't seem to be a lot of motivation from browsers in deciding one way or another.

[ilisepe1]

So, any comments on my last post?
How do we proceed from that point?
As I understand, I basically have to contact firefox and chrome developers and convince them that this is a hot topic to start working on it? :)

[zcorpan]

@ilisepe1 yes. I recommend filing an issue and point to this one.

https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
https://bugs.chromium.org/p/chromium/issues/entry

[zcorpan]

@chaals <input type=color readonly> for chromium was fixed in https://bugs.chromium.org/p/chromium/issues/detail?id=249515

I did not find any other issues about readonly applying (or not) for color or range in webkit/chromium/mozilla bug trackers.

Filed:
https://bugs.chromium.org/p/chromium/issues/detail?id=693037
https://bugs.webkit.org/show_bug.cgi?id=168421
https://bugs.webkit.org/show_bug.cgi?id=168422

(No wpt since this requires user interaction.)

[zcorpan]

Back on topic...

https://bugzilla.mozilla.org/show_bug.cgi?id=1338535
https://bugs.chromium.org/p/chromium/issues/detail?id=690927 (no activity yet)

In the mozilla bug @ilisepe1 commented

Other people looking for something similar (just googled for readonly select box, checkbox, radios, etc):
http://stackoverflow.com/questions/368813/html-form-readonly-select-tag-input
http://stackoverflow.com/questions/37762671/how-to-create-readonly-select-box-but-i-will-post-that-value
http://stackoverflow.com/questions/155291/can-html-checkboxes-be-set-to-readonly
http://stackoverflow.com/questions/4727974/how-to-post-submit-an-input-checkbox-that-is-disabled

Myself and @annevk discussed this a bit in #whatwg

<zcorpan> annevk: i checked the stackoverflow threads, and indeed it seems a lot people are running in to this issue, and the workarounds seem pretty messy... the least messy is maybe removing disabled onsubmit and adding it again after, but that results in a flash-of-enabled-controls...
<annevk> zcorpan: it's also a rather trivial change to the processing algorithm, just need to decide on how to expose it
<annevk> zcorpan: one thing that seemed rather nice to me was disabled="submit", but the API-side of that would be less clean
<zcorpan> yeah i think we should have a new attribute
<zcorpan> but "anyway" is not clear what it's referring to
<annevk> zcorpan: I'm in favor I suppose of moving forward here, specifics hopefully sorted out by someone else
<zcorpan> submitdisabled="" maybe
<annevk> zcorpan: could also be a flag on <form> potentially
<zcorpan> per-control is more flexible
<annevk> disabled="submit" could work if you reflect it through disabledState
<zcorpan> we also have <fieldset disabled> which is a bit special
<annevk> Oh stuff inherits?
<annevk> Hmm okay
<zcorpan> inherits except into the <legend>
<zcorpan> considering <fieldset disabled> i think it should be a separate attribute. you may want to toggle disabled for a whole fieldset, but always submit a specific control inside
...
<zcorpan> annevk: software.hixie.ch/utilities/js/live-dom-viewer/saved/4891
...
* zcorpan finds 302 matches of '<fieldset(?:\s[^>]+)?\sdisabled\b' in httparchive

[ilisepe1]

Better title:)
Perhaps it would be more search-friendly if you added the "readonly" term somewhere, like: Provide a way to have disabled form controls to be submitted (readonly fields).
That's just a recommendation, I leave it up to you...

I'm glad that you are discussing the feature.
Mozilla seems more engaging than Chrome at the moment. We'll see...

[zcorpan]

Looks like there is tentative support from Gecko and Chromium:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1338535#c11
• https://bugs.chromium.org/p/chromium/issues/detail?id=690927#c4

@othermaciej - the stackoverflow threads suggest this is not in fact a rare problem, and the workarounds are clunky indeed. Is it reasonable to expect WebKit to follow if we standardize something here and it is implemented in Gecko/Chromium, or are there any objections?

[othermaciej]

@zcorpan If it goes in the standard, WebKit would not specifically hold out, though it wouldn't necessarily be a high implementation priority. It's not important enough either way to be worth fighting over.

I will say that I do not personally find the case for this feature compelling. Five question threads over a span of seven years is not very strong evidence of demand for this functionality. As a counterpoint, I note that apparently JS framework authors have not added anything to support this specific use case. JS frameworks typically have a lot more convenience features than the base platform, yet they have not judged it worthwhile to provide a packaged workaround.

On the cost side, form controls and their many attributes are already a complicated area of the web platform, and fairly complicated implementation-wise. The bar for adding a new attribute to that is ultimately a convenience feature should be pretty high. It's likely we'll have complexity creep for forms anyway, for new basic capabilities. So the payoff should be really high.

In conclusion, while I don't specifically think the feature is terrible, there is some cost to adding it, and in my opinion the evidence does not show strong demand.

Further, I would not necessarily interpret the comments in the Gecko and Chromium as "tentatively support". The most I could say of those comments is that they show non-refusal. Is this because developers of those engines actively think it's a good idea, or merely that it wouldn't be worth disputing if it was in the spec? These comments show that the feature would not be blocked but I don' think they make a positive case for adding it.

Notwithstanding my opinion (that this feature does not add enough value for the complexity cost), we'll respect the judgment of the spec editors on this. If it's in the spec and in other browsers, then we'll very likely implement it sooner or later. Please do not interpret this statement of non-refusal as tentative support though.

[othermaciej]

(As a further aside, I think it was probably a mistake in the original design of forms that disabled controls are not submitted. If it wasn't decades too late to reverse that decision, I'd call for reversing it. But I think having both modes with an explicit switch is worse than having just the inferior mode.)

[domenic]

As a counterpoint, I note that apparently JS framework authors have not added anything to support this specific use case. JS frameworks typically have a lot more convenience features than the base platform, yet they have not judged it worthwhile to provide a packaged workaround.

I wanted to say that I find this a compelling counterargument.

Ideally what we should be seeing here is @ilisepe1 producing a library or framework plugin that gets wide adoption, before we put it in browsers. The wide adoption would prove not only that this is a problem lots of people have, but it would also prove that it's possible for a single simple solution to serve everyone's needs.

The worst case would be finding out that the proposed "submitanyway" attribute only addresses some small fraction of the use cases that are cited in support of this issue, as then we've added a new feature to the platform for very little gain.

[ilisepe1]

Hello all,

Since it was cited, I can't agree more with the first part of @othermaciej's last coment. I can't stress enough though that I disagree with the conclusion, because it's like saying "ok, I admit the problem, but let's not do anything to fix it".

Anyway, I have to acknowledge it's very encouraging (to logic) that you at least consider committing to this feature. In my head, it makes perfect sense and surprises me why it's not already included, but enough with me grumbling.

On the other hand, I never thought that you (whatwg) would tell me to get involved on this feature actively. So, if I understand correctly you ask me to dive into firefox code and implement this feature?
Because if it looks "fairly complicated implementation-wise" for @othermaciej (as he mentioned previously), imagine how it would look to me, that have absolutely no idea of the insides of firefox.

However, I am willing to try as long as someone points me at least to the specific source files/folders that deal with this feature.

Unless, you ask me to do something on top of it (ie with js), which sounds scary since I'll have to control things on a higher layer (ie dom) for things that a lower layer is responsible (browser). Looks like a bogus/bloated project.
The closest approach is to use onfocus="this.blur()" onclick="return false" along with a grey/faded css to give the looks of "disabled", but this trick works only on firefox (and not with their latest version because it's a confirmed bug).

I'm open to ideas.

Thank you

[domenic]

On the other hand, I never thought that you (whatwg) would tell me to get involved on this feature actively. So, if I understand correctly you ask me to dive into firefox code and implement this feature?

That's not what at least I meant. What I meant is producing a JavaScript library that e.g. watches the DOM for any form elements, and attaches a submit listener to them that enables all disabled controls marked with data-submitanyway attributes, then posts a microtask to re-disable them. This would effectively "polyfill" the behavior you are proposing.

We can then see if your library gets a lot of usage, to find out if it's actually a widespread problem, and to find out if your proposed solution solves the problem for everyone.

[chaals]

See also w3c/html#89 w3c/html#91 w3c/html#92

The use cases seem pretty clear, the question in terms of priority, as @othermaciej points out, is how often people are doing this. The problem is that without a straightforward solution, there are a number of different strategies, including:

• disable the control's behaviour, as suggested above by @ilisepe1
• enable the control on submit, as suggested by @othermaciej
• reflect the disabled control in a hidden input

Since all of these can be accomplished in multiple ways, that makes it very hard to find out how common they are. Adding another approach as a polyfill can provide a measurable quantification of uptake, but the delta is only those who find it and decide it is more convenient than to continue using one or other existing technique, so its a slow and extremely conservative way to learn anything.

The question of web compatibility is also hard. Since unimplemented input types default to text, which means readonly works, it seems unlikely that those with patchy implementation have a compatibility problem. Common HTML 4 types like checkboxes and so on might be different.

Newer implementations of input types also repeatedly seem to get readonly behaviour when shipped, and then get fixed later to match the spec. Since I assume browser developers are not obviously fools, this suggests that the idea of readonly working on non-text controls doesn't strike them as a priori foolish enough to change even though it contravenes the spec.

None of which answers the prioritisation question, so much as pointing out that the data is harder to read than it seems :(

[ilisepe1]

Hello all,

After @domenic's suggestion, project created.

It's just a draft yet, but it seems to be working.
Comments/suggestions are always welcomed.

I hope there is support from the users, although I'm not sure how they will find it:)

[zcorpan]

@domenic created a poll on twitter:
https://twitter.com/domenic/status/839906226049810434

21% out of 318 answered "Yes". Some relevant comments:

https://twitter.com/harmenjanssen/status/840097921894772739

Yes, even more so because <select> does not support the readonly attribute.

https://twitter.com/medikoo/status/839941581520130050

yes, readonly would be a solution if it'll be supported on all inputs (as a solution we emulate it via scripts)

https://twitter.com/tabatkins/status/839915334089990147

I've had to add hidden form controls to submit the value the disabled control represents.

https://twitter.com/pracucci/status/839910665296961536

yes. My use case: disable the form while saving changes in background.

[ilisepe1]

wow, 21% :)
Do we have a winner?

+1 to https://twitter.com/harmenjanssen/status/840097921894772739 and https://twitter.com/medikoo/status/839941581520130050 :)

Perhaps you should tweet my little project to check responses?

Just to update you, I also found another project similar to what we are discussing here:
https://github.com/haggen/readonly
He's using a different approach, but the idea looks like is exactly the same.

And another one (for select tags only): https://gist.github.com/jpetitcolas/4395080

[ilisepe1]

Ok, I just wanted to share that there is another problem with disabled elements. Seems like you can't dispatch events to them. Probably this has nothing to do with you, or does it?
Seems like the problem is with firefox only, it's working with chrome.
Interesting way of standardization:)

[patrickdark]

Just ran into this problem in designing a Firefox extension options page. It is very unintuitive that checkboxes cannot be made read-only especially after one has done it with ARIA aria-readonly attributes using emulated, script-based checkboxes. (The ARIA 1.1 draft specification explicitly lists that attribute as applicable to checkboxes.)

Furthermore, this issue is unexpectedly difficult to polyfill. Using the Event.preventDefault method on the change, keydown, and mousedown events apparently does nothing for checkboxes, so the obvious solution doesn't work. I ended up using pointer-events: none and tabindex="-1", but this broke a CSS cursor: not-allowed declaration and I was forced to move that to a span element containing the checkbox.

Add to that styling issues: if you want what one might call the "read-only appearance", then one has to disable the checkbox anyway thereby mooting the above fix. You can't create it yourself short of just replacing the element outright since browsers like Firefox don't allow one to style the checkbox border or content. I even tried CSS outline paired with a negative outline-offset to create a grayed-out border, but that doesn't work since Firefox frustratingly gets the outline one pixel off on a single side.

While read-only isn't strictly required for this use case, it seems to me to be good UI to disable options that that aren't relevant based on other options. There's no reason for a user to need to tab through a checkbox that doesn't matter, for example, and it makes the UI easier to understand at a glance since one's visual focus will move to the stuff that doesn't have the "read-only appearance". (In the case of my UI, I also gray-out irrelevant form control labels to improve readability.)

Lastly, I think a submitanyway attribute solution is a bad idea because it will be paired with disabled which will cause the form to submit nothing in browsers that don't support it. Better to have a readonly form control be writable and submitted than read-only and not submitted.

[felixfbecker]

I was very disappointed to see <input type="color" value="..." readonly> doesn't work. It would be very useful to display colors consistently in an application that cannot be changed, but where you still want the user to be able to trigger the native OS color picker UI where you can see the individual components of the color broken down, where it sits in the hue wheel, potentially UI to add it to an OS-level favorite color palette etc. Just not apply any changes. disabled works, but will make the input non-interactive, i.e. it will not open the picker UI.

[patrickhlauke]

Apologies for jumping in late on this discussion, but: note that using ARIA, it is currently possible (and valid) to set aria-readonly="true" on checkboxes and radio buttons (and possibly, though @scottaohara may know more, even other input types like <input type="color">?). This is reflected in the accessibility tree and exposed to assistive technologies, and it allows these form controls to be both non-changeable (as they're read-only, though this needs to be handled programmatically with JS), but also submitted as part of the form submission. This has been discussed a while ago over here w3c/aria#1309 and there are arguments in that discussion about why this is a good thing etc. My main concern here is that ARIA essentially diverges from the standard semantics/capabilities of HTML, for a feature/functionality that should not just be limited to assistive technology users but baked right into the core standard itself. It feels odd that there is this particular mismatch.

[vdh]

I find it problematic that someone with higher permissions managed to subvert this issue away from discussion about readonly attributes with a title change. It's conflating readonly and disabled together based on visual assumptions, with some bike-shedding about proposing another form submission mechanism thrown over the top.

There are real distinctions between read-only and disabled states that people have tried to voice, but it was muddied by this sidetrack into this tangentially-related proposal to mess with disabled input form submissions. "Disabled inputs that submit" is not a one-to-one equivalent to a read-only input, and dismissing read-only as some sort of inferior variant of disabled inputs is disingenous.

Read-only is an input that is part of the form, but not editable. This could be a transitional state based on other factors. It is still a value in the form. Disabled is an input that is not available. While some visual appearances are similar (particularly for checkboxes/radios), they are not equivalent states. The underlying values that this form is managing is where the distinction between read-only or disabled is occuring. It is an attribute of the data management in the form, not the UI element it has currently been wired up to.

It's frustrating that this is clearly a distinction that is important and permissible to text inputs, but for arbitrary reasons, this distinction is denied to every other input type. A lot of other form elements submit strings, just like text inputs, but those opposed to readonly support haven't clarified why they should be denied this. Read-only as a concept isn't just limited to only the UI implementation detail of text selection. As mentioned, the color input could provide a meanful distinction in its UI based on the two data states.

This handicap with the HTML spec / native inputs usually get bypassed by encapsulating the limited input tags within a more functional wrapping "component" (all the way back in the jQuery days, down to current-day components like React or similar). When you're already bypassing the native checkboxes to provide better visuals, you're also bypassing the lack of read-only support at the same time. The form submission and data management are usually bypassed as well, managed entirely in Javascript. You may not be able to easily find evidence of this directly in libraries, but that's where "read-only" support is usually shimmed in. Native form handling is bypassed completely, so I doubt many feel motivated to ask for a fix for something they've already completely re-routed around. Hence the relative lack of noise about read-only, because the developer is usually so far removed from the native forms that only the most studious of us that look under the hood feel motivated to raise the issue on the lack of read-only support. It's sad and frustrating that this needs to be routed around to such extremes just to get this basic functionality that's missing from native forms. I'd really prefer to just use a simple, native (ARIA-accessible) tag instead of pulling in layers of dependencies just to shim in a decent form input. But it feels like we're just caught in this catch-22 where the spec wont ever be allowed to change for the better, so the browsers wont ever ship better inputs, so devs never feel compelled to stop hacking around native forms.