> I've never had to or considered serving pages as application/xhtml+xml, there's no reason for me to know the answer to this question

I think VML's response is valid here, it's to check for experience and if you were engaged enough with the happenings of the web at the time.

Background (not a 100% accurate, I'm writing from my admittedly poor memory):

XHTML and later XHTML2.0 were being pushed a while ago (early 2000s) as the next HTML language (succeeding HTML 4). At some point the community split and people from Mozilla, Apple and Google (I think) formed WHATWG to pursue a different (and faster) direction which is where HTML5 was formed, then later adopted back by the W3C.

One of the issues at the time when people pushed for wide XHTML adoption was that most people served pages as text/html which was basically wrong.

Serving pages as application/xhtml+xml triggered the XML parser instead of the HTML parser which is the "proper" way to parse XHTML.

The problem some people ran into was that the XML parser is way less lenient than the HTML parser. You _have_ to close your tags, you _have_ to escape entities, and if you had a single mistake anywhere in your markup the browser would render an error page instead of working around it.

There were also issues with in-lining JavaScript and having to wrap it in a CDATA block to stop the XML parser from attempting to parse it.

This was a headache for sites with user generated content and people in general seemed to not like the idea of having to clean their markup for what some perceived as very little gain.

Anyway, long story short, HTML5 won, XHTML didn't.

Makes sense I don't know any of this, I was in high school in the early 2000s.

What it needs is the explanation why.

Preface with I'm not a front end guy, but I get the impression this was a major discussion topic around a decade ago. So this specific question is a resume tester, you claim 15 yrs experience on the resume, lets talk about a major gossip or controversial topic from 10 yrs ago that is pretty much irrelevant or uncontroversial today so someone with only 5 "real" years experience would have no opinion about the topic.

Also give the candidate a little BS, and evaluate the response. In programmer land if you ask a candidate what the first line '#!/usr/bin/perl' means in a CGI script and if the candidate keeps cool then thats good, but if the candidate responds like the intro scene of the movie Bladerunner then its probably not so great of a candidate regardless of anything else.

This is a bit unrealistic... asking someone what spacer.gif was used for could in theory work the way you describe, because it was something wide-spread and doesn't require you to recall too much details, just a general idea. On the other hand, issues like this xml mime-type thing are just too specific to recall after all that time. Frankly I don't remember half of the things that I've read last week and this was decades ago...

On the other hand, asking theback-end programmer what is a shebang line is totally legit in my opinion, nothing BS about it.

The context of the questions is important - they can tell you what someone knows and what they don't. I don't think the idea is "don't hire anyone who is unaware of the consequences of serving pages as application/xhtml+xml".

Plus if you are secure in your abilities you should be able to say "no, I'm not quite sure why that could be bad" without feeling like the world is ending. We all have stuff to learn.