1338535 - submitanyway attribute (like readonly)

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[ilisepe1]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20160106234723

Steps to reproduce:

Hello,

This is a proposal for a new feature to have readonly fields (and submit their values).
Currently "readonly" attribute supports only text related fields. It would be very nice to extend this readonly concept to other fields as well like select boxes, checkboxes, etc.

WHATWG agrees to standardize a new attribute called "submitanyway" to achieve this functionality, in combination with "disabled" attribute.

So basically for input type=text and textarea elements we can use the already existing "readonly" attribute, and for the rest fields (ie radio, checkbox, select, multi select) we can use "disabled" plus "submitanyway".

See https://github.com/whatwg/html/issues/2311 for more info.

There are plenty of users requesting this kind of functionality. Obviously there are workarounds but they all involve a lot of unnecessary boilerplate that would be really great to get rid of.

Thank you for your time.

Comment 1

[Andrew Overholt [:overholt]]

I'll leave the decision to Anne.

Comment 2

[ilisepe1]

OK. If you tend to agree with this feature that's great:)
However if you tend otherwise, it would be nice to discuss it a bit, before you make up your mind.
Thanks again.

Comment 3

[Anne (:annevk)]

> There are plenty of users requesting this kind of functionality.

Can you back this up with evidence?

What are the use cases?

Comment 4

[Anne (:annevk)]

(Also, to be clear, what you stated in comment 0 is not true. WHATWG did not agree to standardize anything. Simon is being supportive of your request and has given you some feedback on how to potentially make progress, but that's all.)

Comment 5

[ilisepe1]

(In reply to Anne (:annevk) from comment #3)
> > There are plenty of users requesting this kind of functionality.
> 
> Can you back this up with evidence?
> 
> What are the use cases?

The idea is simple: why should we have only readonly text based fields, when there are other type of fields in a form?
It looks like this preference breaks squared logic.
Sure, there is "disabled", but it will not post values. Sometimes these values can *only* be calculated on the front-end, so we have to post them to the back-end. Image a form where by selecting a value on a checkbox, it needs to run some javascript logic to calculate and set another field. Obviously there are workarounds, like adding extra code to copy values to hidden fields. But we can avoid all that by using "disabled" and "submitanyway". Reducing unnecessary boilerplate is always a good thing, especially when this extra code is another's layer responsibility (browser rendering).

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

Comment 6

[ilisepe1]

(In reply to Anne (:annevk) from comment #4)
> (Also, to be clear, what you stated in comment 0 is not true. WHATWG did not
> agree to standardize anything. Simon is being supportive of your request and
> has given you some feedback on how to potentially make progress, but that's
> all.)

I'm sorry if I misinterpreted their intentions, but I believe that they wouldn't advise me to seek implementors if they hadn't agreed on this proposal. So, if there is implementation interest, then they will revise the standard.
That's how I understood the situation and I surely hope to happen.
I'm apologize if I mistakenly jumped to conclusions.
At least they will consider updating the standard (to me it seems like they don't have any objections).

Comment 7

[Anne (:annevk)]

Well, e.g., othermaciej in that thread represents Apple, and didn't seem convinced, so we'll see. Having said that, your evidence seems somewhat compelling (and something I recommend leading with in future proposals). And the processing model change to form submission also doesn't super complicated, though introducing a new attribute is somewhat involved. It might be worth doing. I recommend sharing your evidence (and perhaps finding more) with the HTML standard issue.

Comment 8

[ilisepe1]

(In reply to Anne (:annevk) from comment #7)
> Well, e.g., othermaciej in that thread represents Apple, and didn't seem
> convinced, so we'll see.

Well, othermaciej hasn't replied to my argument/comment (https://github.com/whatwg/html/issues/2311#issuecomment-277927769). The bottom line is that he chooses the boilerplate workaround, whereas I don't. Everyone is entitled to have an opinion:) IMHO boilerplate workarounds should be avoided and given the fact that HTML is about 20 years old, I think it's mature enough to do something about that.


>Having said that, your evidence seems somewhat
> compelling (and something I recommend leading with in future proposals). And
> the processing model change to form submission also doesn't super
> complicated, though introducing a new attribute is somewhat involved.
> It might be worth doing.

Thanks for your support. If I understand correctly, the actual implementation is not that difficult.
That's certainly another good reason in favor of this feature:)

> I recommend sharing your evidence (and perhaps finding
> more) with the HTML standard issue.

Share where exactly?
Should I relay/communicate my idea to any other community/organization?
I'm not familiar with that kind of procedure.
Please elaborate a bit.

Comment 9

[Anne (:annevk)]

Share with the issue you mentioned in comment 0 (that's the repository for the HTML Standard). I can't really say at this point whether we'll implement it, but given the evidence it seems worth exploring further, especially if we keep it very simple.

Comment 10

[ilisepe1]

Hello again,

Here are a few more examples where this feature seems like a perfect fit:
https://www.sitepoint.com/community/t/read-only-radio-buttons/26225/2
http://stackoverflow.com/questions/1953017/why-cant-radio-buttons-be-readonly
http://stackoverflow.com/questions/7357256/disabled-form-inputs-do-not-appear-in-the-request
https://www.drupal.org/node/357328
http://stackoverflow.com/questions/1191113/how-to-ensure-a-select-form-field-is-submitted-when-it-is-disabled

I could keep looking and always find some new posts talking about similar issues, but I think those examples are enough to make a convincing argument that there is demand behind this feature.

Thank you

Comment 11

[Anne (:annevk)]

Thank you! I guess I wasn't entirely clear before. Mozilla supports exploring this further in the HTML Standard issue you mentioned in comment 0. The next steps would be convincing other implementers, coming up with a design, a pull request for the HTML Standard, and a pull request for web-platform-tests to make sure the new feature is properly tested. You don't have to do all of those yourself of course, but any help is appreciated and might make things move along quicker.