Editorial: cleanup postMessage() invocation for dedicated workers

[annevk]

Instead of language such as

The postMessage(message, transfer) and postMessage(message, options) methods on Worker objects act as if, when invoked, they immediately invoked the respective postMessage(message, transfer) and postMessage(message, options) on the port, with the same arguments, and returned the same return value.

which we use for both Worker and DedicatedWorkerGlobalScope we should use a shared abstract operation so that we don't invoke a public API.

[acharyasourav]

Hey, @annevk I would like to work on this can you please elaborate on what needs to be done? Also, where should I start looking?

[foxzhang1224]

Hi, @annevk I looked into the code and wonder if we adjust the code of /Users/foxzhang/html/source

particularly those that are associated with

suffering from an overflow

would that resolve the logic/frontend issue with postMessage()?

since the removal class of class can keep the Bikeshed/HTML source readable

[kritikaat]

Hi @annevk, I would like to work on this issue!

I’ve read through the description and understand that the goal is to introduce a shared abstract operation for the postMessage() behavior on Worker and DedicatedWorkerGlobalScope, so we avoid directly invoking the public API in the spec text.

I plan to:
Identify the repeated sections in the Bikeshed source
Create an abstract operation following the existing spec style
Update both postMessage() references to use this shared operation
Test and ensure the spec still builds correctly

Please let me know if you have any extra suggestions or guidance before I start!

[annevk]

No, that's all you need to do. And in the future there's no need to leave a comment on an issue either. All we need is a PR. 😊