From 674921f283ecc29123fe0b786343c96593752b13 Mon Sep 17 00:00:00 2001
From: Miguel Camba <miguel.camba@gmail.com>
Date: Sun, 14 Oct 2018 13:52:32 +0200
Subject: [PATCH 1/4] Dynamic tags in glimmer templates

---
 text/0000-dynamic-tag-names.md | 111 +++++++++++++++++++++++++++++++++
 1 file changed, 111 insertions(+)
 create mode 100644 text/0000-dynamic-tag-names.md

diff --git a/text/0000-dynamic-tag-names.md b/text/0000-dynamic-tag-names.md
new file mode 100644
index 0000000000..bb3e587846
--- /dev/null
+++ b/text/0000-dynamic-tag-names.md
@@ -0,0 +1,111 @@
+- Start Date: 2018-10-14
+- RFC PR: (leave this empty)
+- Ember Issue: (leave this empty)
+
+# Dynamic tag names in glimmer templates.
+
+## Summary
+
+With the transition from inner-html semantics to outer-html semantics in components, we lost one feature: Being
+able dynamically define the tag name of components.
+
+I think it was an useful feature and we should find a way to bring it back.
+
+## Motivation
+
+Although not something we use every day, there is a need for some components to have a dynamic tag name.
+
+This is most often used for certain low-level _presentational_ components.
+
+Take for instance a component named `<Panel>` that is used to encapsulate some presentation concerns.
+The template of that component could be like this:
+
+```hbs
+<div class="pt-10 pb-10 ps-20 box-shadow" ...attributes>
+  {{yield}}
+</div>
+```
+
+For accessibility and semantic reasons, sometimes a `<div>` may not be the best kind of tag.
+We might want the panel to be a `<section>` element, or an `<aside>` when it's content is somewhat unrelated
+with the rest of the page. Or maybe a `<legend>` if it's and the end of a form.
+
+## Detailed design
+
+The syntax I propose is to allow to interpolate just after the `<` and `</` markers in templates.
+
+For instance:
+
+```hbs
+<{{@tagName}} class="pt-10 pb-10 ps-20 box-shadow" ...attributes>
+  {{yield}}
+</{{@tagName}}>
+```
+
+The glimmer parser needs to be able to distinguish this from any other interpolation in the so called
+_element space_, like the future [Element Modifiers](https://github.com/emberjs/rfcs/pull/353).
+
+This syntax presents two edge cases that we need clarification:
+
+1 - What happens when the value in the interpolated in the opening and closing tags are different?
+
+```hbs
+<{{@tagName}} class="pt-10 pb-10 ps-20 box-shadow" ...attributes>
+  {{yield}}
+</{{@otherTagName}}>
+```
+
+This is clearly illegal and must throw an exception in development or production alike.
+
+2 - What if the interpolated value is not a string? (`null`, `undefined` or a number/object).
+
+Any value other than a String must throw an exception in development or production alike.
+
+About `null`/`undefined` we can take two approaches.
+We can deem them an error and throw an exception or we can take a similar approach than React did with `<>...</>`.
+For those not familiar with `<></>` in React, that is used to generate DOM fragments. That is, the absence of a root
+element.
+I lean towards considering that a runtime error, but I could be convinced otherwise.
+
+
+## How we teach this
+
+This must be documented with examples in the guides, making very clear that the values being interpolated
+have to be strings.
+
+## Drawbacks
+
+Admittedly this syntax is somewhat strange, and the fact that the exact same value has to be repeated in
+both the opening and closing tags opens the door to making mistakes that should have good error messages.
+
+## Alternatives
+
+We can propose other alternative syntax. For instance, we could have a special built-in component for this:
+
+```hbs
+<DynamicElement @tagName={{@tagName}} class="some-class" ...attributes>
+</DynamicElement>
+```
+
+## Unresolved questions
+
+#### Should we allow helpers inside those interpolations?
+
+For instance:
+```hbs
+<{{or @tagName "div"}}>
+
+</{{or @tagName "div"}}>
+```
+
+I think that this repetition makes templates harder to read, so I advocate that only simple bindings
+can be passed in. If the user wants to use something more complex than a binding, they could use the `let`/`with` helpers
+for that.
+
+```hbs
+{{#with (or @tagName "div") as |tagName|}}
+  <{{tagName}} class="foo">
+    ...
+  </{{tagName}}>
+{{/with}}
+```

From aff3d25316471ea4498cde22fdf1b601cd121390 Mon Sep 17 00:00:00 2001
From: Miguel Camba <miguel.camba@gmail.com>
Date: Mon, 15 Oct 2018 00:58:34 +0200
Subject: [PATCH 2/4] Refine proposal

---
 text/0000-dynamic-tag-names.md | 102 ++++++++++++++++++---------------
 1 file changed, 55 insertions(+), 47 deletions(-)

diff --git a/text/0000-dynamic-tag-names.md b/text/0000-dynamic-tag-names.md
index bb3e587846..8cb4e148b1 100644
--- a/text/0000-dynamic-tag-names.md
+++ b/text/0000-dynamic-tag-names.md
@@ -30,82 +30,90 @@ For accessibility and semantic reasons, sometimes a `<div>` may not be the best
 We might want the panel to be a `<section>` element, or an `<aside>` when it's content is somewhat unrelated
 with the rest of the page. Or maybe a `<legend>` if it's and the end of a form.
 
-## Detailed design
-
-The syntax I propose is to allow to interpolate just after the `<` and `</` markers in templates.
-
-For instance:
+With the `element` helper proposed in this RFC, this can be accomplished with something like this:
 
 ```hbs
-<{{@tagName}} class="pt-10 pb-10 ps-20 box-shadow" ...attributes>
-  {{yield}}
-</{{@tagName}}>
+{{#let (element @tagName) as |Tag|}}
+  <Tag class="pt-10 pb-10 ps-20 box-shadow" ...attributes>
+    {{yield}}
+  </Tag>
+{{/let}}
 ```
 
-The glimmer parser needs to be able to distinguish this from any other interpolation in the so called
-_element space_, like the future [Element Modifiers](https://github.com/emberjs/rfcs/pull/353).
+## Detailed design
 
-This syntax presents two edge cases that we need clarification:
+We propose to add a new `element` helper that takes a tag name and generates a contextual component that, when invoked, renders the selected element.
 
-1 - What happens when the value in the interpolated in the opening and closing tags are different?
+Example:
 
 ```hbs
-<{{@tagName}} class="pt-10 pb-10 ps-20 box-shadow" ...attributes>
-  {{yield}}
-</{{@otherTagName}}>
+{{#let (element @htmlTag) as |Tag|}}
+  <Tag>...</Tag>
+{{/let}}
 ```
 
-This is clearly illegal and must throw an exception in development or production alike.
+Unlike ids, classes or other attributes, the tag name of DOM element cannot be changed in runtime.
 
-2 - What if the interpolated value is not a string? (`null`, `undefined` or a number/object).
+To help the user understand that changing the tag of an element in runtime is an expensive operation,
+the syntax is intentionally chosen to express that changes in the tag name will turn down the given block
+and recreate it again.
 
-Any value other than a String must throw an exception in development or production alike.
+Having dynamic tag names can also open the door to possible XSS vulnerabilities if developers allow user-input
+to become tag names (e.g. `xlink:`) . To prevent that, this helper will throw an error for any tag name containing anyting
+but lowercase letters and dashes.
 
-About `null`/`undefined` we can take two approaches.
-We can deem them an error and throw an exception or we can take a similar approach than React did with `<>...</>`.
-For those not familiar with `<></>` in React, that is used to generate DOM fragments. That is, the absence of a root
-element.
-I lean towards considering that a runtime error, but I could be convinced otherwise.
+A working proof of concept of this approach has been created in https://github.com/tildeio/ember-element-helper
 
+Shall this RFC me accepted, that helper would be ported to Ember.js itself, perhaps making it more efficient
+on the process.
 
 ## How we teach this
 
-This must be documented with examples in the guides, making very clear that the values being interpolated
-have to be strings.
+_It's vitally important that developers have awareness the negative impact that misuse of dynamic tags can have on the accessibility of an Ember application._
 
-## Drawbacks
+While dynamic tags enable a great deal of flexibility in components, it's essential to recognize that these can also negatively impact accessibility. Developers should be keenly aware of the appropriate role that should be applied per HTML element (as specified in the [WAI-ARIA specification](https://www.w3.org/WAI/PF/aria/roles)), and ensure that the role is also updated, if necessary, as the tag name is changed. In some cases, the use of native, semantic HTML elements may eliminate the need to apply a role at all, so developers should consult the WAI-ARIA specification until they are certain of the correct use for their specific use cases.
 
-Admittedly this syntax is somewhat strange, and the fact that the exact same value has to be repeated in
-both the opening and closing tags opens the door to making mistakes that should have good error messages.
+This new helpers will be added to the list of [built-in helpers](https://emberjs.com/api/ember/release/classes/Ember.Templates.helpers) along
+with its cousins `component`, `array`, `each`, etc...
 
-## Alternatives
+Some meaningful example for the docs could look like this (extracted from a real use case):
 
-We can propose other alternative syntax. For instance, we could have a special built-in component for this:
+```hbs
+{{!-- sidebar.hbs, a template-only component --}}
+{{#let (element (or @htmlTag "aside")) as |Tag|}}
+  <Tag ...>...</Tag>
+{{/let}}
+```
 
 ```hbs
-<DynamicElement @tagName={{@tagName}} class="some-class" ...attributes>
-</DynamicElement>
+<Sidebar @htmlTag="nav">...</Sidebar>
 ```
 
-## Unresolved questions
+Since this feature is not very commonly used it is debatable if it should be mentioned in the more beginner-friendly guides,
+but if deemed appropriate the _Components > Customizing a Component's Element_ section is a perfect
+fit.
 
-#### Should we allow helpers inside those interpolations?
+## Drawbacks
 
-For instance:
-```hbs
-<{{or @tagName "div"}}>
+Admittedly this syntax is somewhat convoluted, as it involves using the `let` helper, the new `element`
+helper that yields a contextual component that is then invoked using angle-bracket syntax.
 
-</{{or @tagName "div"}}>
-```
+This syntax is intentional to make clear that any change in the tag name would yield a new contextual component,
+effectively tearing down the previous one before rendering the new one, but I can see perceiving this
+as unnecessarily complex.
+
+## Alternatives
 
-I think that this repetition makes templates harder to read, so I advocate that only simple bindings
-can be passed in. If the user wants to use something more complex than a binding, they could use the `let`/`with` helpers
-for that.
+We can decide not to do anything and leave this problem to be solved in user space, as it can be
+solved using only public APIs.
+
+We can also propose other alternative syntaxes. For instance, we could have a special built-in component for this:
 
 ```hbs
-{{#with (or @tagName "div") as |tagName|}}
-  <{{tagName}} class="foo">
-    ...
-  </{{tagName}}>
-{{/with}}
+<DynamicElement @tagName={{@tagName}} class="some-class" ...attributes>
+</DynamicElement>
 ```
+
+## Unresolved questions
+
+---
\ No newline at end of file

From c2959e656f4c50192ac59faf20f41b1f15f675dc Mon Sep 17 00:00:00 2001
From: Godfrey Chan <godfreykfc@gmail.com>
Date: Fri, 5 Apr 2019 12:04:07 -0700
Subject: [PATCH 3/4] update teaching section

---
 text/0000-dynamic-tag-names.md | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/text/0000-dynamic-tag-names.md b/text/0000-dynamic-tag-names.md
index 8cb4e148b1..82b8f7fc43 100644
--- a/text/0000-dynamic-tag-names.md
+++ b/text/0000-dynamic-tag-names.md
@@ -89,9 +89,8 @@ Some meaningful example for the docs could look like this (extracted from a real
 <Sidebar @htmlTag="nav">...</Sidebar>
 ```
 
-Since this feature is not very commonly used it is debatable if it should be mentioned in the more beginner-friendly guides,
-but if deemed appropriate the _Components > Customizing a Component's Element_ section is a perfect
-fit.
+Since this feature is not very commonly used, it should not be mentioned in the more beginner-friendly portion
+of the guides. However, the _Components > Customizing a Component's Element_ section is a perfect fit for this.
 
 ## Drawbacks
 
@@ -116,4 +115,4 @@ We can also propose other alternative syntaxes. For instance, we could have a sp
 
 ## Unresolved questions
 
----
\ No newline at end of file
+---

From 0b3329135aac4d5f3a6e71d2e516323e189e1a44 Mon Sep 17 00:00:00 2001
From: Robert Jackson <rjackson@linkedin.com>
Date: Fri, 12 Apr 2019 14:38:55 -0400
Subject: [PATCH 4/4] Rename to the final API.

---
 text/{0000-dynamic-tag-names.md => 0389-dynamic-tag-names.md} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename text/{0000-dynamic-tag-names.md => 0389-dynamic-tag-names.md} (100%)

diff --git a/text/0000-dynamic-tag-names.md b/text/0389-dynamic-tag-names.md
similarity index 100%
rename from text/0000-dynamic-tag-names.md
rename to text/0389-dynamic-tag-names.md