Re: [mediacapture-region] Need for a predictable error type for unimplemented Element subtypes (#55)

The [cropTo](https://w3c.github.io/mediacapture-region/#dom-browsercapturemediastreamtrack-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](https://drafts.csswg.org/cssom-view/#dom-element-getboundingclientrect), 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.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/55#issuecomment-1154115720 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 13 June 2022 16:13:36 UTC