Consider defining "failure"

[jyasskin]

We return "failure" from a bunch of algorithms, but I don't think we define what we mean. (It'd be a singleton type like undefined and null.) Should we add a definition in https://infra.spec.whatwg.org/#primitive-data-types?

@inexorabletash also points out that we're missing <dfn> markers for null, true, and false, and we're missing an Infra-level "undefined" entirely.

[annevk]

#95 has some discussion on undefined.

[domenic]

I think defining failure is reasonable. Such work should probably be coupled with advice on when to use it vs. null and undefined.

(My take: we probably over-use "null" when "failure" is appropriate. "undefined" should only be used when interfacing with JavaScript / Web IDL. "null" is also useful for that purpose. And, don't tie yourself into knots so that you use exactly the right type for each algorithm and then have to convert between them: if an important call site exposes the return value to JavaScript, and it should be undefined there, then it's probably not worth having your algorithm return "failure" and then doing an explicit conversion step at the call site.)

I'm hesitant about adding <dfn>s for null, true, and false because... really, do we want blue links for those everywhere in the spec ecosystem? (This is not a great reason, but still.)