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!
Yeah, 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.
If an extra tool is fine, a really common trope in the world of minimal markup languages/libraries/DSLs are ways to write low-furniture html/xml and generate the delivery files.
DMark (https://denisdefreyne.github.io/d-mark/) is the only one I've used, but IIRC there are probably ~dozens of these out there (and many eschew furniture more than DMark).
I didn't know about DMark. I actually designed a syntax that provides a way to implement custom tags, but this is not quite easy.
While my syntax is even lighter than this, it's reasonable and DMark seems to be very easy and enjoyable to extend. And I say this as someone who doesn't know Ruby and for whom Ruby hasn't clicked (yet?). I'll definitely have to check it out, either to adopt it or to improve my own thing, ten years later.
Thanks for mentioning it, there's taste in this design. Very nice.
It is. I found it several years back but I finally built something on it recently and extending it was pretty simple (as someone who likewise doesn't know ruby, though I've written a little for Chef recipes).
I ended up writing a python parser for it (mainly just to get access to a different css parser), and the author also has a rust parser.
Yep, 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".
i 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.
Well, 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.
yes, 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)
I think I see your point, but it feels weird to see this form, to me.
To your point, I can see the opening tag as ( and the closing as ), but then that would lead to something more like:
(table
(tr
(td one
(td two
(td three
(tr
(td ...
Which really just highlights how odd it is to see the opening tags without the closing ones. Which probably goes a long way to explaining why I don't like it. :D
Probably more natural to have something like:
(html
table
tr
td "one"
td "two"
tr
td "...")
In this way, you could optionally have the closing tags of /td and such. Still looks very weird to me.
Raw 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.
HTML 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).
Fair, "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 )
Markdown 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).
Ish. Per 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)."
My 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.
To 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."
...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.
Giving 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?
Sorry, 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.
You 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).
I'm mostly HTML5 at this point and have been for some time. The only exception I would make is things (say, Standard Ebooks) that haven't made the jump yet so their linters freak out if you don't do things exactly as they expect.
For the record, anyone who writes `<br />` as `<br>` is...misinformed.
It's not our (SE's) choice to use XHTML in ebooks, it's part of the epub spec. So we merely expect valid XHTML per the epub spec, and valid XHTML requires self-closing tags.
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.
Implicit 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>.
The XML way is very good for XMLs purpose, which is enabling generic tooling that doesn't need to understand the semantics of the particular application language, which is great for building a foundation for tooling to support thousands of application languages most of which will have very few users so it is very good if much of the tooling cost is smeared across lots of other languages.
HTML is important enough that it warrants direct investment in tooling and doesn’t need the XML approach.
> “make everything verbose, even when it’s already unambiguous”
The idea is to make the language less context-sensitive and more consistent. It's better if the meaning of `<p>` and `<p/>` don't change based on the parent tag. Now, obviously they failed at making the semantic changes necessary to achieve the goal, but a true XML-based language would've been far simpler both for humans and computers than what we've got now. Most of the author's points are entirely valid, but the conclusion really should've been "HTML is bad."
But the meaning does change based on the parent tag. <p> is not allowed to be nested, just like <li> and many other elements. Those are rules anyone writing markup has to remember, whether XML or not. Allowing <li> to close the previous <li> is a natural extension of that rule, and strikes a good balance between the rigor of XML and brevity of Markdown, whose context rules I find to be both less consistent and incredibly difficult to remember. (Can a list contain a list? Does ^ superscript a whole line or just a word? What elements can contain a table?)
All 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.
As 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.
This 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.
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:
Tables become uncluttered: And you can even write the entire document in that style: No need for stupid html, header, body elements. They are optional![0] https://html.spec.whatwg.org/multipage/syntax.html#optional-...