In modifying getContent, we neglected the fact that parseAttrs wraps arrays in HTML.Attrs. Now we wrap arrays outside of parseAttrs near the code that modifies the attributes array for textarea contents.
Needs tests
Remove the concept of a "Special" as a generalization of template tags in HTML parsing and the HTMLjs tree. Just call something that's parsed by hooking the HTML parser a TemplateTag. Don't wrap the return value of getSpecialTag (now getTemplateTag), just require that it be an instanceof HTMLTools.TemplateTag.
Spacebars.TemplateTag is now a subclass of HTMLTools.TemplateTag. Both support `.toJS()`. The same object returned by getTemplateTag is now inserted into the HTMLjs -- that is, the Spacebars compiler creates an HTMLTools.TemplateTag instead of it being created as a wrapper inside HTMLTools. All usages of the words "special" or "special tag" are replaced with "template tag."
Some failing tests, which are hopefully mostly just tests of the modified code that need to be ported.
The main work was replacing the use of pseudo-attributes $special and $dynamic with the new HTML.Attrs(...) / array representation. Some functions were also rewritten to use Visitors (`toJS`, old `toHTML`/`toText`/`evaluateAttributes`, `replaceSpecials` in the compiler, but not `optimize` yet or `materialize`).
Create the "blaze-tools" package to hold toJS and other functions that are useful for template parsers/compilers that need to read or generate JS.
We now no longer check whether we're at a closing
HTML tag by peeking for "</" since that would fail
if there were a {{! }} comment directly before it.
Instead, we tokenize and then rewind. Presumably
this does have an effect on compilation time but it's
probably fine. An alternative would have been to
explicitly parse {{! }} comments rather than implicitly
skipping them before generally parsing tokens.
- Start shrinking html.js down to the 150-line file it can be
- Move "proper case" logic to the template compiler; the tagName of an HTMLjs tag is now in proper case. This is both for better performance and reduced size and complexity of runtime code (i.e. blaze.js).
- Start moving html-tools to the HTMLTools namespace
So, in HTML, the following are equivalent, and both mean that a checkbox is checked, because the `checked` attribute is present:
- `<input type="checkbox" checked>`
- `<input type="checkbox" checked="">`
We can't mess with that. On the other hand, in Spacebars before this commit, the following would *also* result in the checkbox being checked, regardless of whether `foo` evaluates to null, undefined, false, or the empty string:
- `<input type="checkbox" checked={{foo}}>`
- `<input type="checkbox" checked="{{foo}}">`
With this commit, the checkbox will NOT be checked if `foo` evaluates to null, undefined, or false.
To achieve this:
- In HTMLjs, an attribute is considered absent if its value is "nully" after being fully evaluated (i.e. after expanding functions and components via HTML.evaluateDynamicAttributes / HTML.evaluate). A nully value is one consisting of null, undefined, an empty array, or an array of those things. `false` is not nully and renders as "false". An empty string is not nully, and will "prop open" an attribute that would otherwise collapse into absence.
- Spacebars.mustache converts null, undefined, and false to null. So if you use {{foo}} anywhere in a template and foo evaluates to "false", that gets to converted to a null in HTMLjs (which is ignored). (true is rendered as "true".)
- When parsing HTML, an attribute that consists of *no tokens* becomes an empty string in the HTMLjs, which props open the attribute (unlike null or an empty array). (Since comment tokens are stripped during tokenization, if there are only comments in an attribute value that counts as no tokens.)
