Inconsistent SSR of Boolean attributes

[axel-habermaier]

Consider the following example code:

function Attr() {
  return (
    <>
    <input checked={true} />
    <input checked />
    </>
  );
}

In SSR mode, this gets transpiled to:

import { ssr as _$ssr } from "solid-js/web";
import { ssrHydrationKey as _$ssrHydrationKey } from "solid-js/web";
var _tmpl$ = ["<input", " checked=\"\">"],
  _tmpl$2 = ["<input", " checked>"];
function Attr() {
  return [_$ssr(_tmpl$, _$ssrHydrationKey()), _$ssr(_tmpl$2, _$ssrHydrationKey())];
}

While technically correct according to MDN, the two templates should not differ. I'd expect <input checked={true} /> to also result in the template ["<input", " checked>"] as opposed to the actual ["<input", " checked=\"\">"].

Furthermore, if the value of the checked property is computed at runtime, i.e., <input checked={Date.now() > 0} />, the rendered HTML string also is <input checked>, inconsistent with the <input checked=""> generated by the transpiler when the value is a constant.

[titoBouzout]

Besides the different output, does it make any difference? There has been some effort into making all of this more predicable, which is a work in progress (so stuff is not as consistent as it should be); but my question still remains, besides the inconsistency does it make any difference?

[lxsmnsyc]

@titoBouzout probably just to shave off a few bytes

[titoBouzout]

Yes, agree, what I wonder is if it changes behaviour in any noticeable way, think of CSS selectors and so on

[titoBouzout]

This PR fixes the reproduction the issue is reporting #385, but that's just for the literal case, haven't looked what will happen in the dynamic case, having these to match would be good

[axel-habermaier]

haven't looked what will happen in the dynamic case

As I mentioned in my original post, <input checked={Date.now() > 0} /> prints <input checked>, so this should be consistent with #385.

[edemaine]

what I wonder is if it changes behaviour in any noticeable way, think of CSS selectors and so on

I don't think so. https://www.w3.org/TR/2012/WD-html-markup-20120329/syntax.html#syntax-attr-empty says

empty attribute syntax is exactly equivalent to specifying the empty string as the value for the attribute

But certainly nicer to be consistent and shorter.