Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom 'void' or self-closing elements (HTML parser changes) #624

Closed
pfrazee opened this Issue Jan 30, 2017 · 20 comments

Comments

Projects
None yet
8 participants
@pfrazee
Copy link

pfrazee commented Jan 30, 2017

This was discussed in #113

It would be very nice to be able to declare Custom Elements as void or self-closing. Given that element names are already a little lengthy (from the required dash) there are times where avoiding the name repetition would preferable.

Presently, all custom elements must be used as:

<my-element></my-element>

And I'd like to be able to do self-closing:

<my-element />

Or void:

<my-element>

Perhaps by a static getter in the class definition

customElements.define('my-element', class extends HTMLElement {
  static get isVoid() { return true }
})

Any chance we can reopen this discussion?

@rniwa

This comment has been minimized.

Copy link
Contributor

rniwa commented Jan 30, 2017

This would require a HTML parser change. We might be able to do this (self-closing) if we restricted to elements with - in its name.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Jan 31, 2017

Nobody wanted to change the HTML parser the last time around. What changed?

@rniwa

This comment has been minimized.

Copy link
Contributor

rniwa commented Jan 31, 2017

Well, I didn't want a parser change to be part of v1 since that would have required a lot more compatibility checks. Now that v1 is out the door, I think it might be worth checking whether there is an actual Web compatibility issue or not.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Jan 31, 2017

@rniwa whatwg/html#919 (comment) has pretty good rationale for why we nevertheless probably shouldn't do it.

@pfrazee

This comment has been minimized.

Copy link
Author

pfrazee commented Jan 31, 2017

That's a credible reason, so the question is, how much do we care about self-closing tags? Enough to fight that battle?

App devs can work around this using custom templating engines, but that's a shame when you consider that part of the appeal of Custom Elements is getting away from non-native solutions.

@Jamesernator

This comment has been minimized.

Copy link

Jamesernator commented Apr 4, 2017

I would definitely like to see self-closing tags, a good amount of tags I've found useful can be often described from their attributes e.g. <x-markdown src="./some-info.md"></x-markdown> which would be a lot nicer as just <x-markdown src="./some-info.md" />.

@rniwa

This comment has been minimized.

Copy link
Contributor

rniwa commented Apr 4, 2017

@annevk I don't agree with @hsivonen assertion that we should not make changes to the parser. There are many things that are security sensitive. In theory, the security of websites can rely on the absence of any Web feature and become vulnerable when any new feature is introduced. But we don't stop introducing new features just because of such a concern. I can be convinced if this turns out a be real security concern, but given the importance of the motivating use cases, I'm not at all convinced we can't make any changes here.

@Jamesernator

This comment has been minimized.

Copy link

Jamesernator commented Apr 5, 2017

@rniwa Yeah I don't think the argument is strong enough to suggest that we should never change the parser ever and stop adding features to html. By the html definition <x-markdown /> should be an error anyway even though browsers recover and wrap following content in it.

It's weird too because the html document even specifies that tags from other namespaces can be self-closing, it just seems weirdly inconsistent. Is there a particular reason every element can't be self-closed?

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Apr 5, 2017

@rniwa I still don't see how minor changes here and there to the HTML parser actually accomplishes what folks want, which is custom elements that can take the place of arbitrary HTML elements, such as <li> or <td>. And what it does do is make the HTML parser less reliable and a source of bugs and problems across the ecosystem.

@Jamesernator

This comment has been minimized.

Copy link

Jamesernator commented Apr 5, 2017

@annevk Just speaking for myself but I'm sure others would like it too but I'd certainly find self-closing tags an improvement and assuming only <x-foo /> form is allowed (initially at least) it shouldn't conflict with <p> like behaviours which I feel should be a separate issue given that it's far more complicated.

And from what I'm aware isn't it the case that a correct parser should consider this an error anyway <x-markdown /> (assuming this still applies https://www.w3.org/wiki/Validating_your_HTML#Different_browsers_interpret_invalid_HTML_differently) so correct parsers shouldn't break (just fail) if given <x-markdown />, the thing is the addition of virtually anything to HTML could potentially make the HTML parser a source of bugs, e.g. simply adding another void tag or auto-closing (like <p>) (and plenty of other things I'm sure) would mean existing parsers would be invalid . For those reasons I'm definitely not happy with the argument that we can't extend HTML because some parsers might break.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Apr 6, 2017

@Jamesernator HTML parsers do not fail and that document seems out-of-date at best. The HTML parser we care about is defined at https://html.spec.whatwg.org/multipage/syntax.html#parsing and any change would have to be a change to that algorithm.

@annevk annevk added the v2 label Sep 4, 2017

@annevk annevk changed the title Custom 'void' or self-closing elements Custom 'void' or self-closing elements (HTML parser changes) Feb 18, 2018

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Mar 5, 2018

There's no interest in changing the HTML parser for void elements. The bar for changes is too high and the ergonomic benefit is too low.

@annevk annevk closed this Mar 5, 2018

@abitrolly

This comment has been minimized.

Copy link

abitrolly commented Apr 30, 2018

Just to clarify - is there these two types of elements:

  1. void - <my-element>
  2. self-closing - <my-element/>

It seems logical that modifying parser to catch new void elements is not good, because nobody knows if custom element should be void or not just by looking at the tag. But what is the problem with self-closing tags?

abitrolly added a commit to abitrolly/metamask-status that referenced this issue Apr 30, 2018

Update demo.html
Custom elements can not be self-closing too
w3c/webcomponents#624
@annevk

This comment has been minimized.

Copy link
Member

annevk commented Apr 30, 2018

I should have been more clear, my statement applies to self-closing tags too.

@abitrolly

This comment has been minimized.

Copy link

abitrolly commented Apr 30, 2018

Then how high would be the bar for changes if we concentrate only on self-closing tags without touching void elements?

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Apr 30, 2018

It's still too high. There's basically only interest in security fixes and non-normative changes.

@abitrolly

This comment has been minimized.

Copy link

abitrolly commented Apr 30, 2018

So people are doomed to double their simple <custom-element></custom-element> names till the end of internet?

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Apr 30, 2018

As far as the text/html format goes that's where we're at.

@amkuipers

This comment has been minimized.

Copy link

amkuipers commented May 21, 2018

as a developer using custom elements I would really like self-closing custom elements. It makes no sense to me if I have a <custom-box color='RED' /> , that my browser even stops and ignores the remaining html code. I must specify a separate closing tag for the custom-box before it even works.

  • Developer friendly: allow self-closing custom elements for custom element users

Another motivation is; when someone is using the custom element and that element has no nested content or elements, that developer wants to cleanup its code by changing it to a self closing element. It just looks ugly.

Another motivation is; when the custom element needs a separate closing element, the developer might assume that the custom element accepts content; which it might not.

  • I would vote for the custom element IDE to issue a warning on ignored content for:

<custom-box color="RED">ignored text</custom-box>
<custom-box color="RED"><p>ignored child element with text</p></custom-box>

@ivands

This comment has been minimized.

Copy link

ivands commented Dec 10, 2018

Thumbs up for self-closing tags.
Let's move forward and make the web a better developer experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.