I struggled with Markdown (and various other mark up formats) for a long time, until I realised that, for me, nothing beats plain HTML for simplicity and expressive power.
I now use HTML the way people generally use markdown: as an open, easy to read, easy to write, plain-text format for taking notes, writing articles, expressing thoughts, and so on.
I didn't really choose HTML, I just sort of noticed that I was using it. It seems like an unconscious decision, like a river flowing downhill, finding its own path.
Most used tag would be <p>, because I write a lot of essays and things with paragraphing. As well as other structural elements such as headings and lists, I lean into <time>, <cite>, <abbr> a lot.
I tend to use the 'optional' form. I don't close <p>'s and <li>'s unless required.
But is [abc](http://...) any better? I can never remember which brackets to use, and I've been using Markdown for years now. I never have a problem remembering the HTML syntax.
My problem exactly. My memory seems not to work well for symbols which rely mostly on position. Is it URL first or link text first, and do I put the URL in round or square brackets? Same with formatting: Is the first * italics or bold? I can remember <i> and <b> much better, and will trade off a bit of verbosity for not straining my memory anytime.
The lack of internal consistency, especially the link syntax, has always been something I struggled with with Markdown. But that's about the first sensible way to remember it that I've seen.
Makes sense if you think about it. Basically everything is pretty well defined and its obvious what next tag should close the context. <td> for example obviously ends when you come across another <td>, another <tr>, or the required </table>
I lived through the XHTML era; when I was doing web-design I adopted it for many projects. It just seemed right to rigorously enforce a formal approach, and I suspect it reduced errors.
Took me a long time to train myself out of <br/> afterwards though.
But the optional-style works I think for writing. Especially if you're just writing a document. If you don't have site-menus, a search bar, social-media sharing icons, javascript libraries and all the other paraphenalia and page-furniture of a website, then you are left with a lean and structured file.
A silly corner of the spec, considering that this is a spec that specifies exactly how to handle e.g. misnested elements and admits plenty of other things that read intuitively as standardized sloppiness.
Nope, nesting works! The required ending tag on table means any nested table will open a new context and then any <tr> or <td> will now scope to that table and will until the second tables closing </table>.
10 years ago, I got frustrated adding in all the closing tags for my blog's articles, so I implemented Markdown. It made writing long articles so much easier that I wouldn't dare go back and wonder why I waited so long to do it.
Not equivalent, but arguably more useful for manual authoring: Emmet [0] was all the range a while back, and I still use it to write HTML. It comes naturally if you're used to writing CSS-like selectors, and mostly gets out of the way.
DSL-wise, I've rather enjoyed Clojure's Hiccup [1].
When writing html for documents and not as code, indenting everything really lost its luster to me, it's really nice to have the content root flush with the left margin.
pretty sure you're not supposed to use px in the height attribute. they are pixels.
the width will be set to match the aspect ratio but your browser will have to DL the image first. which probably doesn't matter unless you have content to the left/right of it, then it'll get bumped when the image loads. layout shift is a nasty thing.
I don't exactly write "HTML" by hand if by HTML one means (as seems to be implied in the article) long text documents with HTML tags in it. For that I use markdown because it's faster and much easier to read.
But I do write HTML templates by hand when I code webapps; it's cleaner and more efficient than use some kind of library.
I tend to use DIVs with custom data- attributes; I don't know if it's a good or bad practice but I'm not familiar enough with other approaches and I'm used to it.
I also code SVGs by hand and it's surprisingly easy and straightforward; most (not all, but most) drawings can be approximated by combining elementary shapes (instead of paths).
>I also code SVGs by hand and it's surprisingly easy and straightforward; most (not all, but most) drawings can be approximated by combining elementary shapes (instead of paths).
Interesting. Do you have any examples of thise approximations?
I write HTML by hand and one thing that's come in handy is HTML's built-in functionality for author-defined custom elements. We use ICON-LIST which wraps a UL and optionally an SVG if you don't want to use the default checkmark, and STAR-RATING which displays a rating out of 5 SVG stars. They aren't my most-used, that's probably P or A or LI or DIV or SPAN by number, but they're some of the most important I use frequently!
Web Components are generally considered to be a set of standards, and Custom Elements is one of them. The others are Shadow DOM and HTML Templates (the <template> element).
Was wondering as well. You can just go ahead and use your own element straight away. You just won't get tag omission and other short forms, but you aren't getting those by using the questionable JS API for declaring elements (or proposed new APIs for HTML fragment parsing in browsers) either.
The use case mentioned - custom list bullets - can be implemented using CSS btw [1]. Not that I'd advocate for it; like all things CSS, it involves lookup of obscure and rare custom syntax, questionable layering a la "content:", suggestion of orthogonality that isn't really there, and browser support troubles.
Is there an HTML formatter that'll strip unnecessary closing tags?
I used to be team semi-colon in JS but I've switched teams now and have my formatter strip them. There's like 1 or 2 edge cases where that can bite you but practically speaking it's a non-issue. The real downside is that I sometimes get lazy when writing C++ and that very much dislikes poor punctuation.
I write HTML by hand, and I am into retro-computing, so I write for Any Browser (with progressive enhancement for cooler features).
The p tag is one of the most frequent.
I use span tags for placeholders in templates, that way the HTML is still usable before it is filled in.
The tag form is important to remember, because older browsers will not even display input elements without it, and you won't be able to address them.
The font tag gets a lot of scorn these days, but it is the only compatible way to color individual parts of text in older browsers, so I use it sparingly, via templates.
There is a subset of HTML 2.0 which works consistently across about 25 years of browsers, and I think it is one of the most amazing technologies we have in the world, for its longevity, resilience, and open/unowned nature.
I use whatever programming language to generate HTML string from a simple function like h("div", { class: "box" }, [ ... ]), so I can use variables, loops etc.
<g> is interesting there: it’s an SVG element. SVG and MathML are fun in HTML syntax, because it becomes a little more XMLly when parsing them: XML-style self-closing tags (<tag/>) actually work, and there’s no such thing as a void element (e.g. <br> which has no closing tag because it has no contents). This can lead to fun problems in overly-simplistic filtering, e.g. <script/>alert()</script> is a syntax error in SVG or in XML-syntax HTML, is swallowed and does nothing inside SVG-in-HTML (it’s an empty script tag followed by a text node and an extraneous end tag), and alerts inside HTML (the trailing slash in the start tag reports a syntax error but they don’t do anything). This is ripe for security issues from smuggling stuff. There’s also fun like whether <script>alert("<")</script> alerts “<” (SVG/XML-syntax HTML) or “<” (HTML). These sorts of things are why it is said: use a real HTML parser if you’re working with HTML.
In the rest of HTML syntax, adding a trailing slash does exactly nothing—it’s just ignored by the parser¹. For my part, I firmly recommend against writing it if you’re using HTML syntax, because it gives the false impression that it does something; rather, there’s a hard-coded list of elements that have no contents and thus no closing tag. It’s not uncommon to find people writing their />, but it’s practically never consistently applied, e.g.:
So if you tried loading this with XML syntax (which is still very much a thing), you’d hit a parse error. And remember, this was put in as an XHTML compatibility measure (though I’m honestly not convinced it was worth it—without the special handling, you’d just have ended up with an attribute named / with an empty string value, which isn’t so bad).
HTML/XML polyglot is a surprisingly thorny issue, and my experience is that a lot of JavaScript libraries make assumptions that don’t hold in XML-syntax documents and thus won’t work properly. In practice, almost no one uses XML syntax for anything new, and foreign content (SVG/MathML) is the last remnant of widely-used XML in HTML.
—⁂—
¹ This is a very slight simplification. Look into the self-closing flag in the spec if you’re interested in the details.
² I think that wrong capitalisation of charSet comes from Next.js, because every time I’ve seen it, Next.js has been present. It has irritated me for years, but never quite enough to dig in and find the source and beg them to fix it. No idea if Next.js supports using XML-syntax HTML, but if it does, that meta charSet will be invalid, because XML syntax is case-sensitive and it’s supposed to be charset—though I think it will still work in practice because of the charset detection algorithm actually working on the bytes, not the XML/HTML syntax, and being case-insensitive. And if Next.js doesn’t support using XML syntax, I wish they’d stop generating trailing slashes, too, because they’re just a waste of time.
Yeah the trailing slash cargo cult just goes to show the author has no idea what he/she is doing. Even more pointless is a pretentious space before the slash. It appears many extant uses of the bogus slash result from WordPress filters and their fragile nature (never change a running WP system aka WP trainwrecks) rather than manual insertion.
> Even more pointless is a pretentious space before the slash
It could also be an habit, and not really a harmful one. You can argue against it with convincing arguments, but in the end, there's nothing fundamentally wrong with it. It's understood by the parser.
The space before the slash once was advised for compatibility with old browsers when writing polyglot html. Some old browsers would not understand the slash, but this would not be an issue with a space. This is mostly irrelevant today but habits stick.
And with the gotcha exposed by my sibling comment, maybe it's better to stick with the space after all when using the slash. And I can see how wanting to explicitly close the tag is compelling, even if it has its drawbacks.
Lots of lists on my personal site, even excluding the one non-handcrafted page.
#!/usr/bin/awk -f
BEGIN {
while( (getline t < "tags.txt") > 0) tags[t] = 0
}
{
for (t in tags) tags[t] += gsub("<" t "[ |>]", "")
}
END {
for (t in tags) print tags[t], t
}
./count.awk $(find . -name '*.html') | sort -rh | head -n 10
534 li
290 a
215 p
149 br
132 span
99 ul
66 b
47 div
40 pre
37 meta
I hate writing HTML. Yes, there's IDE support for inserting <s and >s but it's just annoying. Same for lists of classes or attributes etc.
For everyone else feeling like me: Try pug (formerly jade) or rather it's CLI variant pug-cli. You can reuse stuff and even have JS in it to iterate through things or give it parameters, all while still feeling pretty vanilla.
Lots of references to different ways to generate html and I feel obligated to mention sexpcode, a bbcode-flavored Lisp by the same guy who came up with sleepsort. Ye Olde /prog/ used bbcode for markup and /prog/ worshiped lisp so it was a natural conclusion.
I can't see how anyone would prefer xml formatting to sexp for any significantly lengthy document. I made my own homage to sexpcode called lispmark, some of my friends find it better than markdown or html..
Moreover, I don't even have internal dependencies, every page is written from scratch (with a pinch of copy-paste). This is a hobby project, and I like to program, so I'm just not interested in code reuse.
> Do you write HTML by hand? If so, what tags do you use most?
I like to use as many <table> and <span> tags as possible. Particularly for layouts. Sometimes, if I'm feeling frisky... <frame> gets invited to the party.
For many purposes it is needlessly verbose to write html by hand. Thats why markdown became popular.
But if more people do it and report their usage patterns one could maybe create a "super-markdown", i.e., the closest you could get to mapping html flexibility without the annoying XML verbosity.
> the closest you could get to mapping html flexibility without the annoying XML verbosity
Aka SGML.
Though while you can hide those away in an external DTD, SGML of course needs lots of markup declaration ([1]) for HTML "void" (empty) elements, tag inference, and enumerated attribute short forms, and then still more for markdown short references.
It's definitely heavier than Markdown's, but then again, it can do a lot more... In practice, if you're using Emacs, it doesn't really matter, because you can just insert a code block, and specify the language (if you're not using Babel stuff)
I struggled with Markdown (and various other mark up formats) for a long time, until I realised that, for me, nothing beats plain HTML for simplicity and expressive power.
I now use HTML the way people generally use markdown: as an open, easy to read, easy to write, plain-text format for taking notes, writing articles, expressing thoughts, and so on.
I didn't really choose HTML, I just sort of noticed that I was using it. It seems like an unconscious decision, like a river flowing downhill, finding its own path.
Most used tag would be <p>, because I write a lot of essays and things with paragraphing. As well as other structural elements such as headings and lists, I lean into <time>, <cite>, <abbr> a lot.
I tend to use the 'optional' form. I don't close <p>'s and <li>'s unless required.