Boolean Attribute parsing

[thec0keman]

Recently we merged a PR in Emblem that restored automatic quoting of non-event HTML attributes:

# Emblem 
input enabled=foo
=>
<input enabled={{ foo }}/>
Now returns:
<input enabled="{{ foo }}"/>

(This functionality was for non-Ember apps using Emblem).

However, this breaks with Ember's coercion of boolean attributes:

<select multiselect={{ foo }}>
with:
true => exists
false => does not exist
'' => does not exist
null => does not exist

<select multiselect="{{ foo }}">
with:
true => exists
false => exists
'' => does not exist
null => does not exist

The issue is that Ember (or Glimmer) will treat the string "false" as a truthy value. On the one hand this makes some sense, since Ember is already coercing variables to strings, and as far as it is concerned this syntax is saying 'no we really do want a string'. On the other, it is automatically detecting true / false / blank strings, and a case could be made that the string false should also be detected.

Is this intended that the string 'false' will be treated as a truthy value?

Thanks!

[Serabe]

On the other, it is automatically detecting true / false / blank strings, and a case could be made that the string false should also be detected.

Can you please clarify this part?

I'm not sure this can be categorized as a bug, given 'false' is true in any way I can think of in JS.

[thec0keman]

Definitely. 'false' is truthy in javascript. But in Ember these are very different:

<input disabled=someBoolean/>
<input disabled="{{ someBoolean }}"/>

As I mentioned, I think the latter is probably a syntax error. I don't think I've seen any examples in the Ember docs of this, but I just wanted to clarify that this was the intended behavior.

[Serabe]

Did this behavior worked at some point in the past?

[thec0keman]

I'm not sure, not to my knowledge

[Serabe]

@thec0keman I discussed this and I am sorry to tell you that we are closing this as not a bug. Changing this behaviour would affect other Ember users and cause strange behaviour in some scenarios (data-x={{y}} vs data-x="{{y}}").

Thank you and sorry for the inconveniences.

[thec0keman]

@Serabe no worries. I think you answered my question sufficiently, and we came up with an alternative approach for emblem. Thanks!