What helped is remembering an entire "block" of tags

e.g. H1 would also mean H2-H6

(I'll be the first to admit I really struggled to get to 41 and I too have been writing HTML by hand since 90s)

Mildly curious on what all I'm not using.

For what it's worth, I started writing HTML when dates began with the prefix 19... though most of my career has been on the server side.

But it doesn't recognize marquee as a valid tag

[1]: https://www.w3.org/TR/2011/WD-html5-20110405/obsolete.html#t...

[2]: https://html.spec.whatwg.org/multipage/rendering.html#the-ma...

> what's particularly interesting is that the element cannot be closed

> the element cannot be closed

> cannot be closed

THE END IS NIGH! REPENT!

    <div class="inline-block">click me</div>

  <div class="zfJ2qEW6n">click me</div>

https://x.com/brajeshwar/status/1812149514632925525

And if you deal with Japanese website development, <ruby> and associated tags will came across, though less often.

Its sole purpose is to attach a caption to an image in <figure> - which basically no one uses.

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

- Probably <ruby> and related tags are used in Japanese and other spheres with such a language feature

- <base> I knew of, I thought archive.org used it but apparently not currently. Probably if you work with archived or otherwise namespaced content, you can reasonably find this a very familiar element

- <track> if you're a media person, doesn't seem that outlandish

- <dfn> I knew of basically, but just couldn't recall the names for glossary tags

- <kbd> is used all the time on Superuser (in Markdown, where HTML is valid though of course they filter most of it)

- Some others that I didn't remember, like <template> and <article>, were just stupidity. I know these...

This leaves <del> and <ins>. There are enough diffing tools, but it's not as big a category of software people constantly work on, especially since this is only for browsers. I'd not be surprised if these are the most-forgotten elements

Or does anyone still use <map>? I saw it in the HTML tutorial (linked from a Dutch magazine) that got me into programming so I know of it and remembered while doing the quiz, but it's fairly far faded from my mind and I'm not sure anyone would ever use it when, if you want this sort of functionality, you'd probably want the versatility of JavaScript

The teacher had us build a page with like 10 tags or something. I thought I was clever and quickly wrote out:

h1 h2 h3 h4 h5 h6 h7 h8 h9 h10

Needless to say he told me to figure out why I needed to redo it.

https://web.archive.org/web/20060203035414/http://code.googl...

The mantle has now been passed to the HTTP Archive, whose Web Almanac includes a section on the popularity of HTML elements:

https://almanac.httparchive.org/en/2022/markup#elements

BTW: I got 97, which is 96 more than the number of friends I have :)

Looked up your name plus the word 'w3'. I am not surprised to find involvement in an HTML spec discussion :D The top result on duckduckgo was <https://github.com/validator/validator/issues/1433#issuecomm...>.

Click the stats on the left

HTTP Archive has similar data, but from the web crawler, so page views don't matter.

I could write a page with a dozen marquees in it, but those marquees will be far less used than a single one on Google's homepage.

But it shouldn't be to hard finding each of these individually.

Here are some links I could find:

https://www.advancedwebranking.com/seo/html-study

https://w3techs.com/technologies/overview/javascript_library

  const elements = [
    "html",
    "body",
    "head",
    "link",
    "meta",
    "marquee",
    "script",
    "style",
    "blogroll",
    "constructionsign",
    "guestbook",
    "webring"
  ];
  // The above array was a decoy. You weren’t peeking at the array were you?
  // Now the real array with all elements via

Doing this reminded me how angry I am that I am supposed to use "<strong>...</strong>" instead of "<b>...</b>". The verbosity overhead in a normal document of markup littered with five-character tags for something as basic as a keyword is sufficiently worse than one-character tags that it drives me to want to use something like Markdown (but then I am angered that it went with *...* and **...** instead of /.../ and *...* and I just start to give up on other peoples' tooling entirely).

"strong" is an intention and allows other things to define what style(s) that intention should be represented with.

It's not often that you want to represent something as a "bold" style without representing it as having strong emphasis, but there are times. A header is a good example of a place where you might want the header to be styled bold, but strongly emphasize a single word in the header. Since <header> doesn't apply the styles that - say - h1 does, it would be perfectly reasonable to script your header as

``` <header><b>The <strong>Worst</strong> Case Scenario</b></header> ```

... especially if you didn't want all of your headers to have a bold style applied.

Obviously there are a few other edge cases but I will admit that the vast majority of the times would naturally call for a strong tag, over a bold tag. And for those majority cases, I'm really glad that it's "strong" rather than bold, because "strong" is meaningful in different ways than "bold" and it always makes more sense, to me, reading it back as html telling me how I should interpret the word, rather than just how it should look.

Instead, I am complaining that we got to allocate a one-character tag to bold and then when we realized that we screwed that up we allocated a FIVE-character tag to strong. Hell: we hadn't even run out of one-character tags!! Why not <e>...</e> and <s>...</s>?! If you really think we needed to preserve the one-character tags, that we were given a two-character abbreviation for <em> but are forced to use a five-character word for <strong> is just insulting :(.

Incidentally, there's also "strike" and "del", which look the same in my UA style sheet. I think strike was "deprecated" at some point, but I probably added it because websites still use it.

Did you use ChatGPT to count the letters?

https://en.wikipedia.org/wiki/Narcissism

(Hell: it isn't even clear that I'm "advocating" for anything at all; at best it would be "don't bother with HTML/Markdown, as both ended up making poor choices for readability of your source document: instead, use a custom markup/markdown and then have code--on your server--to render it into the appropriate semantic HTML". Yet, while that is how my blog used to work, I actually failed to reallocate the tag names.)

I do, in fact, carefully use <strong> in my HTML documents (though I'm now starting to wonder if that's wrong, per the sister comment which linked us to the standard; it, surprisingly-to-me, does seem like I'm "supposed to be using" <i> in most, if not all, of the places I've been using <em>...), and I've been known to go to pretty extreme lengths to correctly support various accessibility technologies in my code, both on the web and native.

It simply makes me a bit angry, every time I see it, that someone decided to make such a common element <strong> instead of, say, <s>, which I believe is a reasonable position and has nothing to do with accessibility, as we could have named the new tag <powerful> and it would have worked the same and yet clearly that would have been even worse than <strong> ;P. We should get to separately judge--and even potentially lament one of--these two decisions.

(I'm thereby going to assert pretty directly that your decision to insult me by calling a narcissist is based on you not bothering to read what I wrote or pay attention to the actual thing I was complaining about--as I'd in fact have no reason to complain if I didn't care about the same thing you do: no one removed <b> from either the standard or the implementation--and just ran with a knee-jerk interpretation of some of the keywords I used.)

> The b element represents a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood, such as key words in a document abstract, product names in a review, actionable words in interactive text-driven software, or an article lede.

Same for <i>: that's not short for "italic" anymore, it's just a letter now, and is defined as:

> The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts.

So go nuts: don't use <strong> or <em> if you semantically just needed <b> or <i>.

I got to 80, and I'm stumped on the last 34.

[1]: https://joeldueck.com/what-about/html-printer/

...

Ah, but thinking about it while I type these lines tells me where I'm wrong: It is an HTML element that's by default rendered as a block element, takes part in all the typical layout stuff. I can apply border, border-radius, background, etc. to it and it behaves like a div. Just that I can also put graphics inside.

edit: Case in point, I missed <img>...

Probably the only time I’ll ever use menu, dfn or del/ins.

I was able to recall 48.

It's so common (so common that it still works everywhere) might be worth an exception.

I just added 'center' tag to Scroll, and seems promising:

https://try.scroll.pub/#scroll%0A%20Hello%20world%0A%20%0A%2...

That's what I say to markup that uses the <center /> tag

https://html.spec.whatwg.org/dev/obsolete.html#obsolete

Semantic HTML was a pipe dream and a silly idea in hindsight.

Tailwind and CSS have nothing to do with semantics of a document outline and its markup.

Markup is the description of the contents of the document. CSS is the styling of the document and has nothing to do with description of content. That is the realm of HTML.

I'm sort of ashamed I couldn't remember more off the top of my head.

You know you've been doing HTML for a long time if you remembered 'base'.

https://www.rfc-editor.org/rfc/rfc1866#section-3.2.5

Basically <!> was valid, and -- only served as the start and end of a comment, and between <! and > you could have multiple "comments", example from the rfc:

  <!-- another -- -- comment -->

https://html.spec.whatwg.org/#comments

<blink> and <marquee> were my first guesses just for fun before I moved on and started with all the single character tags I could think of (a,b,i,p,s,u), then the various document tags (html, head, body, link, style, script, meta), then all the semantics (aside, article, nav, header, footer). Then the old school (table (and the descendants), div, p, span, etc...).

It made me realize how many tags I just do not use anymore (object or embed anyone?).

- <blink>

- <marquee>

- <tt>

- <center>

- <frame>

- <frameset>

That said, it accepts both <object> and <embed>, which I found moderately surprising, since I thought that those were mostly only used for ActiveX and NPAPI plugins. Maybe the last major round of deprecations for HTML came just a tad too early to kill them off, or maybe there is more to them than that.

Some tags I feel are underrated in handwriting HTML that are still in the spec: <figure> and <figcaption>, good for semantically representing images with captions. <thead>/<tbody>/<tfoot>, semantically segments a table; In theory could be used by assistive technology, or possibly renderers that need to paginate HTML and want the table headers to repeat on each page (does any agent do this?). <picture> + <source>, pure-HTML method of having responsive images in an HTML page, can support a fallback for browsers that don't support it, too. On that note, the srcset and loading attributes of img are very useful too, srcset as an alternative to <picture>, ostencibly aimed at use cases where the different sources are identical aside from pixel density (vs <picture> which is meant to contain potentially more significantly different images for different responsive layouts.)

I wonder which things I missed. That would be a nice feature to add.

(I know I missed a few table elements because I just thought of colgroup while typing this.)

(Although that never really worked.)

I think/hope/believe that even though these elements fell out of grace of the standard bodies [1] long time ago, implementers simply cannot go against backwards compatibility here and remove them like spec suggest and MDN scaremongers that it "was not implemented in a consistent way" [2], yet last time I checked, the support in major browsers was pretty solid [3].

- [1] yet https://html.spec.whatwg.org/multipage/obsolete.html#xmp tells still acknowledges that "User agents must treat xmp elements in a manner equivalent to pre elements in terms of semantics and for purposes of rendering. (The parser has special behavior for this element though.)" - [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/xm... - [3] https://github.com/mdn/browser-compat-data/issues/2168#issue...

> NB: we've left a SQLi vuln in this site. If you're smart enough to find it, congrats: you're a mod.

That's certainly a creative approach.

What's even more fascinating about <q> is that it is localized too! Wow!

Check it out. If you do...

    <p lang="en"><q>My English quote</q></p>

    “My English quote”

    <p lang="ja"><q>日本語の引用</q></p>

    「日本語の引用」

There's only one real problem I have with this: it seems to be implemented on the layout-level using ::before and ::after pseudo-elements, and thus the quotation marks are intangible. That's a real bummer, which has the result of making the quotation marks not able to be copied or selected (and their visibility to screen readers may also be impacted?)

So unfortunately, for now, I am going to continue using good ol' ldquo and rdquo. But, that's pretty neat.

E.g. I once built a logo element, where the logo may be either at logo_A.jpg, logo_B.jpg or logo_C.jpg. As there wasn't any API to determine which of them would exist in advance, I instead used three nested <object> tags. They would request the image in sequence, and the first one that would respond with an image is displayed.

I noticed several functional HTML elements (like "font") were not in the list, so might be nice to just trust the browser (not sure how you'd get the correct count per browser though).

There are a few sites still using <frame> and <frameset>, but both are marked as invalid.

Those are invalid now?

Well more useless knowledge accumulating in my brain I guess.

But: invalid according to the spec doesn't mean it won't do something in a browser, browsers aren't pure spec implementations, they're applications used by humans to view content made by humans =)

So "HTML Element Name Recall Test" would probably the most "correct" title, but I think everyone understands what the current title means.

> tag Markup that delimits an element. A tag includes a name which refers to an element declaration in the DTD, and may include attributes. [SGML]

> element A component of the hierarchical structure defined by a document type definition; it is identified in a document instance by descriptive markup, usually a start-tag and end-tag. [SGML]

https://www.rfc-editor.org/rfc/rfc1866#ref-SGML

https://en.wikipedia.org/wiki/Recall_test

    Els.filter((item) => {return ! Elsguessed.includes(item)})

    Els.filter((item) => {return ! Elsguessed.includes(item)}).map((item) => {console.log(`https://developer.mozilla.org/en-US/docs/Web/HTML/Element/${item}`)})

in the CodePen console, not in the browser's console.

here's a shorter version.

  Els.filter(item => !Elsguessed.includes(item)).forEach(item => console.log(`https://developer.mozilla.org/en-US/docs/Web/HTML/Element/${item}`))

  new Set(Els).difference(new Set(Elsguessed))

My favorite recent discovery is <details> - a native show/hide/spoiler toggle: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...

These are the ones I don’t remember ever using:

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

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

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

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

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

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

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

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

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

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

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

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