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.
Severity: normal → enhancement
Component: General → DOM: Core & HTML
I'll leave the decision to Anne.
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.
> There are plenty of users requesting this kind of functionality. Can you back this up with evidence? What are the use cases?
(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.)
(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).
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.
(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.
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.
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
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.
You need to log in before you can comment on or make changes to this bug.