XML brought in "empty elements" by adopting SGML's "null end-tag" (NET), part of the SHORTTAG minimization (though it changes the syntax slightly to make it work).
In SGML's reference concrete syntax, the Null End-Tag delimiter is `/`, and lets one omit the end tag.
<p>This is <em/very interesting/.</p>
Here the EM surrounds "very interesting." In XML the "Null End-Tag Start" becomes "/" and the "Null End-Tag End" is ">".
So in XML a `<br />` is syntax sugar over `<br></br>` and identical to it (an element with _no_ child nodes), but in HTML `<br>` is an element which _cannot contain child nodes_ and the `/` was never part of it, required, or better.
As called out in another comment, the trailing `/` on HTML void elements is dangerous because it can lead to attribute value corruption when following an unquoted attribute value. This can happen not only when the HTML is written, but when processed by naive tools which slice and concatenate HTML. It's not _invalid_ HTML, but it's practically a benign syntax error.
These two things have nothing to do with each other though:
- HTML doesn't have XML-style empty elements such as in "<div/>" and simply ignores the slash, treating the construct as start-element tag
- HTML is "hardcoded" in that the vocabulary understood by the browser is determined out of band, whether for empty ("void") elements or not. An SGML DTD (like the W3C HTML 4.01 DTD or newer DTDs for HTML 5+, which would be the means to inform a parser about the parsing rules for a markup language dynamically), actually contains declarations for the meta, img, and other elements as having EMPTY content, along with tag inference and attribute shortform rules also necessary for parsing.
It's mentioned in the GitHub readme, SuperHTML only supports HTML5 regardless of what you put in the doctype.
I will probably keep tracking the WHATWG living spec and never implement any other spec (old HTML versions, XHTML), so if you have a keen interest in anything other than contemporary HTML, SuperHTML might not be the right tool for the job.
That said, I'll add a warning if you put something else in the doctype so that users can know what to expect.
I got this error first with HTML doctype, so it is a problem in my code which uses self-closing tags with HTML doctype. Instead of very noninformative "html_elements_cant_self_close" message it should explain that HTML spec does not have "self-closing tags", and this code uses deprecated feature from previous (XHTML) specs.
You're getting a very clear error: your sample is not valid HTML, because, as the error informs you, HTML elements can't self close. Why would it reference some other document type for which this may or may not be valid syntax? Should it also tell you that these are not valid JSON objects or LISP forms?
Now, separately from that, it might be nice if it told you that it doesn't support DOCTYPE == XHTML and will treat the document as HTML anyway, but that should only appear as an error/warning on the DOCTYPE line, it shouldn't confusingly mention XHTML wherever you might have meant some XHTML-ism that is invalid HTML.
Also, XHTML is not "an older version of HTML", it is a completely different standard that is (or was) sometimes used instead of HTML.
"html_elements_cant_self_close" is not a very clear error.
Yes, now it is clear what does it mean, and it would be great if other users should not start a new HN-discussion to receive clear explanations when it can be explained directly on "html_elements_cant_self_close" tooltip. We can polish text, decide to mention XHTML or not, but the error message should be more informative.
> On void elements, it does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind. For such void elements, it should be used only with caution — especially since, if directly preceded by an unquoted attribute value, it becomes part of the attribute value rather than being discarded by the parser.
What is "latest build"? V does not release any stable build and you can get "large error" on any platform right now when trying random "latest build" without any effort to investigate the issue.
gitweb requires server setup, while Mercurial web ui can quickly start locally without any configuration and that was the one of mercurial selling point until github and other services arrives.
I think the way you're using hg's web UI is slightly different to the uses I think of for sites like GitHub, BitBucket or SourceHut.
A web UI is fine for being able to see the different commits, and files at different points in time.
But people also make use of GitHub as a hosted repository for sharing code with others, as an issue tracker, and for doing code review etc. -- for sharing things outside a local network, there's the understanding that either you're paying someone else to host it, or you're making effort to host it yourself, so "requires setup" isn't much of an issue.
"sourcehut competes with bitbucket" puts more emphasis on the latter than the former.
Can you make "sr.ht git services" the blue title of the repo "card" and "~sircmpwn/git.sr.ht" - the subtitle (with dimmed color)? This simple change will improve UI usability in 10x times.
I think the proper UI fix would be to split the username (sircmpwn) from the repo name (git.sr.ht) and make them two separate links divided by a non-link " / ".
This is what github does and I feel like it's a standard people expect, similar to having the logo of a page on the top left.
The former is a human-readable text which allow eye to easy understand and latter is a technical info which is not required to have space on the screen and makes UI "hard to use".
I wouldn't consider the repository name any more technical in nature than the name of a CD or film. I think it makes sense to have the title be more prominent than the description of what it does.
<head> <meta charset="utf-8" /> </head>
</html> Why it warns html_elements_cant_self_close on meta tag?