Binding `selected` to `<option>`s via handlebars values doesn't add attributes

[Kerrick]

Ember Twiddle

If you have the following Handlebars in an Ember application:

<select>
  <option disabled>--Select One--</option>
  <option>hello</option>
  <option selected={{true}}>goodbye</option>
  <option>maybe</option>
</select>

You'd expect the "goodbye" option to be selected and to have a selected boolean HTML attribute. It is selected, but it does not have the attribute. This means you do indeed see the "goodbye" in a closed select menu, but using CSS to style option[selected] does not work because the attribute is missing.

[Serabe]

Thank you!

[raido]

I also stumbled on this in my component that wraps bootstrap-select which uses selected attribute to set up it's own logic.

Workaround for now:

{{#if somethingShouldBeSelected}}
  <option selected="selected">...</option>
{{else}}
  <option>...</option>
{{/if}}

[pixelhandler]

@Kerrick @Serabe @raido is this still an issue, perhaps we should close or create a new reproduction of this, what do you think?

[raido]

My project is still has workaround as above so probably but I’ll confirm this in few days.

[Serabe]

@pixelhandler updated https://ember-twiddle.com/63f5290e898dfeee90f7266ce01af5ef?openFiles=controllers.application.js%2C

Still a bug.

[rwjblue]

Hmm, I don’t really grok the twiddle. It’s not clear to me what is expected for each of those selects. Some don’t make a ton of sense to me (e.g. having multiple options with selected but not marking the select as a multi select).

[raido]

‘’’<option selected={{eq foo bar}}>{{foo}}‘’’

This one in the Twiddle exactly my usecase which fails. Option will be selected but no attribute will be present in DOM.

Rest of the twiddle examples look weird to me also as they have multiple values selected, as @rwjblue pointed out, but not multi selects.

[Kerrick]

Yep, the first example in the twiddle is the actual use-case, the rest was just messing around.

[raido]

It seems same happens when you do:

export default Component.extend({
  tagName: 'option',
  attributeBindings: ['isSelected:selected']
});

<option> is actually selected but no attribute in DOM.

[mixonic]

I'm closing this issue as the described behavior is not a bug. That said, I and FW core agree that it is confusing! We consider the mis-match in expectation and behavior a design flaw.

Ember follows a "prop-first if prop available, fallback to attribute" approach to setting a property or attribute when there is a binding in a template. <option selected={{true}}> will set the property of the option element, as expected since selected is a property on the DOM node for an option.

In many cases property values are reflected as attributes, however in this case (selected prop on an option element) the DOM does not have that behavior! In many ways the gap in expectation and behavior is a failing of the DOM API, and not of Ember.

However it is confusing and changing Ember is, relatively, a lot easier than changing the DOM API :-) I have some followups for this:

• @rwjblue says he has a writeup with more details about how this works today in Ember. He will share that here.
• The FW core team has been thinking about this problem for a long time, and we think we have a path forward that wasn't as clear a year or two ago. I'm taking away an action item to draft the RFC for making Ember templates "attribute only, prop via a modifier" and we can continue this conversation there!