What should the spec say about elements like HTMLAudioElement?

[eladalon1983]

Let's continue the discussion which stopped here.

It looks like some Elements are not sensible crop-targets. For example, HTMLAudioElement. What should we do with these?

Edit, 2022-05-27, 21:15 CEST, at @jan-ivar's request: In case it's not clear from the context of the aforementioned previous discussion, I am suggesting we allow user agents to reject CropTarget.fromElemet() on elements such as HTMLAudioElement.

[jan-ivar]

I don't see a problem with HTMLAudioElement:

It looks like some Elements are not sensible crop-targets.

I think focusing on what can and cannot be a "target" at the time of minting is the wrong place to triage what can and cannot be cropped to.

Lots of elements won't make sense to cropTo (but you can't know that at the point of minting):

1. Elements properties that control their visibility (e.g. controls) may change at any time
2. Elements may become attached or become detatched to a captured document at any time
3. A div may become 0x0 pixels or huge depending on CSS changes at any time
4. An element may become obscured or invisible at any time, rendering its appearance irrelevant to what's captured

In short, the live cropping algorithm is going to need to handle situations occurring that produce no output. Trying to use input validation to ween what goes into this basket seems of low value.

[beaufortfrancois]

I don't see a problem with HTMLAudioElement:

Without the controls HTMLAudioElement attribute, the HTMLAudioElement is invisible as you've noted later in your answer.
You can enter data:text/html,<audio style="border: 10px solid red"></audio> in your URL bar to see it in action.

[eladalon1983]

Lots of elements won't make sense to cropTo (but you can't know that at the point of minting):

1. Elements properties that control their visibility (e.g. controls) may change at any time
2. Elements may become attached or become detatched to a captured document at any time
3. A div may become 0x0 pixels or huge depending on CSS changes at any time
4. An element may become obscured or invisible at any time, rendering its appearance irrelevant to what's captured

These events belong to the category of things that could happen even after cropping. They are covered in the spec, and is in fact the basis for many of the design decisions behind the spec. But we're not discussing these.

Rather, we are discussing something that is known before minting and cannot change - the type of Element. If it is extremely unlikely that Web-developers would use a target of a certain type, then time spent expanding the definition to include it, and time to implement it, is time wasted. Time that could otherwise be used productively (to the benefit of all constituencies). We should seriously consider allowing user agents to reject some types.

[youennf]

Rather, we are discussing something that is known before minting and cannot change - the type of Element.

It seems HTMLAudioElement would be eligible to cropping according this definition but HTMLAudioElement should not be eligible to cropping based on the initial message of this thread. I have difficulties following what we are trying to discuss here.

If the type of element is ensuring that it will always be 0x0, it should be very very very simple to implement and optimize.
This might not be super useful for web developers (though who knows!), but rejecting does not seem great either (rejecting is like throwing an exception, it might disrupt applications, especially if some browsers reject and not others). Specs should try to avoid allowing UA specific behaviours. Rejecting is also not the best approach for feature detection.

It seems what we are after here is something different, maybe scoping the spec down to only supporting div/iframe (?).
This is a different discussion that we can certainly have. Note though that consensus was reached for supporting all elements so I think new information, for instance how hard it is to support some elements, would be useful/needed.

Please also note that trying to revisit this issue has impact on the API discussions we are having in #50.
For instance, fromElement is not a great name if only div/iframe will ever be supported.

This discussion seems fundamental (what are the input we want to support), so fundamental that it seems best to solve this issue before trying to rush out any API proposal like #50.

[eladalon1983]

If the type of element is ensuring that it will always be 0x0

At least with HTMLAudioElement, it does not appear that it's always 0x0. But please note that it was not me who introduced 0x0 into the discussion, I was only answering @jan-ivar's question. I don't think 0x0 is special, and I've explained as much. What I asked was - is it "sensible" to support HTMLAudioElement?

it should be very very very simple to implement

It is common even for engineers of all experience levels to underestimate future challenges in implementation. I do not feel confident enough to say it would be simple to implement cropping for all possible Element subtypes. The spec should not mandate that we MUST support an Element subtype, if that subtype is neither sensible (Web-developers don't need it) nor simple (browser-implementers might have a hard time with it). Such a requirement would serve nobody.

This discussion seems fundamental (what are the input we want to support), so fundamental that it seems best to solve this issue before trying to rush out any API proposal like #50.

@youennf, you have previously agreed HTMLElement made sense, and at your suggestion, we even expanded to Element. You made this suggestion five months ago. The API as a whole has been debated for 1.5 years by now. I do not think this qualifies as "rushed". It is the nature of our jobs that decisions must be made without full certainty. Past a certain point, additional debates are less productive than making a decision, even if that decision could end up proving less than perfectly optimal. (To clarify - I think we're making a good decision in #50.)

[jan-ivar]

Without the controls HTMLAudioElement attribute, the HTMLAudioElement is invisible as you've noted later in your answer

@beaufortfrancois right, I said: "Elements properties that control their visibility (e.g. controls) may change at any time".

So please answer this: should the presence or absence of the controls property at the time of minting affect whether minting fails?

[eladalon1983]

Without the controls HTMLAudioElement attribute, the HTMLAudioElement is invisible as you've noted later in your answer

@beaufortfrancois right, I said: "Elements properties that control their visibility (e.g. controls) may change at any time".

So please answer this: should the presence or absence of the controls property at the time of minting affect whether minting fails?

The visibility issue is a red herring - any Element can have 0 visible pixels if it's scrolled away from view. The real issue is explained here. (And to plainly answer your question - no, the presence/absence of controls is immaterial.)

[jan-ivar]

I think we should follow precedence set by element.requestFullscreen(). I see strong parallels between that API and cropTo: both APIs let a single element take over an entire viewport.

Here's what element.requestFullscreen() requires of this to not reject:

• This’s namespace is the HTML namespace or this is an SVG svg or MathML math element.
• This is not a dialog element.
• The fullscreen element ready check for this returns true.
  • element is connected.
  • element’s node document is allowed to use the "fullscreen" feature.

Type-wise this would suggest we should reject on dialog element, and non-HTML non-SVG non-MathML elements, and nothing else.

[eladalon1983]

The parallel drawn with requestFullscreen does indeed make some sense. But, still, I cannot easily imagine a real purpose for cropping to the bounding box of an HTMLAudioElement. Consider too that this is going to look different between different implementations. And consider how some implementations have a non-rectangular or partially-transparent HTMLAudioElement, which means pixels from background content will poke through.

Note: This is not the only case of non-rectangular or partially-transparent element. We've used the bounding box for a reason. But the special thing with HTMLAudioElement is that non-rectangularity and/or transparency is different between user agents, which means an application misguidedly trying to use it as a crop-target would yield non-uniform results. It's a footgun.

[eladalon1983]

Btw, I've tried calling requestFullscreen() on an audio element, and I was not impressed with the results.

See the controls at the bottom? Not terribly useful.

[eladalon1983]

The results on Firefox are even more interesting:

The controls are entire absent for some reason. Why's that?

[eladalon1983]

I also tried Safari. It turned out that requestFullscreen() does not exist there, but one can use webkitRequestFullscreen(). I wonder what the story is behind that. But possibly I should not digress.

[jan-ivar]

The controls are entire absent for some reason. Why's that?

Feel free to file a bug on Firefox, but can we agree this is irrelevant here? I've already shown the spec algorithm, and Chrome is compliant.

Btw, I've tried calling requestFullscreen() on an audio element, and I was not impressed with the results.

As you can see, it works. I think it's a good API. From a web developer's perspective:

• It's the least surprising result
• It says what it does and does what it says
• It doesn't restrict or convey judgement about whether what you're trying to accomplish is "sensible" or not
• It simplifies documentation (no need to mention what uses browser vendors consider sensible or not)
• It's more work on browser vendors to make it KISS for web developers (in line with the priority of constituencies)
• It's done (no need to maintain or update list of sensible use cases)

[eladalon1983]

but can we agree this is irrelevant here?

Bugs are irrelevant and transitory. But abiding incompatibilities such as elements looking completely different between implementations, up to and including capturing background pixels in some implementations but not in others... That is very relevant.

It doesn't restrict or convey judgement about whether what you're trying to accomplish is "sensible" or not

The difference is that with requestFullscreen(), at worst you get slightly silly behavior for the local user, whereas with cropping, you could be exposing a different set of pixels to remote participants, possibly unbeknownst to the local user.

It's more work on browser vendors to make it KISS for web developers

It's good and proper for browsers to pay for developers' lunch, but only if developers are going to eat it. Here, I think we'd be wasting time and effort on unrequested, undesired functionality, that no prudent developer would use. So far, developers seem to be happy with cropping to DIVs. We have expanded the scope all the way to Element rather speculatively.

[jan-ivar]

Consider too that this is going to look different between different implementations ... pixels from background content will poke through.

This seems like a red herring, because exposure of implementation-specific rendering is inherent with screen-capture and seems mostly orthogonal to cropping. I.e. we'd need to shut down screen capture entirely if this were an issue.

the special thing with HTMLAudioElement is that non-rectangularity and/or transparency is different between user agents, which means an application misguidedly trying to use it as a crop-target would yield non-uniform results. It's a footgun.

No more so than screen capture already is. We're not capturing the "element", we're capturing whatever CSS determines is rendered top-most at the pixel coordinates determined by the element's bounding rectangle, which may be pixels that have nothing to do with the element. So to speak of other rendering showing through behind round corners and calling that a "footgun" frankly has me worried about whether this API has received the scrutiny and vetting it deserves.

I also don't think it's accurate to say this is somehow unique to HTMLAudioElement. HTMLVideoElement with controls look different in different browsers as well, and corner shapes are like the wind, they change with the seasons.

[jan-ivar]

So far, developers seem to be happy with cropping to DIVs.

This is a brand new API, so I don't see how you can claim this. See also https://crbug.com/1328836 detailing my run-in with this limitation in Chrome, which required me to use CSS workarounds.

We have expanded the scope all the way to Element rather speculatively.

Who's "we" and where are you going with this? HTMLAudioElement is an HTMLElement.

[eladalon1983]

This seems like a red herring, because exposure of implementation-specific rendering is inherent with screen-capture and seems mostly orthogonal to cropping.

That's missing the point. The problem is not that the players look different generally-speaking. I don't mind if one implementation exposes the play button to the left of the scrubbar and other implementation to the right of it. The problem is that the players' opacity and shape is different in substantive ways. This implementation-specific shape is peculiar to HTMLAudioElement and perhaps a handful other Elements.

Consider a developer working with Firefox and Safari. They try to cropTo an audio element and they get only the player, which is rectangular and opaque. They're happy. They don't mind that the player is different in both cases. They ship it. Then it turns out that in Chrome, that still captured some background pixels. Oops! That's unfortunate.

Sure, the same problem would have been observed with a div-containing-a-player, if the player happened to obscure something. But that case makes it clearer to the developer that they're capturing "what's in the div" and not "the player". It's a lesser issue.

Who's "we" and where are you going with this?

We who participated in the discussion.
Where I'm going with this - towards excluding some Element subtypes.

[jan-ivar]

Sure, the same problem would have been observed with a div-containing-a-player, if the player happened to obscure something. But that case makes it clearer to the developer that they're capturing "what's in the div" and not "the player". It's a lesser issue.

No it is the exact same issue. I would like you to address what I already wrote on that so we don't go in circles:

"We're not capturing the "element", we're capturing whatever CSS determines is rendered top-most at the pixel coordinates determined by the element's bounding rectangle, which may be pixels that have nothing to do with the element. So to speak of other rendering showing through behind round corners and calling that a "footgun" frankly has me worried about whether this API has received the scrutiny and vetting it deserves."

If you're claiming the user somehow expects cropping to an "element" to somehow be safe from leaks of other information in the viewport (behind, around or on-top) or be anything other than a pixel-cropping operation of the viewport image, then we have an API fail, and we should change the API to make it clearer to web developers what the actual functionality exposed does and what it's side-effects are.

This implementation-specific shape is peculiar to HTMLAudioElement and perhaps a handful other Elements.

Lastly, web developers can already crop to any element using trial and error and pixel coordinates, which is more likely to produce surprising undesirable results across browsers: the cropping coordinates may appear fine in Chrome but cut off elements in say Firefox, or work some of the time but break at other times due to unforseen layout or language changes. Being able to specify an element would only improve the situation and the user agent's ability to include the necessary vendor-specific rendering.

[jan-ivar]

Where I'm going with this - towards excluding some Element subtypes.

This isn't clear from the issue you've filed. To not waste the WG's time, may I suggest filing a more precise issue explaining what the problem is?

[eladalon1983]

I would like you to address what I #51 (comment) so we don't go in circles

I believe I have addressed this multiple times during the past 1.5 years. "To not waste the WG's time", I don't intend to address these topics again. The API shape and its trade-offs should be clear by now. We are discussing whether improvements can be made around the edges, with some niche Element sybtypes being excluded from this API because they make no sense, are useless to implement, and won't be employed by any developer because of their unique idiosyncracies.

Lastly, web developers can already crop to any element using trial and error and pixel coordinates,

That is not robust to resizing, which is a major reason why we even have Region Capture - as you should know. I don't see how this is relevant to our present discussion.

[By @jan-ivar] where are you going with this?

[By @eladalon1983] Where I'm going with this - towards excluding some Element subtypes.

[By @jan-ivar] This isn't clear from the issue you've filed. To not waste the WG's time, may I suggest filing a more precise issue explaining what the problem is?

This would be the second time you ask me to branch this particular discussion. Actually, third time we do it. And frankly? I can't begin to imagine how my intent is not clear from the original issue. I think the way to show respect for this WG's time is to carefully read messages before responding to them, to be mindful of context, and to drive this discussion to completion without additional distractions.

[eladalon1983]

Here's a possible compromise. Instead of blocklists, let's employ allowlists. For the time being, let's redefine CropTarget.fromElement() as accepting (HTMLDivElement or HTMLIFrameElement). This can be expanded later. Wdys, @youennf, @jan-ivar? It's the opposite direction than what Youenn previously suggested, but we can always move back in the original direction later (more/all subtypes). Let's lock in the gains and proceed with the controversial subtypes later.

[jan-ivar]

Here's a possible compromise. ... redefine CropTarget.fromElement() as accepting (HTMLDivElement or HTMLIFrameElement)

@eladalon1983 between what positions would that be a compromise?

I can't begin to imagine how my intent is not clear from the original issue.

What elements do you mean when you say "elements like HTMLAudioElement?" Do you include HTMLVideoElement? If so I would not have guessed that from the OP. @youennf also said: "I have difficulties following what we are trying to discuss here", which is why I suggested opening a fresh issue describing the problem anew. He proceeded to say/ask you:

It seems what we are after here is something different, maybe scoping the spec down to only supporting div/iframe (?).
This is a different discussion that we can certainly have.

Is having that discussion here your intent? I see no direct response from you to that statement/question.

What I asked was - is it "sensible" to support HTMLAudioElement?

Yes it's sensible and has consensus, which means I don't have to defend it (even though I did), rather people who want to make a change have to explain why it's not sensible.

To help clarify, do you think it is sensible to support HTMLVideoElement?

[eladalon1983]

Clarification: All Elements are eligible to cropping based on the current definition in the spec - which I am arguing we should amend, because not all Element subtypes make sensible crop-targets. We started this discussion when I said that we should allow user agents to reject crop-minting for three categories of reasons. The three categories were laid out here, before you (@jan-ivar) insisted on branching the discussion. The present issue was created to discuss the first category - "Elements like HTMLAudioElement". I have been arguing for a while that we should allow user agents to reject these Elements. Is this clear now?

What elements do you mean when you say "elements like HTMLAudioElement?" Do you include HTMLVideoElement?
...
To help clarify, do you think it is sensible to support HTMLVideoElement?

If this part were unclear before, you could have asked. @dontcallmedom, could you please help ensure the W3C does not devolve into 4Chan? It is quite inappropriate to claim that I am wasting the WG's time when I fail to answer a question that was never posed.

To answer @jan-ivar's new question - I think HTMLVideoElement makes a relatively sensible crop-target and I don't presently seek to pack it in the same bin with HTMLAudioElement. I can start compiling a list of such subtypes after we decide what to do with HTMLAudioElement. The guiding principle is that Elements whose shape is not sufficiently constant between implementations do not make for sensible targets, because they don't produce a definition of a target area that is constant between implementations, or even different versions of a given implementation.

Is having that discussion here your intent?

My intent is to find partners who are honestly engaged in having the discussion and following it wherever it naturally goes. If this means scoping back down to div/iframe, as Youenn and I have both now suggested ([1][2]), then that works for me too. Are you interested in this compromise, @jan-ivar? Yes or no?

Yes it's sensible and has consensus

I don't see how it helps anyone to claim "consensus" when one of three parties engaged in this discussion tells you they want to change things. It would make more sense to call this the "status quo".

rather people who want to make a change have to explain why it's not sensible.

Which I have.

[youennf]

I am still puzzled by what we are discussing here. Can somebody summarise the various proposals?

A few thoughts:

• Chrome can certainly ship a partial implementation without any spec change. It often happens that implementations start with low hanging fruits and go to completion after some time. I thought this was Chrome team plan.
• Specs define the end goal. At some point, if the end goal is not reached or not reachable, we need to have a discussion to align the spec with what implementations have been/will be able to achieve. We are at the start of the cycle. The current end goal (Element) seems good to me.
• Learning from fullscreen API is a good idea. This was one reason I was in favor of supporting Element and not HTMLElement like initially proposed.
• Doing implementation prioritisation of an element type (HTMLVideoElement) over another (HTMLAudioElement) is a UA implementation decision, I do not see why we should discuss this here. The question we can ask here is whether we want to support HTMLAudioElement or not. So far, I have not seen any reason why we should remove support. It can have some very good uses (say reporting a bug about A/V synchronization and doing an A/V capture to help diagnose the issue). If it is very hard to implement correctly, we can always discuss this.

If this means scoping back down to div/iframe, as Youenn and I have both now suggested ([1][2]), then that works for me too.

To be clear, I am not proposing that.
I asked whether this is what Chrome team wanted/what this discussion was about and I am still not sure whether this is the case or not. Again, as I asked earlier:
Does Chrome team want to reduce the scope of the spec/proposal to div/iframe only?

@youennf, you have previously agreed HTMLElement made sense, and at your suggestion, we even expanded to Element. You made this suggestion five months ago. The API as a whole has been debated for 1.5 years by now. I do not think this qualifies as "rushed".

Please reread the sentence where I used "rush".
It was referring to the API shape change we are trying to get consensus on.
Normally, we would present it at a WG interim meeting and then let editors finalise the PR.
There is a request to bypass WG interim meeting and land this PR asap so that Chrome can align its implementation with that proposal before shipping it. This qualifies as "rushed", especially since we now seem to be discussing changing the scope of the spec.

With regards to the overall discussion, here is a rough sketch:

• 1.5 year ago, Chrome team made a proposal. At the time, the end goal was to support HTMLElement.
• 0.5 year ago, I proposed to extend it to Element, so that SVG/MathML could be supported. This is current WG consensus and we continued API discussions based on that consensus.
• Chrome team is now (maybe, I am not sure) proposing to revert these decisions and scope it down to div and iframe only. This happens at the same time we are trying to change the API while Chrome team is trying to ship a first version of this API. This is not great timing.

[eladalon1983]

I am still puzzled by what we are discussing here. Can somebody summarise the various proposals?

I'll summarize again. Note that if you want to know what I am trying to discuss, it helps to focus on what I am saying, and not confuse my choice of topic with my responses to off-topic questions. See more on this below.

The general topic is that minting can fail - but at your request this discussion was branched. There are three categories for these failures. The current issue discusses why I think minting should fail (synchronously) for HTMLAudioElement. The solution initially proposed was to allow the call to fail. Later, I reacted to your mention of reversion to iframe/div and mentioned it's a potential compromise.

Specs define the end goal.

This refers specifically to the other topic - criterion 2 of this message. You have asked me to branch the discussion off from there so as to keep these topics separate. So let's please observe your request - both of us.

Learning from fullscreen API is a good idea.

Please read this reply, which responded to the comparison with the fullscreen API. HTMLAudioElement means a different set of background pixels would be captured when comparing different implementations, and that's undesirable.

Doing implementation prioritisation of an element type ... I do not see why we should discuss this here.

That's NOT what was being discussed. I have never discussed HTMLVideoElement except in response to Jan-Ivar's queries on the topic - and specifically to say: "To answer @jan-ivar's new question - I think HTMLVideoElement makes a relatively sensible crop-target and I don't presently seek to pack it in the same bin with HTMLAudioElement."

If this means scoping back down to div/iframe, as Youenn and I have both now suggested ([1][2]), then that works for me too.

To be clear, I am not proposing that.
...
Does Chrome team want to reduce the scope of the spec/proposal to div/iframe only?

Thank you for the clarification. This reversion to div/iframe was NOT the original intention of this thread, but it DOES provide a shortcut out of this issue, and I'd love it if we took it.

Chrome team is now (maybe, I am not sure) proposing to revert these decisions and scope it down to div and iframe

I believed you were floating the idea as a possible compromise; possibly temporary.

Normally, we would present it at a WG interim meeting and then let editors finalise the PR.

All of the people who have expressed interest in this API during WG interim meetings are represented here. Continuing the discussion in 20min-per-month slots during interim meetings does not serve us.

[youennf]

The current issue discusses why I think minting should fail (synchronously) for HTMLAudioElement.

OK, let's focus on this issue specifically then and if we want to discuss other issues, let's have separate issues.

AIUI, you want the spec to state that creation of CropTarget for HTMLAudioElement should fail synchronously.
This is the proposal you want to move forward here.

Chrome team is now (maybe, I am not sure) proposing to revert these decisions and scope it down to div and iframe

I believed you were floating the idea as a possible compromise; possibly temporary.

I floated this idea to understand what was Chrome team request.

Please read this reply, which responded to the comparison with the fullscreen API. HTMLAudioElement means a different set of background pixels would be captured when comparing different implementations, and that's undesirable.

I do not think this invalidates the point that fullscreen API is a good source of information for designing media capture region.
Some APIs allow web sites to focus user attention to an HTMLAudioElement. One way is the fullscreen API.
Another way might be cropping the view port on the HTMLAudioElement.

As I said earlier, I could see some use of cropping to an HTMLAudioElement. This might not be the most widespread use of it but why should the spec forbid it?

AIUI, your argument for forbidding it is about HTMLAudioElement opacity.
I do not see how this has impact on the bounding box computation, which is what CropTarget is all about.
My guess (from what you are saying) is that implementing HTMLAudioElement cropping is difficult in Chrome's implementation.
Is that correct or are there other arguments?

[eladalon1983]

OK, let's focus on this issue specifically then and if we want to discuss other issues, let's have separate issues.

I have focused on this topic exclusively in this issue here. I would appreciate it if you could point out where this was ambiguous in my comments. (Note: My responses to others' off-topic messages do not count as me being off-topic myself.)

AIUI, you want the spec to state that creation of CropTarget for HTMLAudioElement should fail synchronously.
This is the proposal you want to move forward here.

You understand correctly.

I do not think this invalidates the point that fullscreen API is a good source of information for designing media capture region.

I too think that the fullscreen API is a good source of information. As soon as Jan-Ivar brought it up, I went out and examined its specification as well as implementation - as covered in my previous comments. What I found was that:

1. Most important - there are substantive differences between the two APIs which mean we cannot apply them identically. This has been explained in previous comments.
2. Less important - the fullscreen API is inconsistently implemented. I argue that this is NOT just a bug. It's indicative of how HTMLAudioElement is an uninteresting target for the fullscreen API and is rightfully prioritized too low to fix. It's similarly uninteresting as a crop-target.
3. Interestingly, HTMLScriptElement is a valid target for the fullscreen API! So I think a few design decisions were made there that I would not want to replicate.

As I said earlier, I could see some use of cropping to an HTMLAudioElement. This might not be the most widespread use of it but why should the spec forbid it?

As stated in my previous messages, the main reason is that it makes for a poor crop-target. It's a footgun. (Because of the inherent, non-cross-compat shape differences.)

AIUI, your argument for forbidding it is about HTMLAudioElement opacity.
I do not see how this has impact on the bounding box computation, which is what CropTarget is all about.

That the definition of a bounding box yields is meaningful does not mean it's useful.

My guess (from what you are saying) is that implementing HTMLAudioElement cropping is difficult in Chrome's implementation.

I have no reason to suspect that it's difficult in Chrome's implementation.

Is that correct or are there other arguments?

What about HTMLScriptElement? Is this a clearer example of why some subtypes don't make sense?

[jan-ivar]

The current issue discusses why I think minting should fail (synchronously) for HTMLAudioElement.

OK, let's focus on this issue specifically then and if we want to discuss other issues, let's have separate issues.

I have focused on this topic exclusively in this issue here. I would appreciate it if you could point out where this was ambiguous in my comments.

I'd be happy to:

• The subject is not "What should the spec say about HTMLAudioElement?" but "What should the spec say about elements like HTMLAudioElement?" (your OP edit similarly says "elements such as HTMLAudioElement.")

This appears to directly contradict your statement above that you've "focused on [HTMLAudioElement] exclusively in this issue", since you filed this issue and wrote the OP about a category of elements.

"Elements like..." implies a category X of elements of which HTMLAudioElement is a part. But it's ambiguous what the criteria for category X are, which means it's ambiguous what criteria are being proposed to be enshrined in the spec, and what criteria are being used to justify it.

I took a stab at the criteria being: no visual component, as did @youennf and even @beaufortfrancois it looks like judging by engagement to my rebuttal showing HTMLAudioElement does have a visual component at times.

After conceding this, you then said visibility was not the criteria for what was "sensible", and linked to:

• The OP, whose only definition of what's "sensible" appears to be its reference to "In an out-of-band chat with Harald, he has raised the interesting point of HTMLAudioElement and similar elements. In other words, some elements simply do not make sense as crop-targets."

In other words, you seem to be relying on @alvestrand's definition. I asked @alvestrand today at our co-chair meeting, and he confirmed he thought cropping to an HTMLAudioElement didn't make sense because it didn't have a visual component.

This would appear to support the view of others that visibility was the original criteria, and that you misunderstood Harald. Of course it's fine for you and Harald to have different reasons, but to others it is demonstrably ambiguous what you mean, since the only person you quoted used a different definition from yours.

Your summarized criteria for what is "sensible" appears to be "Web-developers don't need it" as determined by you. Not only is this subjective and impractical — short of running every element type by you, this amounts to a highly ambiguous definition of what is sensible and what is not — But it's also surprisingly narrow: You said "we'd be wasting time and effort on unrequested, undesired functionality, that no prudent developer would use. So far, developers seem to be happy with cropping to DIVs". Here it seems like you're saying only DIVs are sensible? This appears to contradict your earlier statement that HTMLVideoElement was sensible, and ALSO your statement here that this is only about HTMLAudioElement.

Based on these points which you've asked me to call out, I would say your position is far from clear, and that people who call this out are not in error.

I would ask we not make claims about what makes sense or not without backing such claims up with arguments and facts that can be debated. I would also ask we limit debate to those arguments regardless of who makes them. This should save a lot of time.

[eladalon1983]

This appears to directly contradict your statement above

This new confusion is unrelated to that in Youenn's second bulletpoint of this message, where he goes back to discussing the second bulletpoint of this message. But, at any rate, "and similar elements" was featured in almost all of my messages. The one time it was missing - that was an unintended outlier. Please read that too as "and similar elements."

I took a stab at the criteria being: no visual component

If you thought I used HTMLAudioElement solely because of a supposed mistaken notion of it being always-invisible, then why didn't you just respond that HTMLScriptElement or HTMLBrElement or HTMLSomeOtherElement would be a better example? That would have been a lot more productive.

This would appear to support the view of others that visibility was the original criteria, and that you misunderstood Harald.

Please don't attempt to read my mind. My first message did not mention visibility. My second message demonstrates full awareness that HTMLAudioElement can be visible. It is patently obvious that, as of 2022-05-27, we all knew HTMLAudioElement could be visible. Let's proceed.

this amounts to a highly ambiguous definition of what is sensible and what is not

I'll give an objective definition of valid crop-target-element-types in my next comment (for better visibility).

Here it seems like you're saying only DIVs are sensible?

I said they were sufficient. This allows us to compromise on specifying them first, and expanding the definition later.

[eladalon1983]

Here is my proposed first draft of definition for which Element subtypes should be allowed.

The Element-subtype is associated with a non-null, well-defined subsection of the viewport.
To be well-defined, both the size and opacity must be sufficiently specified.

Note:

• This refer Element's subtype. It does not matter if the specific instance is outside the viewport at the moment of minting.
• By "sufficiently specified" I seek to ensure that the developer gets as close to what he's asked for as possible, cross-platform. The limitations are discussed in this message (search for "div-containing-a-player").

I would have liked to include sensibility/usefulness, but I agree that it would be difficult to define, so let's shelve that for now.

If (i) a non-null bounding box is easier to reach consensus on than (ii) well-defined size and opacity, then we can start with (i) and get back to (ii) later.

[dontcallmedom]

Since CSS can be used to make any element (including <script>) part of the viewport, I'm not sure we can define ex-ante a subtype of elements that can't be in such a state?

[eladalon1983]

Since CSS can be used to make any element (including <script>) part of the viewport

I was not aware of that. Could you please explain how?

[dontcallmedom]

for instance

<html>
  <style>script {display: block; font-family: monospace; }</style>
  <body>
    <div id="log"></div>
    <script>
      document.getElementById("log").textContent = "This page displays the script that controls it";
      </script>

(visible in https://jsfiddle.net/wuardx8k/, although it seems to show more of the script there because of jsfiddle specific code)

[eladalon1983]

That's interesting, I did not know you could do that to <script>. But does it really work for any Element? I tried playing around with <head> and <title> and that did not produce an observable result. I am not sure what I'd see with <br>, either...?

[dontcallmedom]

https://jsfiddle.net/ze0q1sk7/ shows an example where title and br gets rendered on the viewport. (the latter works in Chrome but not in Firefox - I haven't investigated why)

[eladalon1983]

Thanks, Dom. That was news to me - that all Elements can be made visible. If that's indeed the case for all Elements, it might be best to close this discussion. I still think part (ii) here could be interesting, but (i) would have been more interesting and compelling, and I see nobody else has much concern about (ii).

--
Btw, for posterity - turns out that the title is only visible if both it as well as the head are set to display: block. I learned that from Dom's fiddle.