I'm not sure this is "How well do you know HTML" so much as "how well do you know browser quirks and edge cases involving CSS, DOM, and HTML."

I did horribly. I actually did better just guessing at random in some sections. On the other hand, I can't ever think of a time in 19 years of coding HTML where I ever structured anything like the code examples in the quiz.

I agree, but I think these exercises are still useful.

Reminds me of an interview I had well over a decade ago. It was a pretty high-flying investment bank, that was over 80% PhDs.

They were a C++ shop and asked me a particularly gnarly C++ question in the interview.

I didn't know the answer. In fact, I had no idea. I was pretty green & it was a pretty scary high-performing environment. So I answered how & why I'd avoid it entirely. Plus what I'd do if I actually encountered it in the wild.

The interviewer told me at the end - "Plenty of other interviewees have answered that question, but you're the only one who got it right."

That's just an anecdote really, but it's been borne out in my experience too. Knowing what you don't know is sometimes very useful...

> The interviewer told me at the end - "Plenty of other interviewees have answered that question, but you're the only one who got it right."

Thanks for sharing that story. It was very instructive.

If it makes you feel better, I discovered loads I didn't know just writing the questions.

No, that's great too! I found the quiz informative. The title on HN was a little misleading, that's all.

Neither did I, though I still enjoyed it. Really opened my eyes to aspects of web development I never considered.

Well it's kind of a joke at the expense of the people who push these things into existence on the web.

I managed OK till the js part, and got bored (I suck at js anyway)

I find that having to guess at questions I simply do not know the answer to can actually prevent me from retaining the right information. Because it forces me to rationalize and objectify my guess which will now have to compete with the real answer in my head once I want to retrieve it.

I ended up clicking "No" every time and just read the information. Lots of good morsels in there. Then I went back and took the quiz to test my retention.

Though I have felt the intuition you mentioned, here's a study that found that test-then-study-then-test leads to better recall than just-study-then-test: http://www.sciencemag.org/content/330/6002/335.abstract

    > To test this hypothesis, we presented 118 participants with 
    > 48 Swahili-English translation pairs for an initial study trial 
    > and then three blocks of practice trials.

I didn't get to study before my test, but the participants in the paper got to study before their first test.

To attempt to use the language of that study, when I take a test with no prior study, I suspect that I'm creating mediators based on my arbitrary guesses. I'm wiring up false assertions in my brain because I'm forced to rationalize and make a "best guess".

Once I get to study for the first time though, I trample over all those forced assertions.

Retrieving the correct information now becomes an exercise in being able to disentangle or even distinguish truth from my own rationalizations. To make matters worse, all of my initial rationalizations sound reasonable to me where the truth may be less reasonable (especially regarding browser quirks and other arbitrary bits of data).

That's a whole class of extraneous junk data that I suspect you can minimize by getting to study before your first test.

Correct title: How well do you know edge cases with asset loading html, javascript, and css in the 4 major desktop browsers?

Too long.

This should be renamed to 'How well do you know Browser Quirks?' as the test is more about that than HTML itself

Also ... .replace(/HTML/HTML,CSS,JS/)

Another important take-away from learning HTML is that, as glacially as it may seem to develop, it is indeed constantly under development, not just by the bodies agreeing on new features and standards, but also by the browser vendors who implement them gradually.

How many use rel="canonical", rel="next", hreflan="x-default", role="navigation", and dir="ltr", for instance? And how many knew that you can target languages in CSS?

It's very important never to be complacent about the HTML you know - or think you know.

Oftentimes, people just seem to think CSS and HTML are the support wheels you need to master before moving on to the things that actually matter farther back on the front-end.

If someone doesn't want to click: It's a css 3d animated quiz with scores and covers questions about whether any browser loads a ressource like css, png or js-file or iframe under certain corner case szenarios (like writing a comment using inline script and the browser having a prefetcher with preparsing)

Hah, well, urm, this isn't quite finished yet, hence it being all broken in lots of browsers.

I guess I should have made this a private repo :D

I really like the presentation of the problems. I hope this is developed much further. It could, however, benefit a lot by having separate quizzes at different levels, and moving the edge-cases and browser-specific questions into their own quizzes. I also question the value of questions that are intentionally meant to trick you.

Some of these questions, by their nature of being browser-specific, are time sensitive since no versions are specified. And I'd have to double-check all of these answers because I found at least one which is wrong:

    window.onresize = function(){window.location.reload()}

Definitely reloads the page in Chrome 27 (and the current Canary, 29).

I can't recreate this. See http://jsbin.com/agitez/1/quiet, open dev tools, preserve the log, click the link, following page does not reload.

Resize the window.

The question was whether or not it refreshed the browser without user interaction. Resizing is an interaction

Yep, what MindTwister says https://github.com/jakearchibald/request-quest/blob/master/w...

The question makes no sense, in that case. The verbatim question is:

> Does the above trigger a request for the current page (a reload without user interaction) in any of the following:

The "without user interaction" as presented describes the request for the current page, implying a programmatic reload, not "will this code run without user interaction." Of course it won't, nor will this:

    function foo(){
      console.log('harharhar, I won\'t ever be printed, obviously!');
    }

At which point the question is really a basic/pointless JS question and has nothing to do with the concept the question is trying to address. Further, the part that manually dispatches the event doesn't quite match the spec:

> If the currently executing task is the dispatch of a resize event in response to the user resizing the browsing context

Emphasis mine. It's reasonable for an implementation to interpret this as a manually fired event does not meet the criteria and reload the page, while the same code called while actually resizing the browsing context would not.

Well, the question does make sense, and it sounds like you've understood it on 2nd reading.

> Of course it won't

Then your answer should have been "no". Remember, the very first example is a paragraph, and it asks you if it makes a request for an image, I don't see you getting into the same rage about that.

The resize question comes later on in the quiz, where the user may have thought "of course it won't" a few times when a particular browser does actually make a request. If all "of course it won't" examples actually made a request, it'd be a pretty simple quiz, right?

> It's reasonable for an implementation to interpret this as a manually fired event does not meet the criteria and reload the page

Agreed, it's a grey area. But this quiz is about what browsers do, not what the spec says.

It's a difficult quiz, no one's expected to get everything right. My expectations were blown apart when I tested a lot of this stuff. You got stuff wrong, that's ok, don't let it ruin your day.

> Then your answer should have been "no". Remember, the very first example is a paragraph, and it asks you if it makes a request for an image, I don't see you getting into the same rage about that.

There's a fairly huge difference between how browsers handle HTML and JS. After fully parsing HTML, the DOM tree is completely built and once resources are loaded, the page is completely rendered. It's declarative. Code is different. No JS interpreter runs a function you define until you call it. So code is parsed and then later on, independent of its parsing, can do things.

When you're asking if code does something, especially in the context of an event listener, it's expected you're actually running the code, regardless of how you've presented it. The HTML equivalent would have been to have asked if opening index.html here would've caused an alert to be shown.

    <!-- index.html -->
    <a href="image.html">Click me to see a funny picture.</a>

    <!-- image.html -->
    <img src="catpic1029381859834.png">
    <script>
        alert('I hope you like my cat!');
    </script>

A quiz should be testing actual understanding/knowledge, not intermixing over-literal interpretations and breaking reader expectations. And the wording on the question is still wrong, because as I pointed out, the sans-user-action point is emphasizing the page reload event, not the code itself, so the only logical interpretation is that the resize event happens. Technically, this could still very well happen without user interaction: consider gravity pulling out a display cable and causing the window to be relocated/resized by the OS.

> It's a difficult quiz, no one's expected to get everything right.

Incorrect. It's a deceitful quiz. The delivery is excellent sans a few load-time render issues, but the content needs work.

> No JS interpreter runs a function you define until you call it.

Right, but the browser can call it, that's the possibility we're dealing with here. If I assigned the code to window.onload rather than onresize, it would be called (by the browser).

With the first phase of the onresize stage, the question was "does the browser call this without user interaction?". And hey, if the question had the page in an iframe, the function would be called in IE.

Since a browser is so close to actually calling the function unexpectedly, I don't think it's unreasonable.

> Technically, this could still very well happen without user interaction: consider gravity pulling out a display cable and causing the window to be relocated/resized by the OS

I think it's reasonable and clear that the questions deal with the code presented and there's no outside influence unless stated. The point about no user interaction is emphasis, it's implicit throughout the quiz. Otherwise the user interaction could be the user opening devtools & adding code to the page to make the request, making every answer 'yes'.

> Incorrect. It's a deceitful quiz.

Crikey.

I was expecting some questions about obscure old school HTML tags and what they were meant for originally. Like others have suggested, maybe rename to cover web languages / browser quirks in general?

There are plenty of obscure modern HTML tags.

If anyway is bored I would love to see a graph of every possible HTML tag (old and new) plotted by frequency of actual use in the wild.

Some very rare - non outdated - ones:

  * colgroup
  * rowgroup
  * datalist
  * optgroup
  * fieldset
  * figure
  * figcaption
  * hgroup
  * keygen
  * legend
  * mark
  * ruby
  * details
  * summary

How many of these do you know? And how many have you ever used?

I would kill for good ruby support in all browsers. As someone learning Japanese it would be a godsend when it comes to reading and learning kanji.

However we would also need to pretty specialised editors / automatic converters to write the ruby markup since it is so $&~!@#^ verbose.

I still find it ironic that the browser with the best (i.e. working) ruby support is Internet Explorer. (I am aware of some firefox plugins but...ech)

I use fieldset and legend frequently. I believe Bootstrap uses these in their example forms, so I don't think these are nearly as obscure as the others.

optgroup is occasionally useful for demarcating groups within lists, but this need hasn't come up much in my experience.

I also use figure and hgroup, although more just for the sake of using HTML5 elements than anything else!

hgroup has been dropped from the spec. You can/should stop using it :)

hgroup has been dropped from the spec.

figcaption is actually quite popular now. Most newly-developed "html5" websites use it.

fieldset has always been quite common in my experience.

Very cool. I'd actually be more interested to know which mobile browsers these answers apply to, considering pretty much the only time I care about how many requests I'm making (within reason, of course) is when my users are potentially paying per request. I believe some mobile plans charge per request with a minimum of 1KB per request or something like that.

In case Jake is reading: that page is unfortunately unusable on an iPhone 4 in Chrome (latest). It freezes for 30+ seconds trying to load the background effect. It crashed once for me, too.

I am reading. It's a work in progress that "leaked", I should have made it private really until it was ready. Was originally built for a Chromebook Pixel kiosk at Google I/O, totally aware it burns most browsers/devices to the ground.

Also crashes mobile safari on an iPhone 5.

Works great on my Nexus 7!

Also works on Firefox mobile nightly quiet smoothly (but with some zoom issues on round changing).

This page is just a black screen for me on Chrome, Linux.

This was really nice, always great to get this kind of stuff in question/answer form. Making you think a little before getting the answer, as opposed to just in the form of some dense reading really makes this type of stuff stick in memory way easier.

Though you have to wonder, since the author clearly knows his browser quirks, as to why this only seems to work in webkit.

Well, wonder no more! The UI was thrown together for a Chromebook Pixel-based kiosk, so that's all I needed to support for the deadline I had.

Was planning on making it cross browser & responsive before making noise about it myself, which is why I've never mentioned it on Twitter etc.

Fix all of these bloody webkit-specific CSS properties, this thing is horribly broken in everything other than webkit. :P

I haven't finished building it yet (I didn't post it anywhere, the repo was discovered by others). You're welcome to preview it of course :)

It's also visually buggy in Safari.

I'm on the original iPad and it didn't work at all for me.

It degrades gracefully in current FF, release channel.

It just flat out failed to work in Opera :(

Hehe, <insert easy joke about Opera here>. Hehe.

Actually, I think it's more a joke about knowing HTML...

It doesn't seem to scale well at large sizes. It's almost unusable in fullscreen Safari on 1920x1080.

No, it scales fine on chrome.

This is fun and informative. Great job!

Many of these JS gotchas you usually don't find out unless you're either writing library code or you're really unlucky. For example, I'd say it's pretty weird for someone to create an script element and not attach it to the DOM at the same time.

I loved the passive-agressive 'encouragement' at the end:

Game Over

You scored 19 out of 39

Here's a fun fact: If you just blindly clicked 'yes' for every answer, you'd have scored better. But don't beat yourself up about it. I mean, you might hit someone else by accident.

Thought the one I got was really funny so I peeked at the source. Maybe that second 32 <= score < 35 text is a work-in-progress? :)

20>score?

Here's a fun fact: If you just blindly clicked 'yes' for every answer, you'd have scored better. But don't beat yourself up about it. I mean, you might hit someone else by accident.

23>score?

Sigh. Oh well. At least no one got hurt. That's the best we can take from that.

25>score?

That performance was like the film Taken 2. You went in guns blazing but the result was, well, ugh. Wouldn't buy you on DVD.

29>score?

Not too bad. If you were my child you'd be my second favourite. Even if I only had one child.

32>score?

Pretty damn good. There's a lot of gotchas in there that you managed to avoid.

35>score?

Difficult to criticise that score without being childish, so: Hahaha points you're a massive nerd.

35>score?

Wow, that was impressive! You hardly tripped up at all. Give yourself a gold star.

// Else:

You cheated. You cheated and I hate you.

What I found most peculiar in the knowledge provided by this quiz was this answer about the old method of reloading a page in the onresize handler (Anyone remembering this from Netscape 4):

https://github.com/jakearchibald/request-quest/blob/master/w...

Only look if you don't want to do the quiz!

This page brings my i3 Gentoo x64 Chrome Version 28.0.1500.20 beta to a halt. For example the rotating effect on the first page is very shaky getting a maybe 4 fps.

Lesson I learned from this: I never want to create a web browser. Reminds me of Paul Irish's blog post[1] about how few things a web browser engine give you and how much these browser vendors have to implement themselves.

1 - http://www.paulirish.com/2013/webkit-for-developers/

Interesting and humbling test of various browser quirks when it comes to inserting assets (and sometimes not inserting them at all) into an HTML document. This is good information to know but a bit too edge casey for me to commit to memory relative to what I personally do on a daily basis at this point. A nice table of all these quirks would be really useful though!

I enjoyed the presentation and animation, in particular. It was more fun than any other online quiz I've taken.

I got 200 points! ;)

Just open the test, answer the first question and press and hold Enter key :)

Tested with latest Firefox.

Hah, yep. Confirmed in Chrome too.

Lol, clearly this guy doesn't know it too well. So many rendering issues.

I'm not sure what to think. I mean, this guy clearly read the HTML spec where it pertains to page loads, but also clearly skipped the sections that pertain to basic layout.

You missed the bit about it being unfinished. I guess the quiz hurt your feelings so you had to come here and get your own back?

Seemed more browser-quirk specific than HTML specific if you ask me. Half of the examples in the test I've never used in my life and never will. Probably an extreme test-case, still was interesting and well put together nonetheless.

This is a good collection of corner cases. I knew more of them than I didn't by a good margin, but there were plenty that made me scratch my head and no small number that I got wrong too.

Not too good..23/39..need to learn about peculiar properties and behaviors that I assumed were trivial things but seemingly not. Great puzzle...I really enjoyed it, keep making more.

Thanks Jake - I did terrible on the quiz, so I found this really educational. Wish I could forget the quirks and focus on the spec, though...

This was super-interesting, thanks!

It would be nice to see the same information in a reference format (rather than a animated quiz), is that possible?

I know HTML pretty well. However, I don't know all the HTML5 JavaScript APIs so I'd wouldn't call myself an expert.

I kept seeing the = in lines such as <a href=...> as - as in <a href-...>, what's with that?

Good. I´ll point to that next time I need proof on how hard web development sucks.

Really interesting - nice job @jaffathecake! Good luck in finishing it :)

What's funny, is how horribly this site loads in Firefox 21.

This is a great way to present this information, thanks!

I agree with the other posters, that this quiz tests edge cases more than anything.

That said, I think it is pretty rude to tell me after showing my score that the quiz would, and I quote, "not buy [me] on DVD."

One should take oneself less seriously.

29/39 is damn good, it seems. What's yours!

26. Unfair! I never used web fonts at all :(

For the record, I hate web fonts because they always display incorrectly in anywhere between 1/4 and 3/4 major render engines. Usually all the ones except where you are testing in. I can't recall having seen websites with custom fonts that rendered correctly in Webkit, Presto, Gecko and Trident, so I shun webfonts altogether and just use the standard ones. Interesting fact that nobody seems to know: some people asked me what font I was using that displayed so well, while it was simply Arial with proper spacing. </rant>

"You scored 22 out of 39

Sigh. Oh well. At least no one got hurt. That's the best we can take from that."

Really enjoyed it though! And worked fine on FF 21 (Win7 64bit).

I 've had 29/39 too. Mostly guessing ("he wouldn't ask if this was obvious, so..").

Blackscreen on Chrome, Ubuntu. Works fine on Firefox

make it work first.

Very nice presentation, examples, and explanations.

This freezes like crazy in iOS Safari.

there really should be an "I don't know" answer. I hate being punished for a bad guess.

Crashes safari on my iPhone 4

How do the animations work?

I'm bad.