Add mechanism to disable rules inline within a given block.

The current implementation of <!-- template-lint disabled=true --> or <!-- template-lint bare-strings=false --> disables the rule for the entire “rest” of the template they are in. We should add a better control/configuration system so that it is possible to disable all or a single rule within a given block.

The principle behind this (i.e. how we think of it applying to the DOM tree) is that we’re providing two ways of configuring the linter in a template:

1. Add an instruction as an in element comment (<div {{! template-lint) that applies to it and (optionally) to its descendants.
2. Add an instruction as a child-less node ({{! template-lint) that applies to all of its later siblings nodes and (mandatorily) to their descendants.

<div>
  {{! template-lint disabled=true }}
  {{! Things are disabled here }}
</div>
{{! But not disabled here }}

{{#foo-bar as |baz|}}
  {{! template-lint invalid-interactive=false }}
  {{! invalid-interactive is disabled here }}
{{/foo-bar}}
{{! invalid-interactive is reset to its original / global configuration here }}

<div>
  <div {{! template-lint rule='invalid-interactive' disabled=true}}>
    {{! invalid-interactive *not* disabled }}
  </div>
</div>

<div>
  <div {{! template-lint rule='invalid-interactive' disabled=true recursive=true}}>
    {{! invalid-interactive *is* disabled }}
  </div>
</div>

Original Proposal

Off the top of my head, I would like to add something like:

{{#template-lint disabled=true}}
  {{! Things are disabled here }}
{{/template-lint}}

{{! But not disabled here }}

These {{template-lint component invocations would be completely removed at build time (just like the HTML comments are today). This would also allow us to slowly phase out the current usage of HTML comments, which is somewhat odd anyways.

Here is an early mockup of what this might look like: http://rwjblue.jsbin.com/vayamom/edit?html,js,output

[rwjblue]

OK, I went spelunking to see how hard it would be to fix things to be able to use Handlebars comments. Turns out I am dumb and it was simply not fully implemented in HTMLBars / Glimmer, but is not a hard restriction on the Handlebars parser side. I am working up a PR to Glimmer to enable the following for us (will still need a bunch of work in ember-template-lint after the upstream fixes land).

Current proposal:

<div>
  {{! template-lint disabled=true }}
  {{! Things are disabled here }}
</div>
{{! But not disabled here }}

{{#foo-bar as |baz|}}
  {{! template-lint invalid-interactive=false }}
  {{! invalid-interactive is disabled here }}
{{/foo-bar}}
{{! invalid-interactive is reset to its original / global configuration here }}

<div>
  <div {{! template-lint rule='invalid-interactive' disabled=true}}>
    {{! invalid-interactive *not* disabled }}
  </div>
</div>

<div>
  <div {{! template-lint rule='invalid-interactive' disabled=true recursive=true}}>
    {{! invalid-interactive *is* disabled }}
  </div>
</div>

This proposal has the following additional benefits:

• We can deprecate <!-- template-lint, and rely only on Handlebars comments (this has irked me for quite some time).
• We do not have to worry about changing semantics (i.e. changing the comments to be block scoped by default)

[rwjblue]

@bendemboski - Love it! Note: the element modifier approach will only work for actual DOM elements, not component invocations (mostly because I cannot even reason about what that would mean). I also think I would definitely still want the original proposed syntax also.

Current proposal:

{{#template-lint disabled=true}}
  {{! Things are disabled here }}
{{/template-lint}}

{{! But not disabled here }}

<div>
  <div {{template-lint rule='invalid-interactive' disabled=true}}>
    {{! invalid-interactive *not* disabled }}
  </div>
</div>

<div>
  <div {{template-lint rule='invalid-interactive' disabled=true recursive=true}}>
    {{! invalid-interactive *is* disabled }}
  </div>
</div>

Everyone on board with that?