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?