- From: David Alsh <notifications@github.com>
- Date: Thu, 15 May 2025 16:50:39 -0700
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/624/2885293349@github.com>
alshdavid left a comment (WICG/webcomponents#624) @abitrolly Arbitrary void elements `<foo>` are bad for parsers but self closing tags `<foo/>` are fine, ergonomic to consume and self documenting. For example; if I create a custom element that abstracts an icon library, the following tag describes an element that does not have children elements, is concise to use and actually improves parser performance (because it doesn't need to search for a closing tag). ```html <x-icon type="chevron-right" /> ``` However today the spec forces us to use a closing tag: ```html <x-icon type="chevron-right"></x-icon> ``` This also applies to other use cases like custom inputs, radio buttons, checkboxes, etc. It's not a deal breaker obviously, but it is certainly more ergonomic than the requirement of a closing tag. Void elements are a no-go because it complicates parsers and could potentially mask erroneous code. While the use case of custom elements is nice, should this apply to build-in elements too? `<div />` `<span />` and what does that imply for their semantics? But the ultimate downside of self closing elements are that they are not backwards compatible so is it worth the migration effort? 🤷 Personally I want to see support added (for custom elements at least) but the risk of breaking websites during the transition means it's not likely to be adopted -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/624#issuecomment-2885293349 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/624/2885293349@github.com>
Received on Thursday, 15 May 2025 23:50:43 UTC