Summary

  • A 2013 W3C standards discussion asked for a way to broadcast to same-origin contexts. A 2014 issue expanded the design to workers; a 2015 public WHATWG exchange recorded implementation interest.
  • The current HTML Standard defines named BroadcastChannel objects. The browser serializes a posted message and queues it for other eligible objects with the same name and storage key; each receiving page decides what to do.

The reader closes a session in tab A. Tab B is displaying a saved-story list; tab C is halfway through an account page. If each tab learns of the change only when it next asks the server, the desk becomes a tiny museum of yesterday's state. A site's windows needed a way to pass a note across the desk without first appointing one tab as office manager. The note might say “logout.” It still takes application code in each tab to change what readers see.

The W3C public issue opened in 2013 preserves the design conversation. Participants sketched a constructible object with a channel name and a postMessage() method, sending to other listeners under a matching origin and name. The comments include alternatives and rough edges; they are a workshop record, with the browser proposed as dispatcher. The important shape was already there: independent pages could subscribe to the same named conversation without handing each other window references.

The workshop widened. A W3C issue filed in January 2014 asked that workers join the conversation. Its June update records the change in the HTML work. A background worker might keep a publication's local tasks moving while tabs come and go; letting it receive the same named message spared the page from inventing a second delivery path. The 2013 idea was crossing the boundary between open windows and their offstage colleagues.

By January 2015, a public WHATWG mailing-list exchange discussed an implementation headed into Firefox Nightly and pointed to the HTML specification. The W3C HTML 5.1 Working Draft index of October 2015 listed BroadcastChannel among the relevant interfaces and linked its definition to WHATWG. These are dated signs of specification and implementation work, not a census of readers' browsers.

The current HTML Standard makes the courier's route explicit. A channel has a name. postMessage() serializes the data and finds other eligible channels with that name and the same storage key. The source object is removed from the recipients. The browser queues a message event for each destination. A window must have a fully active document; a worker must still be eligible. A tab across a different storage partition will stand in another building, however familiar its sign may look.

The standard even gives the desk a scene: when a user logs out in one tab, a channel named for authentication informs another tab, which updates its own view. The message travels locally; the app still performs the logout and presents its result. A named channel handles distribution, while each recipient chooses its response. That is a useful division of labor for account state, a theme switch or a work queue that several open views need to notice.

There is one final office habit in the standard: close a channel when the conversation is over. A channel left with a message listener can remain reachable and consume resources. The intercom is convenient, but leaving every handset off the hook is a poor maintenance plan. The browser's little dispatch room solved a real coordination problem; the application has to treat its messages as events with a life, not as magic shared memory.