- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 13 May 2022 21:39:30 +0000
- To: public-webrtc-logs@w3.org
@eladalon1983 that's inverse of the [priority of constituencies](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies), and conflates "convenience" with "needs". 🤔 I was merely explaining to @yoavweiss there are zero web developer benefits to `produceCropTarget` being async, since he seemed to infer there had to be some (cropping-related feedback). I don't fault him, I fault the API for being confusing, by implying functionality where there is none (instead, all cropping happens in `cropTo`). A similar misunderstanding [surfaced in the TAG](https://groups.google.com/a/chromium.org/g/blink-dev/c/eZE9LTJMUlk/m/3Hj8dxslAwAJ) (_"a lot of elements not visible... these make no sense to set a crop target on"_), who thought this method was "settng" cropping(?) on the element, and that method only made sense on "visible" elements. Neither interpretation matches reality. That's three strikes against this API being intuitive: The "target" construct (which isn't "set") has nothing inherently to do with cropping, never fails, and is merely solving the sub-problem of referencing the element in a different realm. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/11#issuecomment-1126528615 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 13 May 2022 21:39:32 UTC