HTML Tags Memory Test

https://codepen.io/plfstr/full/zYqQeRw

by robin_reala • 2 years ago

154 154 2 years ago

codepen.io

lucasoshiro• 2 years ago

Nice!

But it doesn't recognize marquee as a valid tag

codingdave• 2 years ago

It isn't valid. It is deprecated. Just like <blink>. But to be fair, the page doesn't specify which HTML standard we're working with.

wongarsu2• 2 years ago

HTML5 says it "must not be used by authors", but it still describes it as a tag, and describes what an implementation must conform to. I guess it's open to interpretation what "valid" means. But it is an HTML tag described by the HTML standard (both HTML5[1] and the WhatWG HTML spec [2])

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

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

TonyTrapp• 2 years ago

To be clear: Neither blink nor marquee were valid tags under any HTML standard. They always were non-standard browser extensions.

astura• 2 years ago

Because it's deprecated.

leftnode• 2 years ago

It's funny, I've been working with HTML since 1998, and I got 36 (though I do think <font> should've been allowed). I thought I'd do a lot better, but I guess you can accomplish a lot with only a few tags, CSS, and some minimal JavaScript.

alberth3• 2 years ago

I got to 41.

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)

taeric2• 2 years ago

I struggled to get to 44.

Mildly curious on what all I'm not using.

dotancohen3• 2 years ago

I got to 42 and forgot about font (and center, mentioned elsewhere). But quite a lot of tags weren't valid, such as marquee. I wonder if I broke 50 including those.

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.

block_dagger• 2 years ago

Easy to cheat on this one - the "pattern" attribute on the input lists them all in the source, unobfuscated.

KMnO4• 2 years ago

This isn’t an exam. You can also cheat with Google.

joeyhage• 2 years ago

TIL I cheat at my job every day when I use Google or AI code assistants

echoangle• 2 years ago

Yeah, and you can cheat in Minesweeper by inspecting the memory content of the game.

Waterluvian2• 2 years ago

Wait, there's more than just `<div>` ?!

robin_reala2• 2 years ago

Span gets you to 2.

wongarsu2• 2 years ago

Ah, you mean <div style="display:inline"></div>?

mjhagen• 2 years ago

Spot the javascript dev

gushogg-blake2• 2 years ago

71. Damn, some of them are obvious when you see them as well.

miiiiiike• 2 years ago

I got to 57 before running out of tags that I use at least once a year. Had an "Oh yeah" moment when I realized that I'd forgotten html, head, title, body, script, style, and meta.

KTibow• 2 years ago

Somewhat similar experience, except I started with those and somehow forgot about headings and images.

grose2• 2 years ago

I wonder what the most "obscure" tag is. My vote goes to <base>.

gushogg-blake2• 2 years ago

I was at least vaguely aware of <base>. No idea what <samp>, <track>, <dfn> or <del> do. Also apparently <ruby> is not for embedding Ruby scripts: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ru...

grose2• 2 years ago

<samp>, <var>, <kbd> are definitely weird ones. Maybe <kbd> would be more useful with some better default styling. I think <output> has some accessibility wins but I've never seen someone use it. <dfn> is a good pick, <abbr> is also up there with questionable semantic tags. <del> and <ins> are basically tailor-made for rendering diffs. <ruby> is really useful for Japanese, doing that styling manually would be a huge pain, but niche for sure. I'm happily surprised <small> survived. I still miss <center>.

mj4e• 2 years ago

samp and kbd are good for marking up terminal sessions e.g. https://j4e.name/articles/marking-up-terminal-in-html/

xigoi6• 2 years ago

<dfn> is important when writing mathematical texts. I use it all the time.

phantomathkg• 2 years ago

If one play/work with audio/video streaming. the <track> tag will be something that came across.

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

thiht2• 2 years ago

I got <ruby> simply because I kept seeing it in the list of tags back in the days when I used W3Schools, this useless knowledge stuck with me until today. Same for <bdi> and <kbd>. No idea what they do.

xnx4• 2 years ago

Maybe more obscure now. This tag was extremely common in early web development.

duskwuff• 2 years ago

Lots of candidates, but my vote would go to <figcaption>.

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

smitelli• 2 years ago

I started scrolling the list at MDN, saw that there is <portal> now, then closed the tab.

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

lucgommans4• 2 years ago

I gave it some thought but it's hard to say. For most of the ones I missed and mentioned in sibling threads, I can think of people who'd be aware of them:

- 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

Matheus28• 2 years ago

I’ve used <base> a lot, but it breaks so many things. It was one of my first couple guesses

spencerchubb• 2 years ago

I got 38, and I didn't remember div until I got to #35 lol. The obvious ones can be deceptively tricky

eggfriedrice• 2 years ago

Today I learned about <hgroup>!

TIPSIO• 2 years ago

In HS we were learning basic HTML and I did not care at all at the time.

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.

TheRealPomax4• 2 years ago

and you whipped out the whole "the browser doesn't care, as long as there's corresponding CSS that defines its page layout and styling"?

xnx4• 2 years ago

small but not big?

jeffbee• 2 years ago

Neither marquee nor blink?

xnx4• 2 years ago

I swear Google has published a report from their crawl data about how in/frequently different tags and frameworks were used, in part to determine what they might need to support in Chrome. I'm not able to find this anymore. Does anyone know what I'm talking about?

alberth3• 2 years ago

Given that DIV seems to be the only tag frameworks use the last 10+ years, such a report is not surprising.

seattle_spring2• 2 years ago

What do you mean by that? I know a lot of devs just blast div everywhere, but frameworks? Which ones?

phil-pickering• 2 years ago

This is the one that Hixie published back in 2006. It helped guide a lot of the early decision-making in the WHATWG when it came to proposing new tags for HTML5 in a bid to reduce the number of div's out there:

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

xnx4• 2 years ago

That's it! Exactly what I was thinking of.

lucb1e2• 2 years ago

BTW: I got 97

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

andrei-akopian• 2 years ago

I couldn't find anything either, my searches quickly get flooded with SEO spam.

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

nox101• 2 years ago

https://chromestatus.com/

Click the stats on the left

spankalee2• 2 years ago

That's from live Chrome user metrics, so it's page-view weighted and doesn't include enterprises and other users that opt-out.

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

jessegavin• 2 years ago

Don't right-click on the input and inspect element

InsomniacL• 2 years ago

from the source:

  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

nhggfu• 2 years ago

fun, but meh @ including tags with only semantic purposes (nav, footer etc) that could just be a good ol' div!

saurik5• 2 years ago

(edit: Multiple people have interpreted this comment in a way which makes them think I'm complaining about the semantics and one even seems to think I am "advocating for" using the wrong semantic... I am merely complaining about the chosen tag name and how much longer the much-later-added tag we all are supposed to use is than the tag which is in some sense--not technically, but morally--deprecated, as it undermines being able to use HTML as a true markup rather than a rendering target. If you find yourself thinking I'm against using <strong> and are somehow pro-<b>, maybe re-read the comment or go read some of my other much-longer explanations I've been <strong>-armed ;P into providing down-thread. FWIW, I do at least see how my comment was a bit confusing.)

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

catapart3• 2 years ago

"bold" is a style, and perfectly fine to use for any word that you want to apply that style to.

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

saurik5• 2 years ago

I am not complaining that it is "strong" instead of "bold" or that we have two separate tags, and I'd be perfectly happy if bold had never existed: certainly, if I actually wanted to use <b>, it isn't like anyone removed it from either the browser or the HTML standard... it is, in fact, that I agree with everything you wrote about the semantics of the situation which is why I even have a reason to be angry when I'm trying to read my hand-written markup.

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

mk12• 2 years ago

I spent a while trying to do all the semantic markup properly on my blog -- <em>, <i>, <dfn>, <cite>, <mark>, <strong>, <b>, etc. I eventually gave up and just used <i> and <b> everywhere. It was such a waste of energy reading MDN docs and trying to decide between tags when they render identically and 99.9% of users aren't going to view the source. I also encountered bugs like <cite> breaking Safari Reader View.

catapart3• 2 years ago

Oh, one quick note about your markdown from someone stupid enough to have tried to write his own markdown flavor: those slashes are a nightmare for handling urls/paths. Trying to programmatically distinguish between "my/path to/some/ridiculous folder/and/s/y/m/bol/s" and "/i want this italic/ but not this. and sometimes o/nl/y some letters in a word." was all too much for me. I quickly retreated from using slashes at all in the markdown design. But there are definitely better programmers than me with much better designs for text parsing, so don't let me imply it's impossible (or even that hard! I honestly don't know!). I was just reminded of the anecdote and thought I'd share.

wfleming• 2 years ago

That used to be the advice, but the W3C eventually agreed with you. The spec describes <b> as "a span of text to which attention is being drawn" (https://html.spec.whatwg.org/multipage/text-level-semantics....) and no longer mentions boldface as what the tag "means", it's just how it's usually styled by default & convention.

saurik5• 2 years ago

Huh... the documentation there for i is actually even more interesting to me: it seems like I'm actually actively "not supposed to be" (at least anymore, if ever) using em for almost every reason I've ever used it?!

austin-cheney• 2 years ago

Typing a couple keys on a keyboard is a pretty weak complaint considering the unintended consequence of what you are advocating for results in discriminatory output against persons with access disabilities. This is the literal definition of narcissism, even if unintentional.

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

saurik5• 2 years ago

But... I am, surely, not advocating for people using <b> now: I'm merely lamenting that we allocated a one-character tag for <b> and then resorted to a five-character tag for <strong>, as it affects the readability (I couldn't care less about how many characters it is to type) of the un-rendered/hand-written document.

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

sircastor• 2 years ago

I managed to get 50 unassisted. Now looking at these comments I'm amused at some obvious ones that I missed. I've been writing html since ~1995 (I think) and I was surprised that <frame> didn't work. It was all the rage back in the day.

spankalee2• 2 years ago

I would love to see an "I give up button" that tells you what you missed.

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

saurik5• 2 years ago

It counts <object> but not <param>?

catapart3• 2 years ago

None of the svg subtags, either. path/g/etc.

velcrovan• 2 years ago

I got to 63, I think mainly because I've been working on an HTML5 pretty-printer in Racket recently [1] (basically my own implementation of the formatting aspects of HTML Tidy).

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

ygra2• 2 years ago

In hindsight I missed a few obvious ones (completely forgot lists), but would have expected HTML 4 tags to still be HTML tags (font, etc.). And I do wonder why SVG is on that list, which can be used inside HTML, but is pretty much not an HTML element, to my knowledge (same with math).

oxguy3• 2 years ago

It's a valid HTML tag indicating that its contents are not HTML but instead SVG. The contents of a <script> tag are also not HTML, but we still consider <script> to be an HTML tag.

ygra2• 2 years ago

It's not just the contents; it's the tag itself. The only thing that is special to my knowledge is that the HTML 5 parser understands it and applies the correct XML namespace.

...

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.

Retr0id• 2 years ago

I somehow never knew that "h" goes all the way up to h6.

netcraft• 2 years ago

I got 45 fairly easily, but ive been writing html for a long time. Would love to see the output reveal them in a list in order of commonality - would love to see if im missing some common ones - like if you guessed 1-20 but missed 9...

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

lucgommans4• 2 years ago

<img> also took me the longest time, and <br> even longer though I used it within the last hour, but the facepalm moment came when I almost decided to give up and then remembered <h1> through <h6>. I even knew how many levels existed! Not that I didn't try h7 for good measure, one can't be too sure with these things :-)

thiht2• 2 years ago

Haha, I reached 77 and completely forgot about <br/>

KaiMagnus• 2 years ago

Funny, the first ~15 are easy simply by spamming h1-h6, i, u, em, etc… but then it gets hard.

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

scelerat• 2 years ago

oh noes! I viewed source and saw the answers

Titan2189• 2 years ago

And what else did you expect?

tomjakubowski• 2 years ago

I was hoping to be yelled at for entering <ISINDEX>, but instead my entry was politely rejected.

K0nserv• 2 years ago

Fun game, I got 76 and forget a bunch of common tags in the process: noscript, title, address, source(but I did get picture)

ChilledTonic• 2 years ago

No love for <marquee> or <center> anymore. Remember, an html tag is only truly deprecated if you stop using it and let it leave your heart.

Bilal_io• 2 years ago

I was about to say. Another thing is svg sub tags. I assumed they count since they're valid HTML.

I was able to recall 48.

merb• 2 years ago

blink is also missing

phailhaus• 2 years ago

They say a tag dies twice. Once when it is deprecated by W3C and the second, a bit later on, when somebody uses it for the last time.

TheRealPomax4• 2 years ago

Who needs <marquee> when we have @keyframes? Now everything is marquee.

breck3• 2 years ago

removing <center> was a mistake

assimpleaspossi6• 2 years ago

center is presention. CSS is for presentation. Don't use HTML for presentation or styling.

russellbeattie• 2 years ago

I got to 65 left... So 49 correct. I wish it counted the correct ones. And I want to see a list of what I forgot once I give up! (I cloned the Pen to see...)

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

elicash• 2 years ago

It looks like the comment tag isn't included. (Not sure whether it should be. Not even sure the proper way to identify it, I suppose a single "!")

lucb1e2• 2 years ago

I would have said !-- is the tag name of that, though with the closing part requiring a double dash as well, it's rather unique and maybe not a proper tag... could have included it in a bonus list though, not counting it towards the total but showing it as a bonus entry at the top of your findings

SushiHippie2• 2 years ago

In html 2.0 the definition makes a bit more sense than what the definition in the newest whatwg spec.

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

In the current spec it is basically defined as starts with "".

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

sophiebits3• 2 years ago

In the DOM, comment nodes are not elements, they're their own type of node altogether. Their .nodeName is `#comment`, for what it's worth.

jermaustin1• 2 years ago

I did worse than I thought I would since I've been at this since the late 90s. I blame code completion. I got to 68, and when another tag didn't come to me after 5 minutes, I gave up.

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

jchw3• 2 years ago

I managed to get just over half-way and recall 58 of them before I ran out. I find it interesting which are omitted. I assume these tags are just fully removed from HTML5, although most of them continue to work just fine with the exception of <blink>.

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

bsd_source• 2 years ago

It also doesn't accept keygen

(Although that never really worked.)

anderskaseorg• 2 years ago

It worked in all major browsers until it was removed around 2017–2019. I personally used it, as part of MIT’s authentication systems.

jefftk2• 2 years ago

It also rejected one of my favorites, the long-deprecated <xmp>

myfonj• 2 years ago

<xmp> and <plaintext> never die!

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

assimpleaspossi6• 2 years ago

Both blink and marquee have never been part of any HTML specification since the dawn of HTML. But marquee was inserted into the current version for the sole purpose of marking it obsolete because it was in such widespread use.

a_t48• 2 years ago

Fun fact - the website used for submitting visas to come to India still uses marquee.

sdsd• 2 years ago

I actually used marquee on two recent sites I made (for fun). On darigo.su if you open Napster (in the pokeball button computer), and on hnchan.darigo.su. I love marquee.

jchw3• 2 years ago

hnchan.darigo.su
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.

mbo• 2 years ago

No love for <q>? It does curly quoting!

jchw3• 2 years ago

Wow, that's awesome! I've been remembering the HTML entities for double quotes for so long, I actually had no idea this tag existed.

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>

you will of course get...

    “My English quote”

But, if you do...

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

Then you get:

    「日本語の引用」

Magic!

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.

hobofan• 2 years ago

I think for some fallback mechanisms <object> is the only way to implement them in pure HTML.

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.

CM30• 2 years ago

Damn, got 65 and then had no idea which ones I was missing. Turns out I forgot col, colgroup, menu, dfn, and a lot of others like that.

ajanuary• 2 years ago

Managed to get to 80 after about an hour while watching TV. Wish it would tell me which ones I’m missing, manually cross referencing seems like a bit of a pita. Fun though.

blixt• 2 years ago

Maybe the validator should be something like Object.getPrototypeOf(document.createElement("a")).constructor !== HTMLUnknownElement

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

dotancohen3• 2 years ago

That might make the results browser-dependent.

uses• 2 years ago

After a while they start flowing off screen. Perhaps make them an inline list, or a grid, or a list that fills from the top.

koito17• 2 years ago

For amusement, I tried inputting <applet>, <center>, <font>, <marquee>, and <object>, but the form declared them all invalid. I vividly remember using these over a decade ago.

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

pvorb• 2 years ago

TheRealPomax4• 2 years ago

Correctly: almost all of them were removed from the HTML spec many years ago (but not <object>, that's still a valid HTML5 element).

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 =)

Izkata• 2 years ago

It also doesn't like <blink> and <marquee>

CSMastermind• 2 years ago

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.

ElijahLynn• 2 years ago

I think this should be "HTML Elements Memory Test" yah? Tags are the opening and closing part of the element.

SushiHippie2• 2 years ago

Yeah the tag would be the whole part between < >.

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

xigoi6• 2 years ago

I got 83, which is 82 more than the average React developer.

sophiebits3• 2 years ago

I don't know about that, I worked on the React team full-time for several years and just got to 86 before getting tired and stopping. I imagine most of my former colleagues also know more than 1.

xigoi6• 2 years ago

Unfortunately Facebook, the flagship React application, does not reflect that.

j1mmie2• 2 years ago

61! Pretty proud of that

lucgommans4• 2 years ago

If you want to see which ones you've missed, put this in the JS console:

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

In Firefox (probably also in other browsers), links in the console are also clickable, so if you want to look any up, printing them as a link may be helpful:

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

I got to 80 found / 34 remaining (plus, of course, various deprecated tags and some which I'm very surprised were not deprecated such as map). Of the remaining ones, I've used several in the past and would have been able to say what they do... stupid memory is bad at enumeration!

gabrielsroka• 2 years ago

in the JS console

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

assimpleaspossi6• 2 years ago

Many people mention marquee and blink. Neither of those have ever been part of any HTML specification since the dawn of HTML. marquee was inserted into the current version of HTML for the sole purpose of marking it obsolete because so many people were using it (so I was told long ago).

hypertexthero• 2 years ago

Got around 82 by cheating a bit and looking at some old pages on my site.

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