RFC 5280 defines verification in terms of a trust anchor (issuer name + public key), and cert chain. So in the minimum case you must at least have a leaf cert which is signed by a trust anchor (which technically could be the same if it's a self-signed cert), So you always have at least one cert to do the various processing and checks on.

Some platforms have added non-standard abilities to trust an end-entity cert directly, without chaining to anything, and with varying amounts of processing / error handling. This is not specified anywhere, and the details and implementation is platform-specific.


For background:
AFAICT, Windows does not support it at all.

On macOS: 
* Can trust end-entity cert as “always trust”, works in Safari and Chrome+CertVerifyProcMac.
* Expired certs are OK
* Incorrect eku fails
* Inrecognized critical extensions are OK

On Linux/NSS:
* Can set NSS "trusted peer" bit, but Firefox no longer honors it, instead it allows to set an error override to handle the "how can I browse to my untrusted local test site" case. Current Chrome+CertVerifyProcNSS does honor it.
* Expired cert fails
* Incorrect eku fails
* Unrecognized critical extensions are OK


Given the lack of specifications, and the large differences between different platforms, and the questionable security properties it would be better to not support this, even on platforms where previously it was supported by the platform verifier. Instead users can use the override on the error interstitial, or can setup a proper local trusted CA which issues their test cert.