Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Error for unrecognized tags

See original GitHub issue

Currently, if you have a template with the following

<some-tag-that-does-not-exist/>

The following HTML will be output:

<some-tag-that-does-not-exist></some-tag-that-does-not-exist>

We should instead throw an Error if the tag is not a standard HTML tag or has not been defined as a Marko custom tag. This will help catch typos as well as users who might accidentally write concise style tags at the root when they meant text (or tried to write JS).

Issue Analytics

State:
Created 7 years ago
Comments:35 (32 by maintainers)

Top GitHub Comments

3reactions

gilbertcommented, Feb 9, 2017

For the record, I now believe this was the right choice. After upgrading to rc.13, marko immediately informed me about two invalid tags that I forgot to change during a rename! 😄

2reactions

mlrawlingscommented, Feb 3, 2017

Related to this, Patrick and I are looking at creating a “standard” of sort that could be adopted by web component libraries to make their custom tags visible to tooling.

Marko’s autocomplete in Atom was originally forked from autocomplete-html and it was extended to autocomplete not just HTML elements, but also Marko custom tags that were discovered through directory scanning and marko.json files.

We’re thinking that we could submit a PR back to the original package that would support discovering an html-elements.json in project, but also at the root of any packages that the project depends on. This process and the format of the json file would be similar to the Marko process and format, which has worked well for us.

This would allow a web component package to simply add this file (which could be generated) and autocomplete would be made available to the autocomplete-html package (which has over 200k downloads). There’s an immediate benefit to doing so, but future tools would also be able to make use of this information.

And of course so would Marko. If we could get the web community to adopt this, it would mean you might never (or rather, rarely) have to add definitions/exceptions for third-party custom element tags on your own.

That’s definitely a big “IF”, but between reaching out to other developers, possibly making some PRs to popular libraries and the fact that there’s benefit to the libraries and end users (it’s not purely driven by a need of Marko) it could very well work.