I looked at this with @ylafon in our TAG VF2F breakout

We think the feature is fine and understand your reasoning why this is not an event etc as detailed in the explainer.

We don't like the name. It sounds like the current event now has an entry that was earlier dropped - hasDroppedEntry (could be understood like, has one entry that was dropped). Also we would assume that more than one entry were dropped (entriesWereDropped?)

What about something like hasBufferOverflow or something similar?

Yea that works for me as well, @yoavweiss any thoughts on hasBufferOverflow? We can also present this option in the next call. Honestly naming is hard and we didn't come up with a better name at that call.

A dump of other naming ideas:

• isFull - No, because it needs to reflect past state.
• wasFull - No, because being full is fine. The state we communicate is not reaching the limit, but going over the limit and thus having dropped and missed out on one or more entires.
• bufferOverflow - No, because it needs to reflect past state.
• bufferOverflowed - Maybe, but feels awkward, and I think the last two chars would be too easily ignored or read over and thus not communicating that it is a past state.
• hasBufferOverflow - Maybe, but I think we want past-tense? (per @npm1).
• hadBufferOverflow - Maybe, and is grammatically fine if you interpret "buffer overflow" as a noun - the happening of the overflow. If you intepret it as a verb, then "had [its] buffer overflow" could still be fine, but is stretching it. If we see it as a verb it would probably need to be "has [the] buffer overflown", "had an overflowed buffer", or "did [the] buffer overflow".
• didBufferOverflow - Maybe.
• wasBufferOverflown – Maybe, but feels awkward.
• wasBufferOverflow – Maybe, but feels awkward also.

I have a slight preference toward "has" as it is common and familiar in other boolean interfaces in (Web) APIs. But, admitedly those APIs are about actual possessive nouns like hasChildNodes, hasFeature, and of course hasOwnProperty. While "to have" is grammatically versatile and may be used far beyond simple nouns that belong to something, it is not ideal and can be especially confusing for ESL learners. Also, we couldn't actually use "has", we'd need "had" which I don't think I've seen before in a Web API.

Using "is" or "was" for this boolean state feels more natural, I think, and both of those prefixes exist in Web APIs. It's just that.. I can't think of a name that uses "was" and isn't awkward or incorrect. Any other ideas?

So it is basically an incomplete series of entries. Is this the only reason this can happen?

.incomplete?

This was discussed a bit in the WebPerf WG and we heard some concern that hasBufferOverflow sounds too close to a buffer overflow so perhaps not the best naming. Regarding full, it seems a bit inaccurate since the bool should be true when the buffer became full but also an entry was created after that (hence the buffer lost/dropped an entry). And I think incomplete sounds pretty cryptic to me: what's incomplete? Note that the callback will have true anytime in the future after the first callback was true since the bool is answering the question: "does there exist an entry that was not added to the buffer because it was full"?

What about wasEntryDropped?

I like wasEntryDropped. If we want to imply potentially more than one, perhaps wereEntriesDropped could work as well.

If we want to remain specific to the current through the buffer (as opposed to other future causes), perhaps wasBufferExceeded or wasLimitExceeded could work as well.

The benefit would be that it provides a strong signal about what is happening to the buffer, and could be used to convey other side-effects as result of this. The downside, naturally, is that we could not use it when other causes may be introduced that may lead to entries being dropped.

wereEntriesDropped sounds like a question. didDropEntries or entriesWereDropped sounds better

Adding @alice about naming

Ping, would love to hear your thoughts on naming so we can find the bestest name!

Picking this up in our virtual f2f just now. Apologies for the delay @npm1.

As a meta-note, thank you for filling out the security & privacy questionnaire and providing thoughtful resposnses.

@kenchris, @torgo, @rhiaro and I discussed this in our VF2F breakout today. Here is our feedback:

• It may be good to prefer a dictionary over adding a positional primitive argument, in line with Principle 5.3. While some of the reasoning behind this principle doesn't apply here (since this callback is only called by the UA), a dictionary would allow communicating more information to the callback in the future, without introducing a long list of positional arguments that need to be backfilled.
• We wondered if it would be more in line with your listed goals to report the number of dropped entries, so appropriate optimizations can be made. E.g. the need for buffer adjustments is higher when there are thousands of dropped entries compared to a couple. We also wondered if it would assist in reducing the number of dropped entries if developers could set the buffer size via an observe() parameter.
• A little of the discussion revolved around naming. If this changes to communicate number of dropped entries, it could change to e.g. droppedEntries. The word truncated could also be useful in coming up with alternative composite names.

Thanks for the feedback! I have sent a PR because I agree with the feedback so I've made the changes suggested. In the PR I'm using numDroppedEntries for the name.

We discussed this in our breakout today and think this is shaping up nicely! One minor concern raised was related to the name of the property (numDroppedEntries), which includes an abbreviation that has little precedent in the rest of the Web Platform. We think that, if possible, a non-abbreviated name might work better (e.g. droppedEntriesCount). Note that *Count names do have precedent in the Web Platform.

A few other examples (from a quick search):

animation-iteration-count and column-count in CSS ParentNode.childElementCount and MediaTrackConstraints.channelCount in DOM

I found nothing starting with num*

Good to know! I will incorporate the suggested name droppedEntriesCount in the PR shortly.

Fantastic - thanks for filing this review. We're going to close this off but let us know if we can be of any more help. ✨