- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Jan 2022 16:13:32 +0000
- To: public-webrtc-logs@w3.org
How common is it for specs to plug additional attributes directly onto HTMLElement? Checking the Chromium codebase just because that's the quickest way for me, it seems like it's [exceedingly rare](https://source.chromium.org/search?q=%22partial%20interface%20HTMLElement%22&ss=chromium). I expect that the Chromium implementation is a good approximation of what W3C specifications do, but if my hack at getting this information was misguided, please let me know. As for extending HTMLElement, that's of course [quite common](https://source.chromium.org/search?q=%22:%20HTMLElement%22%20f:idl&ss=chromium) - but that's not what you're proposing. :-) Btw, is it actually possible to expose a new field on all `HTMLElement`s without incurring **any** cost? I'm not sufficiently familiar with how this is implemented in Chrome, let alone in other browsers, but I'd expect a non-zero cost for this exposure even if the field is unset until it's first read. (Possibly as small as increasing a lookup table, which might only happen when the Nth new field is added. I am not sure. But probably it's not zero-cost...?) > For instance, what happens in the case of calling produceCropTarget on a detached iframe for a HTMLElement which is not part of the detached iframe? Could you please clarify how this edge-case would be problematic? The way I see it, if a given context can get a reference to the object in order to supply it as a parameter to `produceCropTarget()`, then that's all that matters. > Calling twice produceCropTarget on the same element is expected to produce the same CropTarget, which might be surprising given it is a method. I don't think that's surprising. We can also reduce the (IMHO already low) surprise factor by renaming to `getAsCropTarget` or something similar. But I think "produce" is good enough. > using promises here is to accommodate a particular browser implementation Politely disagree. It's done to afford all implementations the flexibility to implement efficiently and simply. If some implementations don't require this flexibility, I think it wouldn't harm them either - simply return the Promise pre-resolved. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/11#issuecomment-1022354841 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 January 2022 16:13:33 UTC