> 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.
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.