Organizing Web APIs

[gabejohnson]

I'm opening this issue to discuss how to organize the various web APIs in this project. Here's a tentative list. Please comment w/ suggestions for additions/changes.

Communications:

• XHR
• Fetch
• WebSockets
• WebRTC

Processes (things with which you can postMessage):

• Other windows
• Workers
• MessageChannels
• SharedArrayBuffer (if re-enabled)
• Atomics (if re-enabled)

DOM:

• Event
• EventTarget:
  • Window
  • IFrame
  • HTML
  • XML
  • SVG
  • Canvas
• TreeWalker

Browser:

• Navigator

Graphics:

• Canvas 2D
• WebGL

Animation (https://developer.mozilla.org/en-US/docs/Web/API/Web_Animations_API):

• CSS Animations
• Element#animate
• Document#timeline
• etc.

Storage:

• LocalStorage
• SessionStorage
• IndexedDB

Files:

• Blob and descendants

Audio

Video

Devices (listed under "Hardware access APIs" at https://developer.mozilla.org/en-US/docs/WebAPI):

The intention is not to have a library for each of these categories but, more likely, to have a library for each item (there could be a common library libs for interfaces/superclasses like Event).

[garyb]

Re: EventTarget, those things don't need to be included in the library with it, as we can provide toEventTarget functions in locations that the types are defined instead. For example: https://github.com/purescript-web/purescript-web-file/blob/compiler/0.12/src/Web/File/FileReader.purs#L26

Currently I've split purescript-web-dom to consist of the interfaces defined in the DOM4 spec, so that means Node, Element, Document, etc. along with Event, CustomEvent, EventTarget.

purescript-web-file has Blob, File and FileReader stuff, so it's mostly splitting out the way suggested here already 😄

I'm not too sure where the CSSOM bits we currently have should fit, I was thinking they'd go in purescript-web-html too, but perhaps we should create a purescript-web-css for that, since there is a bunch more to that spec that we could implement.

[gabejohnson]

Re: EventTarget, those things don't need to be included in the library with it...

The intention is not to have a library for each of these categories but, more likely, to have a library for each item

I should have said "for each item or subitem".