-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
HTML should support self-closing tags in general #721
Comments
Here's a relevant thread from way back: https://lists.w3.org/Archives/Public/public-whatwg-archive/2010Dec/0308.html. Specifically, that link is to a comment from @Hixie saying that legacy code such as It could possibly be done with some kind of directive/opt-in. 🙊 |
That's a good point. Custom elements should have less of a legacy problem (or at least merit their own discussion in 2016), but there are cases like |
Fortunately for you, the spec already includes such an opt-in! If your server sends the header |
Yes...but that would (unless I'm missing something) require the whole document to be XML which is a steep prerequisite.
Case-insensitivity, tolerant parsing, simple doctype and other benefits are what web authors expect from modern HTML. Web components mean we're going to be spending more time using tags the spec never imagined that are semantically void but can't currently benefit from the same abbreviated syntax. |
I don't know if @Hixie looked specifically for the combination of code where the start tag contains a hyphen and a trailing slash. Perhaps that is unique enough that we can introduce it as a thing, for custom elements. |
I think it would be more consistent to require special sigils in the name to signify what kind of element it is, as per WICG/webcomponents#113. So for example if an element was named with a dash at the end ( But in general the point I'm trying to make it is that I think it makes more sense to use special sigils in the name to opt in to special parsing behavior, instead of trying to come up with suffixes that only work on custom elements. The end result is somewhat similar, but I think having the processing model be based on name-lookup ( |
This wouldn't work, because the element might have other attributes. |
Note that SVG/MathML in HTML already support We can't make it work in general because web compat, but I don't see anything particularly wrong with making it work for tags with dashes. Any new native element won't have dashes so this rule seems like it's reasonably consistent and easy to reason about (SVG/MathML/custom elements support self-closing, HTML elements not). |
Also self-closing is a lot more flexible compared to void. If you start using an element as void and later want to let it have content, with void you would have to change the element's name, and any JS/CSS/etc would also need to change, or be written to support both names from the start, just in case. With self-closing supported you can switch at will without problems. |
Another way of stating my position is that I think the model we have so far in HTML is void (not self-closing), and void-ness is a property of the element, not of how it's used ( |
Strict void-ness is nice for the parser since it knows whether to expect an end tag, but custom tags will be much more diverse than the current void subset and could have reason to be either/or. (XML leaves it to the domain and doesn't even distinguish between |
There's tons of custom elements on the web (we used to call them "invalid elements that happen to have hyphens in their names"). I would be shocked if changing their parsing model even slightly, let alone this much, was backwards compatible. But if we collect data on this we can find out. |
Going off of domenic's statement that voidness should be a property of an element, and Hixie's note that changing how custom elements are parsed could have unforseen negative results, why not extend the |
@Yay295 we do not want script execution to change the way a document is parsed. That would make it much harder for simple tools to extract data out of HTML. |
Reading through the custom elements spec draft, it sounds like the intent is for unresolved elements to have a basic level of support in the document whether their definition (whatever format that takes) is loaded yet or not. That seems like it would make configuring void-ness at that level challenging since the parser might start with default HTML syntax but later discover a rule that made the element void and have to shift the tree. A document (or template) level |
Re @Hixie I researched http://www.sunil-android.blogspot.in/ uses-permission
This then uses JS to reserialize the DOM and syntax highlight it. But it currently renders the "wrong" thing:
Supporting self-closed here would improve this page. http://www.uregina.ca/ below-leftnav
In a http://www.sebts.edu/ system-region
In a comment. http://www.bancadelladriatico.it/ content-type Page has changed? http://www.miamioh.edu/ system-region
In a comment. http://www.brandeis.edu/ system-region
In a nav, in a comment. http://www.about.com/ globe-environment
In a comment. http://www.bostonapartments.com/ id-publisher
In http://www.rayovallecano.es/ dynamic-element
In another element. http://www.menu.com.do/ cl-transformation
In another custom element. http://www.jmu.edu/ xhtml-block
Has content after, but adding an end tag makes the page render the same. http://www.yoinfluyo.com/ m-eta
Probably deliberate "comment out". In head. Changing to
In http://www.bikinibutt.com/ site-control Page changed? http://www.caript.it/ content-type
In a comment. http://www.fastcult.ru/ lj-embed
Has an image after it. Closing the tag doesn't change the page rendering. http://www.peteava.ro/ site-control
In a comment. http://www.fiu.edu/ system-region
In a comment. http://www.mailendo.com/ moo-modal Page changed? http://www.uwinnipeg.ca/ system-region
In a http://www.haarshop.nl/ angucomplete-alt
In a http://www.commoncurriculum.com/ font-face
Inline SVG. http://www.snc.edu/ caption-under
In a http://www.electronicbeats.net/ soundcloud-player
In a comment. http://www.cqsq.com/ pw-end
Near the end of the page. http://www.cordobacf.com/ dynamic-element
(Prettified here.) OK this one is interesting, because it nests http://www.rajasthantourism.gov.in/ defanged-meta Page changed? http://www.cpp.edu/ system-region
In a comment. http://www.rvusa.com/ angucomplete-alt
In a http://www.swidnik.pl/ l-ink
In conditional comments. http://www.globalsafelist.com/ COOKIE-INCLUDE
In another element. http://www.snapgame.io/ ng-include
At the end of the page. http://www.dominos.co.il/ bad-code Page changed? http://www.pointpark.edu/ cmp-navigation
In a comment. http://www.carisbo.it/ content-type Page changed? http://www.dinheirovivo.pt/ clickly-check
Near the end of the page. http://www.power2.ir/ m-eta
Probably deliberate "comment out".
In http://www.pokerstars.gr/ rg-account
In a http://www.bcgov.net/ system-region
In a http://www.readersdigest.ca/ uses-sdk
In Page changed? http://www.royalsundaram.in/ br-
Inside an attribute value... http://www.gazzettaufficiale.it/ put-attribute
Adding a close tag doesn't change the rendering. http://www.locutorkiko.com.br/ meta-data
In another element. http://www.macomb.edu/ system-region
In http://www.bancacrfirenze.it/ content-type Page changed? |
The |
@nlwillia you can mention it but we can't change |
@zcorpan I'd be very wary of analyses that only look at home pages (they tend to have better markup than deeply nested pages, because they're more important), but if you can get a browser to do it, let's try it and see how it goes. |
A voice from Angular: Angular has uses a special element called |
Closing per WICG/webcomponents#59 (comment) |
This seems like an improper close. The comment you link talks about seeing if we end up with "workarounds in libraries" to show whether or not this ends up being necessary, but you can't work around this issue in libraries. |
You could if you parse the HTML yourself. The problem is that implementers do not want to change the parser. The only option that seems somewhat palatable is having a flag at the start of the document to opt into a simplified tree builder that only has a couple of insertion modes rather than several dozen. |
AFAIK the XHTML parser already supports that, but I agree with others, specially As example, this kind of layout works without issues, yet I'd love to see this available on the Web: html`<span class="decoration" />` The obvious footgun that has been around forever is also the fact when a developer explicitly closes a tag, it would never expect this to contain adjacent nodes: <!-- you write this -->
<div class="lazy" />
<div>not lazy</div>
<!-- you obtain -->
<div class="lazy">
<div>not lazy</div>
</div> and whatever library will populate Please don't close this issue, thanks. |
Proposal: The current HTML standard allows the end tag to be omitted when an element is one of a specific list of void elements. The start tag of a void element may be written as
<name />
in which case the slash is effectively ignored. The void element list is useful since it helps a parser identify when not to expect an end tag, but conflating self-closing syntax with void (and foreign) elements is not. An HTML parser should recognize self-closing syntax on any element and interpret it as equivalent to<name></name>
.Motivation: The ability to use self-closing tags more broadly is not strictly necessary in HTML itself since, in general, elements written without content (ex:
<p></p>
) have no semantic purpose. However, custom elements are being introduced today by frameworks like Angular, Aurelia and others as well as web components that are semantically void, but which the base parser will have no knowledge of. This requires the element to be written as<name></name>
which is more verbose and ambiguous.<name />
in contrast is brief, expressive and assertive about the fact that the element is being used declaratively and has no content. Unless there is a mechanism to configure parsing by extending the void element list itself (which would be more consistent since it would allow just<name>
, but probably more challenging), then just expanding self-closed tags seems like the simplest way to create a practical foundation for custom elements (which are an important part of HTML's evolution) to have greater economy and expressiveness.Implications: Lexically, this would be a modest change, but handling by browsers that were not updated to track it would vary. It's not uncommon to see confusion from new custom element developers when they self-close a declarative custom element out of habit in a framework where the native HTML parser is used and adjacent tags or content are eaten as a result. It's likely that even with standardization it would be some time before native support was widespread enough to assume. In the interim, pre-processing could be applied to template content to expand self-closed custom tags. The argument can be made that the option of custom parsing obviates the need for the standard to change, but frameworks like to track the standard and are reluctant to introduce such measures independently despite the benefits.
Background: This is my own opinion as a developer. I'm not associated with a browser maker or major company or framework. I've researched this issue, but I haven't found where it was clearly ruled out or there was much hope of it being fixable downstream. It may be more appropriate as a web component discussion, but the general impression I get is that people are looking to the HTML standard first. I'm fine with HTML not being XML, but in this case, I think that the self-closing syntax is a worthwhile improvement for consideration.
The text was updated successfully, but these errors were encountered: