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...
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.
> 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.
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)
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:
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'.
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?
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!
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.
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.
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.
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):
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.
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!
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.
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.
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>
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.