I think (and AFAICT) that bit is correct - i.e in this case parsing [1] the srcset would provide no candidates. I think the problem here is rather that we consider the <img> to "represent something" rather than "represent nothing" in this case - causing the 'width' IDL attribute to return the width of the fallback content instead.

[1] It's not obvious how an error being returned from https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-floating-point-number-values propagates to the local 'error' flag in the 'srcset' parsing algo, but it seems reasonable that it does.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/09b18a02d183f468777640bfbbee33352ee1795c

commit 09b18a02d183f468777640bfbbee33352ee1795c
Author: Fredrik Söderquist <fs@opera.com>
Date: Mon Oct 22 18:02:04 2018

An <img> with no 'src', no 'alt' but 'srcset' represents nothing

Based on [1], it would seem that we should treat the case where we have
no image candidate as representing nothing - this apparently also
matches what other UAs do.

Simplify the NoImageSourceSpecified helper function a bit. (IsNull
implies IsEmpty and !hasAttribute.)

[1] https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element:the-img-element-5

Bug:  897033 
Change-Id: I37ecad8faea2b929e8cf35ce7c746313b2d3b915
Reviewed-on: https://chromium-review.googlesource.com/c/1293574
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#601648}
[delete] https://crrev.com/96c0be24a293ae3dd08592cfe6496729cd2636f9/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/the-img-element/current-pixel-density/basic-expected.txt
[modify] https://crrev.com/09b18a02d183f468777640bfbbee33352ee1795c/third_party/blink/renderer/core/html/html_image_fallback_helper.cc