let say I have
= simple_form_for @copy_content do |f|
= f.input :copy_emails, as: :radio_buttons, collection: [['Yes', 'true'], ['No', 'false']]
= f.submit 'Submit'
the Yes radio button is fine but the No (false value) radio button has a "readonly" property
(same apply when i have [['Yes', true], ['No', false]] )
<div class="form-group radio_buttons required copy_content_copy_emails">
<label class="radio_buttons required control-label"><abbr title="required">*</abbr> Copy emails</label>
<span class="radio">
<label for="copy_content_copy_emails_true">
<input class="radio_buttons required" type="radio" value="true" name="copy_content[copy_emails]" id="copy_content_copy_emails_true" />Yes
</label>
</span>
<span class="radio">
<label for="copy_content_copy_emails_false">
<input class="radio_buttons required" readonly="readonly" type="radio" value="false" name="copy_content[copy_emails]" id="copy_content_copy_emails_false" />No
</label>
</span>
</div>
is this a bug or a feature? ( http://www.eq8.eu/bug.png ) ... if a feature, can someone explain to me why ?
thx
just to clarify, event if the collection options are [["Foo", 'will-work'], ["Bar", 'me-too'], ["Car", 'me-three'], ["Dar", 'false']], Foo Bar Car will be normal Dar will be read-only
@equivalent yeah, it's a bug. The problem is that when we have optional :readonly we have readonly: false in the input options that propagates to rails helper - https://github.com/rails/rails/commit/dfac1b188e98d59bda0fac1148c417a9761f7b54 and false option becomes readonly. Not really sure how we can properly fix it. @carlosantoniodasilva @rafaelfranca what do you think guys?
Can we stop to put readonly option in the hash?
Hi!
I have the same problem. Do you know any workaround to allow readonly to be false ?
Kind regards,
Sylvain
+1
It's a hard problem for me because some CSS framework become unusable with the readonly thing...
I cant' check my radio button anywore with the R2.0 of www.semantic-ui.com for example :(
Thanks for your help !
So, this may not be applicable to library maintainers, but for people running into this issue in your application...
tldr; This looks like a feature for users of rails, and a bug for users of rails _and_ simple form.
After looking at the rails code that adds the readonly option, it seems like if you delete the simple_form configuration line b.optional :readonly, then you should be fine. Consider the two cases:
A. You _want_ the input to be readonly. If you do f.input :foo, readonly: true, then your input will be readonly because rails will see the readonly option as non-nil.
B. You _don't_ want the input to be readonly. If you don't include the option at all (after removing it from your config) then rails will skip it because the value will be nil. (e.g https://github.com/rails/rails/blob/dfac1b188e98d59bda0fac1148c417a9761f7b54/actionview/lib/action_view/helpers/tags/collection_helpers.rb#L49)
I kind of hate the semantics of this option, but can see why it was implemented this way: in html the readonly option is "readonly" if the readonly attribute is present. That said, we're not writing html, we're writing ruby that writes html, so perhaps we can consider it an improvement. My guess is that there will be two camps, but I think a PR to rails with some discussion/empathy is totally worthwhile.
If rails won't change, it seems like simple_form could detects rails > whatever version introduced this rails feature, and just noop -- perhaps with deprecation?
What do the maintainers think?
The workaround worked for us, thank you very much @tonywok !
Just came across this issue when I was googling why the HTML validator was throwing errors when validating my form. I got this:
Attribute
readonlyis only allowed when the input type isdate,datetime,datetime-local,month,number,password,search,tel,text,time,url, orweek.
MDN says:
readonly
This attribute indicates that the user cannot modify the value of the control. The value of the attribute is irrelevant. If you need read-write access to the input value, _do not_ add the "readonly" attribute. It is ignored if the value of the type attribute ishidden,range,color,checkbox,radio,file, or a button type (such asbuttonorsubmit).
HTML5 spec says:
Note
The difference betweendisabledandreadonlyis that read-only controls are still focusable, so the user can still select the text and interact with it, whereasdisabledcontrols are entirely non-interactive. (For this reason, only text controls can be made read-only: it wouldn't make sense for checkboxes or buttons, for instances.)
Given the above, it would be save to skip this attribute when those controls are about to be rendered. I am not a ruby developer, hence my question, is that feasible?
Cheers
Patrik
A workaround (in case you don't want to change config) is to do this:
= simple_form_for @copy_content do |f|
= f.input :copy_emails, as: :radio_buttons,
collection: [['Yes', 'true'], ['No', 'false']],
readonly: nil
= f.submit 'Submit'
or as actuall boolean values:
= simple_form_for @copy_content do |f|
= f.input :copy_emails, as: :radio_buttons,
collection: [['Yes', true], ['No', false]],
readonly: nil
= f.submit 'Submit'
Thanks for this post folks, just spent ages on this one so pleased to find I'm not alone and that there's a solution. Both options worked for me, though just FYI i still get a warning when you running my tests of Attempt to set readonly element with value: true * This will raise an exception in a future version of Capybara when using the readonly: nil solution.
readonly: nil worked for me
Closing it since the solution seems to be readonly: nil.
Thank you
Hi, I've run into this recently and have finally found a reason for it in the guide documentation! The issue is the if the Vue "v-bind" directive (or short-cut of colon ":") is not added to "value" attribute of the radio button, the Boolean false value is converted to the string 'false' after a few transitions of the radio button group! Since "false" === false, the readonly attribute is applied to the element when it shouldn't be!!!
...V-bind forces Vue to treat as JavaScript expression rather than a string...
<!-- Even though `42` is static, we need v-bind to tell Vue that -->
<!-- this is a JavaScript expression rather than a string. -->
<blog-post v-bind:likes="42"></blog-post>
<!-- Dynamically assign to the value of a variable. -->
<blog-post v-bind:likes="post.likes"></blog-post>
This change from a Boolean (not surrounded by quotes) to a String (surrounded by quotes) is visible in Vue devtools!
Most helpful comment
A workaround (in case you don't want to change config) is to do this:
or as actuall boolean values: