Looking at the MDN summary docs and the actual XMLHttpRequest standards docs, it is clear that XHR response types are just strings. One implements them by using something along lines of the following:
var xhr = new XMLHttpRequest();
//...more config...
xhr.responseType = 'json';
//or
xhr.responseType = 'blob';
//etc...
I would argue that when using enumerated properties it's pretty standard to key off of constant values. I wouldn't whine normally, but it's inconsistent with, say, the XHR ready state values. Reading the mdn summary docs and the corresponding W3C standards docs, you'll notice that these enumerated values are keyed off of constants (well, actually getters, but that's transparent).
Can anyone enlighten me as to why this inconsistency exists? It clearly does have little impact, but when I was writing an XHR interaction today I realized that 'json' and 'JSON' are technically different strings and you never know if all UAs are using best-practice string comparison. What might work in testing in most UAs might break in something that's not in your test matrix. Seems like a silly way to introduce a bug. I know legacy internet plumbing is pretty hard to clean up and that XHR goes waaaay back to the early days but I was wondering if there's another reason that wasn't just a design oversight.
Thanks!