Change/define HTML element type at runtime
- Dominant language
- TypeScript
- Stars
- 113
- Forks
- 101
- PR merge metrics
- No merged PRs in 30d
Description
**I'm submitting a feature request**
* **Library Version:**
1.0.8
**Please tell us about your environment:**
* **Operating System:**
Windows 10
* **Node Version:**
6.9.4
* **NPM Version:**
4.1.1
* **Browser:**
Chrome 56 but the feature is browser independent
* **Language:**
TypeScript 2.1.5
*This is a follow up to [this stackoverflow question](http://stackoverflow.com/questions/42557158/change-element-type-at-runtime/42573678).*
**Current behavior:**
Best shown in an example. Here's a component which is always styled like a button but can also be a link in order to allow `Save link as`, `Open in new tab` etc and keep the markup semantically correct and accessible (see video [Why do semantics matter](https://www.youtube.com/watch?v=g2tzEil5TL0&list=PLNYkxOF6rcICWx0C9LVWWVqvHlYJyqw7g&index=7) by Rob Dodson)
```html
${contentText}
```
Since both, the `button` and the `a` element consist of the exact same content, this code is not DRY.
Possible solutions (I'm aware of) are currently the following:
* Move the content into its own template file and embed it using `compose` (see [this stackoverflow answer](http://stackoverflow.com/a/42560892/1273551) for details)
* **(-)** The content in this example is very minimal and can't "live on it's own" without the surrounding button etc. Therefore splitting the code into multiple files makes it IMHO harder to maintain.
* **(-)** Possible performance implications (even though I believe that those are 100% negligible in my use case). See [comments](http://stackoverflow.com/a/42560892/1273551).
* **(+)** Definitely a good solution for more complex scenarios
* Only use one tag (`button` or `a`) and use the [link](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_link_role) or [button](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role) role attributes to "fake" the semantics (see [this stackoverflow answer](http://stackoverflow.com/a/42573678/1273551))
* Even though I can't substantially argue against this, I'd still prefer to explicitly use the semantically correct tag whenever possible. I guess I'd use the `role` in situations where it's technically not possible to use the correct tag (e.g. custom `comboboxes` composed of `divs` or anything the like etc.).
**Expected/desired behavior:**
I'd really appreciate a simple way to change/define the actual type of an HTML element inside my component template at run time. One solution I could think of is something similar to Aurelias `as-element` which defines the actual type of the given element:
```html
${contentText}
```
DRY markup, semantically correct & no need to split it into multiple files to keep it as simple as possible ;)
Contributor guide
Research direction
Start by reviewing the requested runtime element-type behavior and the linked Stack Overflow discussion, then trace the templating engine's element creation path. Done means a component can keep one template while selecting the semantically correct HTML element at runtime, without duplicating its content.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- accessibility, frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100