Writing HTML by hand | Hacker News Reader

Writing HTML by hand

simblob.blogspot.com

100 pointstodsacerdoti71 comments

HTML is how I write.

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.

<a href="">links</a> are such a pain to write though. Probably the biggest annoyance when I write in raw html.

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.

IMO, yes, it is so much more concise that it is worth memorizing.

https://mtsknn.fi/blog/how-to-remember-markdowns-link-syntax...

Think of it as a function call (mnemonically, it doesn't need to make sense conceptually).

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.

Easy trick to remember it: [Button](url)

The [ and ] are ascii art for a button - in between goes what is clickable (title) and then comes the url.

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.

yes of course.

> I can never remember which brackets to use

and that is patently untrue, as you just demonstrated.

I had to look it up before writing my comment :)

The optional form is weird looking coming from the XHTML era where we were trained on the auto-closing form.

Looking up elements that support no closing tag:

html, head, body, p, li, dt, dd, option, thead, th, tbody, tr, td, tfoot, colgroup

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.

You mean </br>, presumably.

<br /> is a self closing tag. This is used in XML / XHTML for elements that have no contents.

It is a valid short form of <br></br>

technically <br></br> is not allowed to have an end tag in the HTML spec

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/br

so it should be <br> on its own or <br />

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.

Wow, thanks everyone... it seems I've misunderstood this all these years.

You see this a lot in React/JSX too. Saves seme typing and noise inserting a component with no children.

No. <br></br> is shortened to <br/>

><td> for example obviously ends when you come across another <td>, another <tr>, or the required </table> //

Only a madman would nest tables!!

/me crying in 2000's web design.

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>.

  <table>
  <tr>
  <td>
    <table>
    <tr>
    <td> table-cell-inside-table
    </table>
  </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.

I really love Elm's way of writing html. It's like writing html without closing tags, just indentation.

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].

[0] https://emmet.io/

[1] https://github.com/weavejester/hiccup

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.

Check out haml. Quite similar approach I think.

For me personally, elmish offers even better usability. But thats probably down to simple familiarity.

How do you create TOC ? Navigation bars ?

There's a difference between a web-site and a document. When you fire up a word-processor do you produce a document with "navigation bars".

As for TOC, I've never written anything that strictly needs one. I do have "hxtoc" on my laptop, but I've never needed it.

I do publish some of my writing to my website, and I discuss the minimal tooling I use here: https://brett.coulstock.id.au/site-colophon.html

but how do you do images or video, they need some extra magic work

I'm not sure I understand your question. <img> is the tag you use for an image, and there are tags to embed video.

Yes, it's really simple. And if he meant sizing, "height" and "width" parameters still work in an img-tag:

<img src="img.png" height="100px">

(also the other parameter is set to "auto" automatically, at least in Firefox)

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.

But you can do it and it works. And because it's about taking quick notes, it's not really about the beauty of the layout or layout shifts, isn't it?

<img>? <video>?

but i'm not sure if i understand the question...

In web 2.0 everything is done by javascript.

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?

Here's the Y of HN that I posted as a comment a couple of months ago:

https://news.ycombinator.com/item?id=35898741

Thanks.

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!

Are you talking about web components?

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.

[1]: https://web.dev/css-marker-pseudo-element/

I write all my presentations in HTML.

Advantages: - greater flexibility than with Markdown; - no need to decide between Markdown, ReStructuredText, Wiki markup, BBCode, etc;

Disadvantages: - writing closing tags is cumbersome;

The source code is here: https://github.com/ClickHouse/clickhouse-presentations Example: https://presentations.clickhouse.com/meetup74/ai/

> writing closing tags is cumbersome

Personally I've come to appreciate that many closing tags are unnecessary in HTML. Makes many constructs much more concise. Especially with tables:

  <table>
  <caption>Some letters and numbers
  <thead> <tr> <th>Letters <th>Numbers
  <tbody>
    <tr> <td>A <td>1
    <tr> <td>B <td>2
    <tr> <td>C <td>3
  </table>

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'm old school and write all of my HTML by hand in BBEdit: https://www.barebones.com/products/bbedit/

My most used tag is DIV, because I write more games/apps than docs. By hand using Vanilla JS and HTML.

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.

You might like my tiny library: https://hdot.dev/

It is a bit terser:

h.div.class('box')(...)

<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.:

  <meta charSet="utf-8"/>    ← ²
  <link rel="…" href="…"/>
  <link rel="…" href="…">    ← Where’s my /, hmm?

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.

Mind you, the space before the slash can be load-bearing in HTML syntax, if you use an unquoted attribute value:

  <img src=x/>   =  <img src="x/">
  <img src=x />  =  <img src="x">

Anything you don't write by hand will be difficult to replicated, by hand, later on.

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.

https://pugjs.org/api/getting-started.html

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..

I do all the https://wordsandbuttons.online/ by hand, and this is my top 10:

Do you use a particular JS library for the visualizations? They look great!

No, it's all vanilla JS.

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.

  find . -name '*.html' -exec tags {} \; | sort | uniq -ic | sort -rh | head -n 10

  12307 td
   7224 tr
   5851 table
    950 code
    821 font
    644 a
    522 p
    373 b
    332 span
    293 br

> 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.

[1]: https://sgmljs.net/docs/whatwg-html200129-dtd.html

I've created xidoc[0], which is meant to make writing HTML (as well as LaTeX) easier and more powerful.

[0] http://xidoc.nim.town/

Arguably, org-mode provides a "better markdown", but it's decidedly more niche.

I like org-mode, but one of my gripes is that code block syntax is too clunky.

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)

Emmet!

Reply on news.ycombinator.com