Knowing what mustard to cut
‘Cutting the mustard’ is the term the BBC News web developers use for what in other circles is called ‘feature detection’: Programmatically checking whether a given feature is available in the user’s browser.
The technique can be summarised succinctly as:
if (feature in element) {}
Where feature
is the feature to check for (like ‘querySelector’) and element is the element you will be accessing said feature on (often window
or document
, though it can be any DOM element).
This is a crucial component of progressive enhancement, adding features to users whose browsers can support them, in a layered manner where said features are considered additions.
The problem I have encountered is of a philosophical nature: What features should one cut the mustard for?
If we take BBC’s opening statement (‘The browser is a hostile development environment’) to its extreme conclusion, a browser could theoretically support no JavaScript APIs. Thus, to cut the mustard, one would have to feature detect everything.
Now, this is probably overkill. Aside from the obvious fact that if the browser doesn’t support the controls if
and in
feature detection isn’t even possible, there are softer features to check for that are probably overkill. Object.prototype.hasOwnProperty()
has been part of JavaScript since the beginning, and is implemented in all browsers known to MDN, so it can probably be assumed to be present.
But this still leaves the question: What features should one cut the mustard for? If we can assume some features are present, but not others, how do we determine which ones to check for? The only good rule of thumb I can think of is consulting implementation tables such as the ones on MDN and Can I useā¦, and drawing the line somewhere. And although better than outright user agent detection, it veers too close for my liking.
This might be me being too idealistic, but I am still unsure of the right approach.