How well do you know HTML?
jakearchibald.github.io
jakearchibald.github.io
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.
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...
Thanks for sharing that story. It was very instructive.
I managed OK till the js part, and got bored (I suck at js anyway)
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.
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.
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.
I guess I should have made this a private repo :D
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()}
> 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!');
}
> 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.
> 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.
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>
> 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.
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.
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
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!
figcaption is actually quite popular now. Most newly-developed "html5" websites use it.
fieldset has always been quite common in my experience.
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)
Though you have to wonder, since the author clearly knows his browser quirks, as to why this only seems to work in webkit.
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.
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.
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.
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.
https://github.com/jakearchibald/request-quest/blob/master/w...
Only look if you don't want to do the quiz!
Just open the test, answer the first question and press and hold Enter key :)
Tested with latest Firefox.
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.
It would be nice to see the same information in a reference format (rather than a animated quiz), is that possible?
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."
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>
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).