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 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!
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.
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!
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>
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):
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.
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.
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.
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.
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.
88 comments
[ 2.5 ms ] story [ 93.7 ms ] threadIf 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:
How many of these do you know? And how many have you ever used?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)
I guess I should have made this a private repo :D
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.
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).
Just open the test, answer the first question and press and hold Enter key :)
Tested with latest Firefox.
https://github.com/jakearchibald/request-quest/blob/master/w...
Only look if you don't want to do the quiz!
1 - http://www.paulirish.com/2013/webkit-for-developers/
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 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 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.