aspnetcore: Can't set custom 'value' attribute for a checkbox

The following code in .html file works but not in a page (.cshtml)

<fieldset>
  <legend>Choose your interests</legend>
  <div>
    <input type="checkbox" id="coding" name="interest" value="coding" checked>
    <label for="coding">Coding</label>
  </div>
  <div>
    <input type="checkbox" id="music" name="interest" value="music">
    <label for="music">Music</label>
  </div>
</fieldset>

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Comments: 15 (7 by maintainers)

Most upvoted comments

While this is a bug, a current workaround is to do something like this: <input type="checkbox" id="coding" name="interest" bind=@coding>

This sets your coding variable to be bound to the input… i.e. when you click it, it updates your coding boolean variable… you can see this by putting @coding in the html page, like so: <input type="checkbox" id="coding" name="interest" bind=@coding> @coding

“Yes, we have repurposed value here and there may be an argument that we shouldn’t in this case.”

I don’t think default attributes should be repurpsed under any circumstance, unless it’s really a dealbreaker if they are not.

For example in Vue you still have the default attributes, but then you can hook them up with vue by typing a colon infront of them, like :value="myValue" or :data-something="something".

I’m going to take a shot at tracking this down in a few hours.

Yes, we have repurposed value here and there may be an argument that we shouldn’t in this case. However I’m not sure what you’d usefully do by setting a custom value attribute on a checkbox in a Blazor app, since that would normally only be used for an HTML form post, which is something people don’t reasonably do in a SPA.

We’ll have to give this further considation. Adding to backlog.

Because “value” is being repurposed (which is a bad idea in my opinion) you cannot do the <input value=@MyProperty onchange=@(eventArgs => { MyProperty = eventArgs.NewValue; DoSomethingElse(); }) /> @SteveSandersonMS suggestion (here) to have both a value and an onchange. There are also suggestions that we use the @bind and then do some kind of model pollution in the properties setters to fire your DoSomethingOnChange method. This works for simple models, but not good for lists of things.