Transferrable subfeatures should have an underscore

[foolip]

https://github.com/mdn/browser-compat-data/pull/16281 and https://github.com/mdn/browser-compat-data/pull/16525 added subfeatures for whether objects are transferrable, but can't be distinguished from features that would mean the presence of a transferrable property or method.

Not sure what a good name and description would be at this point, so filing this issue.

cc @sideshowbarker @hamishwillee @queengooborg

[queengooborg]

+1 for this, and we should probably have a guideline as well.

[hamishwillee]

@foolip I'm not sure understand what you're saying. Is it that we can indicate that a "whole" feature is transferrable, but not a particular property or method is transferrable?

I didn't think any method was transferrable.

Do we need to separate transferrable and serializable? A case that came up a week or so ago is the Error.stack is now serializable, which is in effect the same kind of problem - a part of an object can now be cloned/posted, but not the whole thing.

[hamishwillee]

All that said, why can't the transferrable markup applicable to a subfeature just be in that subfeature - is it just because we render the table "flat"?

[queengooborg]

@hamishwillee, this issue is actually in regards to the name of the subfeature, rather than its existence or placement. We have a transferrable subfeature throughout BCD, the name should have an underscore in it to indicate that it is a behavioral feature rather than a property or method (we use underscores in feature names to determine that). Additionally, if an API adds a transferrable property/method, it would conflict with the existing property we use to determine the interface/property is transferrable. (I don't think any browser or spec will do so to prevent confusion, but then again static properties with matching names are allowed now, so...)

Do we need to separate transferrable and serializable?

I don't know enough to properly comment on this, but I think they're different, if slightly?

[hamishwillee]

Thank you for the clarification.

Do we need to separate transferrable and serializable?

I don't know enough to properly comment on this, but I think they're different, if slightly?

They are very different "thangs" but have considerable overlap in the application.

Essentially if something is serializable it means that you put it into a realm-agnostic format, store it, copy it, send it somewhere else, and recover it (almost, in JavaScript you don't have to serialize every bit of something to necessarily decide it is "serializable").

Transferrable basically means that sometimes when you're copying or sending something (postMessage or structuredClone()) rather than duplicating the thing you can choose to transfer ownership. There is still just one thing - it just moves to the new domain or object, and the old one can't be used. For example, big fat memory buffers are usually transferred to write into in a worker, and then transferred back. YOu could serialize those, but there would be a lot of inefficiency.

The list

• Serializable objects: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#supported_types
• Transferrable objects: https://developer.mozilla.org/en-US/docs/Glossary/Transferable_objects#supported_objects

The two definitions are here:

• https://developer.mozilla.org/en-US/docs/Glossary/Serializable_object
• https://developer.mozilla.org/en-US/docs/Glossary/Transferable_objects