Need for a predictable error type for unimplemented Element subtypes

[eladalon1983]

CropTarget.fromElement() receives an Element as input. Element has many subtypes, and some new ones will be introduced over time. Some implementations will, at certain timepoints, not support certain subtypes. Web-developers would appreciate a predictable failure path for still-unimplemented subtypes. (The alternative - each user agent failing differently - is clearly undesirable for Web developers.)

Note on background discussions: Three criteria have been described in previous discussions. The current issue refers to the second of these.

[jan-ivar]

The cropTo spec algorithm should not require per-Element implementation AFAIK (if it does, we should clarify that). The algorithm relies solely on the element's bounding client rectangle, something every Element should have — even if it's {0, 0, 0, 0} which I believe we've already decided should produce no output? — so I'm afraid I don't understand the problem.

Some implementations will, at certain timepoints, not support certain subtypes

Then they're not spec compliant, I think is the answer. Allowing implementations some time to catch up with specs seems fine and normal for a while — Firefox throws NotSuportedError on several methods the spec says shouldn't, and there are bugs filed on all of them — But I don't think it's the spec's job to detail all the ways an implementation can fail to meet it. In fact, doing so risks giving the wrong impression the implementation is compliant when it is not.

Web-developers would appreciate a predictable failure path for still-unimplemented subtypes. (The alternative - each user agent failing differently - is clearly undesirable for Web developers.)

I think that would send the wrong message. Web developers need to know when they're expected to file bugs on vendors and when they should not. In this case, I'd prefer they file bugs. To that end, I think having the spec say failing in this way is NOT to spec, helps clarify that they're expected to file bugs.

I do see some uses of NotSupportedError in specs, e.g. around media types as inputs, and that make sense, but I don't think this issue meets that bar.

[eladalon1983]

In fact, doing so risks giving the wrong impression the implementation is compliant when it is not.

Youenn has brought up a similar concern. This is unclear to me. Users installing a browser would notice when applications don't work. That the failure makes the browser "compliant" is not going to help such a browser gain/retrain market-share. Implementers are motivated to implement missing functionality, independently of compliance.

Web developers need to know when they're expected to file bugs on vendors and when they should not.

Similarly, I don't think Web-developers would refrain from filing a bug over missing functionality under the assumption that a "compliant" browser is complete by definition. I imagine people ask for Firefox and Safari to support tab-capture, without caring whether the spec allows getDisplayMedia() to not offer tab-capture.

I do see some uses of NotSupportedError in specs, e.g. around media types as inputs, and that make sense, but I don't think this issue meets that bar.

Where is the bar?

[jan-ivar]

Implementers are motivated to implement missing functionality, independently of compliance.

Here you seem motivated by compliance.

Where is the bar?

Some specs deliberately allow UAs to support types beyond a minimal required set, which is not the case here. This spec says all elements must work. This spec suggests a way to implement this that doesn't fail for future element types.

[youennf]

+1 to what said @jan-ivar.
I think the bar is met when there is an open ended parameter, say a video codec name for instance.
Here the expectation is that all elements should be supported.
As said previously, this does not prevent a partial implementation to temporarily use NotSupportedError.

[eladalon1983]

Implementers are motivated to implement missing functionality, independently of compliance.

Here you seem motivated by compliance.

That's a non sequitur. Of course Chrome cares about compliance, but how is that relevant? Would Chrome now ship null-functioning APIs and declare success? Has Chrome funded this effort of standardization and implementation of Region Capture as a strange joke? What do you mean to say here?

I also ask you to examine with your chair's hat on, whether your comment here falls within the guidelines of this WG's discourse.

Where is the bar?

...

Thanks for clarifying your positions here, @jan-ivar and @youennf. I disagree with your bar, but now I know where it is.

[youennf]

I disagree with your bar, but now I know where it is.

FWIW, I am basing my assessment of what the bar is on how existing specs are written.
We should reassess the situation if there is a general desire to be more precise for this kind of situations.