7 ms·
Self-closing tags are an inconsequential issue. Of actual practical consequence are optional html5 tags [0]. They allow you to write html by hand as easily as
by enriquto 3y ago
Self-closing tags are an inconsequential issue.
Of actual practical consequence are optional html5 tags [0]. They allow you to write html by hand as easily as if you wrote markdown. Some graybeards even say that optional html5 tags make markdown entirely unnecessary.
Thus, lists don't need closing item tags:
This is correct html:
<ul>
<li> first
<li> second
<li> third
</ul>
Tables become uncluttered:
Raw html tables
<table>
<tr>
<td> are
<td> easier
<td> than
<tr>
<td> any
<td> markdown
<td> flavor
</table>
And you can even write the entire document in that style:
<!doctype html>
<title>Hello</title>
<p>This is a complete conforming html document.
No need for stupid html, header, body elements. They are optional!
[0] https://html.spec.whatwg.org/multipage/syntax.html#optional-tags https://html.spec.whatwg.org/multipage/syntax.html#optional-...
- taeric 3y agoRaw tables are "easier than any markdown" only if you don't mind it looking completely different. My favorite simple tables look like: | are | easier | than | | any | markdown | flavor | Granted, I don't know of any that allow colspan/rowspan well. And even fewer that support newlines in a cell. Styling can also be annoying. But simple tables are surprisingly annoying in most any of these options. (I should say that I fully agree with you, btw.)
- layer8 3y agoHTML tables are easier in the sense that if the length of the cell contents changes, or you add or remove lines within a single cell, that’s easy in HTML but inconvenient in Markdown (or requires special editor support).
- taeric 3y agoFair, "easier to write." They lose heavily on the "easy to read." (And folks that recognize my table as the org-mode table know that resizing the pipes is automatic for you, such that that shortcoming is addressed. :D )
- layer8 3y agoMarkdown was originally only intended as an authoring format, not a viewing format (it was just intended as an easier way to author HTML), and it is still used a lot in that manner (e.g. GitHub readmes).
- taeric 3y agoIsh. Per https://en.wikipedia.org/wiki/Markdown https://en.wikipedia.org/wiki/Markdown, the goal was "to write using an easy-to-read and easy-to-write plain text format, optionally convert it to structurally valid XHTML (or HTML)."
- jraph 3y agoA while ago, I designed a syntax supporting colspan (the last pipe of the line being optional): || are easier | than | | any | markdown | flavor | The number of consecutive pipes would increase the colspan value. I think I also had support for rowspan but I don't remember how. The XWiki syntax [1] also supports it by letting you use HTML attributes. |=Title 1|=(% style="background-color:yellow" %)Title 2 |(% colspan=2 %) Word 1 Word 2 Arguably more clunky and less intuitive, but more powerful I guess. (disclaimer: I work for XWiki) [1] https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/XWikiSyntax/#HTables https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide...
- hinkley 3y agoTrac’s wiki format has tables that work like that, and I don’t think it’s the first time I’ve seen colspan in wiki markup.
- abathur 3y agoI feel like I remember restructured text's visual table format supporting rowspan/colspan cells. (but I've also read the docs for nearly every minimal markup format I can find, so I might be misremembering... :)
- jraph 3y agoYeah, I was not at ease with this kind of stuff but I more and more like it. I'm hesitating between using a fully XML compliant code to be able to automatically spot stupid mistakes thanks to the parser, or this. If I'm not validating the XML I don't see much point in writing these extra tags. It's just less data to transfer. Compression is a thing but still. I do see one point: the version with the extra tags is closer to the actual representation of the document in the browser. You have to explain to newcomers that a full DOM with html, head and body elements will be rendered even if they are not present in the source code, with consequences for CSS and JavaScript to style and manipulate the document. The speech is just easier when the source matches the DOM. For the missing tag endings, it requires quite deeper knowledge about parsing HTML to read a document. It's clear that it makes taking notes faster, but the code is perhaps less clear to someone who has not read it. Still a bit hesitant on this. Nitpick: you might need <meta charset=utf8> before the title.
- afiori 3y agoA good minimizer for the html could remove the optional tags
- jraph 3y agoYep, that would be a solution for any project which has a build pipeline (anyway). For the better or the worse, when I deal with HTML directly, I usually just copy the HTML pages as they are on the server and have no mandatory Javascript, if at all. It's easier, and it's also "free backup on production".
- nicbou 3y agoAre there specific ones you recommend? Currently I just use CloudFlare's, but I'd love to squeeze a few extra kb out of my static pages.
- marcosdumay 3y agoI do think a maximizer that fills the optional tags in would be more useful. (Yeah, that's called a pretty printer, but the symmetry is nice.)
- pseudostem 3y agoMy first reaction to your comment was that it was probably missing a "/s" at the end. Rationale - I last did HTML when Netscape Navigator/ Communicator was still around. IIRC, usual discussion among us college students was how MS IE encouraged bad programming practices by ignoring (many?) unclosed tags, whereas Netscape wasn't as forgiving. I've not seen much HTML since then (I definitely plan to, now). Your comment brought back some fond memories. Thank you! And mind blown.
- entrox 3y agoIt's funny how close your example are to S-expressions, just replace the pointy brackets with round parenthesis and move the closing one to the end: (table (tr (td one) (td two) (td three)) (tr (td another table) (td with more stuff)))
- Zambyte 3y agoPlus by moving the closing bracket to the end, it resolves any ambiguity in nesting.
- TylerE 3y agoIt also tosses the baby out, as you're in that horrible area of distinction-without-difference.
- smcl 3y agoI've seen quite a few HTML templating engines that look just like this (in C#, TS and Python)
- em-bee 3y agoi love s-expressions, but they have closing tags, so to me they are precisely not what the parent example shows. i prefer writing html with closing tags because then i can use any xml parser and my editor can jump from opening to closing tag and back.
- taeric 3y agoWell, sorta. XML style syntax already has open and closing marks for the tags. They just additionally have marks for the end of non-attribute children. s-expressions not having that is still a win.
- em-bee 3y agoyes, s-expressions are a win (that's why i love them) but i don't see the xml structure that way. for me the tags themselves are very elaborate opening and closing markers. that's simply how i perceive it. if a closing tag is missing when there should be one, the structure looks broken to me. the example s-expression matches that structure and i perceive it as the same because the first element in any list has a special meaning (in lisp itself it is the function name, while the rest are arguments) to replicate the html5 structure in the top comment without closing tags as s-expressions i would come up with something different: (table (tr) (td) one (td) two (td) three (tr) (td) another table (td) with more stuff)
- Tade0 3y agoI learned the basics of HTML by reverse-engineering some documents and for a while I thought that this is how you write HTML. The language is very tolerant to untidy syntax, but most people forgot about that after we went through XHTML, which is anything but.
- golergka 3y agoThis also means that I won't be able to jump from the beginning to end and back with % motion in vim.
- pbhjpbhj 3y agoDon't tables become ambiguous without closing? >Tables become uncluttered: If I add a tr, does it nest "than" in the first row or does it move to the second row? Surely it can't nest because each tr effectively has a /tr before it. >Raw html tables <table> <tr> <td> are <td> easier <tr><td>but ambiguous? <td> than <tr> <td> any <td> markdown <td> flavor </table> I notice you closed the title, presumably because otherwise it's ambiguous as to whether the paragraph is in the title. It's so easy to make well-formed documents by closing tags intentionally rather than pushing the closing to be inferred by context by different rendering engines I can't see why you would want sloppy mark-up.
- philote 3y agoWouldn't you need to add another <table> tag if you're nesting?
- taeric 3y agoAll whitespace remains meaningless. That is, the optional closing tag has nothing to do with a newline. Rather, they are defined as optional if the next tag is one of a set, or their parent is closed. https://html.spec.whatwg.org/multipage/syntax.html#optional-tags https://html.spec.whatwg.org/multipage/syntax.html#optional-... is where these are defined. It basically says that a TD remains open until the next sibling td or the tr/tbody/table that it is in is closed.
- bentley 3y agoImplicit end tags aren’t sloppy at all. Documents using them are completely unambiguous and completely well‐formed, as has been the case since the inception of the language. In fact, the fact that implicit end tags and implicit elements are unambiguous is why they exist as a feature at all. <td> cannot contain <tr>—the idea doesn’t make sense—so <td> followed by <tr> implicitly closes the <td>. <li> can’t contain <li>, so it implicitly closes. <p> can’t contain <p>, and so on. XML doesn’t help at all here: even if you use a strict XML parser, you can make a construct like “<p><p></p></p>”, and it’ll be ostensibly “well‐formed,” but it won’t be valid HTML. The XML way of “make everything verbose, even when it’s already unambiguous” was a late addition to the language. And it leads to surprise like what’s visible throughout this thread, such as people expecting <div /> to act like <div></div> when it really acts like <div>.
- Pet_Ant 3y ago...and this is why I still only do XHTML strict. I mean giving up predictability and the whole world of XML tools and libraries for these "benefits"... I really don't see the point.
- TheRealPomax 3y agoGiving up what now? All the tools you need for HTML5 have existed for many, many years. You'd be "giving up" your tooling in the same way you're "giving up your car" if you buy a new car. You have a new car now, what's the problem?
- Pet_Ant 3y agoSorry, but how do I use XQuery with HTML5? How do I use all my generic XML tools with HTML5? I'm sure equivalents exist, but why learn them just so I can drop a few tags? Can't even use xmlindent if I do that to prettify it. If I need to embed HTML inside an XML document it's easier if it's XHTML than HTML5. It's much more convenient for most roles if HTML fits within existing XML flows. The only benefit of HTML5 is for those manually authoring them.
- TheRealPomax 3y agoYou use HTML5 query selectors, not xQuery. You don't use your generic XML tools, you use generic HTML5 tools. As for "why learn them so I can drop a few tags": because you don't, you make the tooling do it for you. Because that's what tooling is for. If you need XML: use XML tools. If you need HTML: use HTML tools. If you need XHTML... you're writing web content for IE, and IE is dead. XHTML died with it. Feel free to stick with what you know, but that's a pretty ridiculous argument for why you shouldn't use the thing that's used these days instead of the thing we used 15 years ago =) (hot damn, 15 years. It's been longer than most folks realize).
- gloryjulio 3y agoIsn't this just like python code?
- 3y ago
- 8organicbits 3y agoThis is the way. I really like that I can include arbitrary HTML when I need it, without complex escaping. Anyone who builds web pages already knows the syntax.
- roelschroeven 3y agoTo be pedantic, it's the tags that are optional, not the elements. The html, header and body elements are still there even if you don't write the tags. Quoting from the document you linked: "Omitting an element's start tag in the situations described below does not mean the element is not present; it is implied, but it is still there. For example, an HTML document always has a root html element, even if the string <html> doesn't appear anywhere in the markup."
- extra88 3y agoAs the HTML Validator will warn, there really should also be a declaration of the language, typically by having a `lang` attribute on the `html` element. https://validator.w3.org/nu/#textarea https://validator.w3.org/nu/#textarea