- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Mar 2022 17:28:54 +0000
- To: public-webrtc-logs@w3.org
> say some browsers ship HTMLElement and add Element support as a follow-up Chrome has already agreed to Safari's suggestion of exposing on Element. So I don't think exposing on anything but Element is a likely outcome. Or have you changed your mind on that? > !!Element.prototype.XYZ I think it's unlikely that any implementation would expose individually for various sub-types of Element, given how many of them there are. (Also, are we planning to avoid supporting/exposing for any sub-type? Chrome is not.) > you need to call navigator.mediaDevices.produceCropTarget with a value that is an Element (and not an HTMLElement) to check whether it rejects There is no plan to reject this sub-type or that. Feature-detection is global, regardless of the Element type an application expects to use. Even if we do expose this API on Element, what I expect is `!!Element.method`, and not `!!ElementVerySpecificSubtype.method`. -- To summarize * I think your arguments here are: * If exposing on Element, then non-conformant implementations would be less disastrous, because a sophisticated application could, if it is aware of non-conformance, check for exposure on the **specific** sub-type it intends to call `produceCropTarget()` on. * My arguments are: * Robustness to non-conformance is an argument, but it's not always a very strong argument. Are you aware of upcoming non-conformant implementations? Ones that don't work for any given Element, that is. * My original argument still stands - in favor of exposing an API adjacently to other APIs it interacts with, that is. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/11#issuecomment-1080943446 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 28 March 2022 17:28:56 UTC