Support nonstandard void elements

[ngdangtu-vn]

I have a case where I use a nonstandard tag name holder and replace it with real element to build out static file. Does deno-dom have plan for this?

<!-- before -->
<h1><translate id='heading' /></h1>
<p>content here</p>

<!-- expect after -->
<h1>Translated Heading</h1>
<p>content here</p>

The sample code about won't work because deno-dom refuses to see it as a void-element. Is it possible to support this feature in the future?

[b-fuze]

I don't see why you can't do that with Deno DOM. I also don't see why that specifically requires a non-standard void element either. I do not plan to treat non-standard elements specially either--though I do plan to implement the customElements API sometime in the future

[0kku]

The standard HTML parser has a list of void elements, and anything else gets closed automatically according to parsing rules (which might be in an unexpected way). Trailing slashes in tags are ignored, so you can't use self-closing tags like you could in XML and XHTML, like you attempted. Deno-dom parses HTML in a standard manner, and much like browsers, is never going to support this use case unless the spec gets amended accordingly.

It's also worth noting that it's not correct HTML to have non-standard elements whose name doesn't contain a dash. These are reserved for future standard HTML elements. To make sure your code doesn't break in the future, it would behoove you to stick to standard names and custom elements whose name contains a dash, such as <translate-element>.

Currently, deno-dom does not support parsing XML, but in the future if/when that is implemented, you'll be able to have arbitrary elements and any element can be self-closing. Unfortunately, WHATWG have indicated disinterest in supporting custom void elements in the HTML parser, so it's unlikely to ever be possible outside XHTML. In the meantime, you could manually close elements like this: <translate-element></translate-element>.

[ngdangtu-vn]

@0kku that's what I meant. However, these nonstandart element would never meet the production stage as it will be replace with a probable one. Yes, it is just a placeholder. I don't worry about conflict in future as well because I already have an option to change the placeholder element name. Therefore I don't need heavy thing like custom element name convension.

@b-fuze the current parser only support nonstandard element with complete elements. I saw in the code there is a strict list of void element. Like I mentioned above, I don't need such complicated thing like custom elements because the placeholder element could just be a <t/>. But if the project plan is stick as close as possible to the spec then I guess I'm out of luck. Maybe an option to allow certain nonstandard to be seen as void elements?

[ngdangtu-vn]

For a second thought, if the development team of deno-dom doesn't mind to do a bit different from browser parser, it would be great to treat evey tags with explicit self-close syntax <div /> as an empty (content) element <div></div> could be great.

<!-- src -->
<div id='a' />
<div id='b'>content text or another element
<a id='ln'>a link

<!-- parse understands as -->
<div id='a'></div>
<div id='b'>
  content text or another element
  <a id='ln'>a link</a>
</div>

And <div> can be any standard or nonstandard tags.

If we can do that, deno-dom would be much more powerful than just a simple DOM parser :D

Btw, for anyone who wish to use deno-dom to fill content to placeholder el, my temporary solution is use an empty element for now.