CropTarget should probably be available to Elements and not only HTMLElements

[youennf]

It seems Element is a good fit for CropTarget. This includes HTMLElement but also SVG constructs (how about cropping to a nice SVG element with some animations?)
That would seem more consistent with https://fullscreen.spec.whatwg.org which is defining requestFullScreen at Element level.

[eladalon1983]

Fine by me if nobody else objects.

[alvestrand]

I'd invoke the rule that "it's easy to expand, but hard to contract". We know that it is useful on HTMLElement, If we were to expand it to Element, that is possible to do later, but contracting down from Element to HTMLElement would be much harder.
(The alternative of saying "you can use any Element except these 47 subtypes" if we were to discover an issue does not appeal to me).

That said, if you can name a specific SVG element that it makes sense to crop to, we can add that to the list of permitted arguments to ProduceCropId() without any great heartburn. But again - probably as an extension.

[eladalon1983]

Given that we have an objection, how about we dial this back until we get a use-case? Note that developers can embed their Element of choice in a <div> and produce a CropTarget for the DIV, so we're not really blocking anything by maintaining the current scope of HTMLElement. Shall we close this issue, @youennf, until such a time as a use-case for Element is discovered?

[youennf]

Is that an objection? While I can understand the 'it is easy to expand' part of the argument, I do not understand the motivation to restrict to HTMLElement.
There are use cases to expose in elements:

• SVG or MathML would benefit from that.
• The fullscreen API is exposed at Element level.

contracting down from Element to HTMLElement would be much harder.

Can you provide a reason why we should not expose to Element?

such a time as a use-case for Element is discovered?

Such a time has come :)
Same use cases as full screen API, which is supported at elements level.

But again - probably as an extension.

As an extension to which spec?
I could understand the desire if mediacapture-region was in LC for instance.
But mediacapture-region is not even a FWPD right now so it seems the right time to do the proper choice.

[eladalon1983]

But again - probably as an extension.

As an extension to which spec? I could understand the desire if mediacapture-region was in LC for instance. But mediacapture-region is not even a FWPD right now so it seems the right time to do the proper choice.

• s/extension/enhancement
• The CfC to make it FPWD is currently blocked on these discussions. I'd rather we completed the open issues before we expand the scope.