Add missing Element-Attr API functions, add Attr type.

[manpages]

This commit also adds natively-typed API to work with attributes.

Notice that here we also take a liberty of explicitly marking legacy and
nonsense-fields of Attr IDL as legacy instead of IDL names of those.

Again, a ridiculously stupid, yet somewhat complete test suite is attached to PR.

I don't expect this PR to get merged right away, instead I'd like to hear
opinions regarding what to do with this code and Attr API.

[garyb]

I'm not sure Attr should be a record type synonym, as giving it field accessors this way doesn't encapsulate the fact that value is mutable, and also it suggests you can "make" Attr values by just using a normal record, which isn't the case.

My original thought was to just have foreign import data Attr :: * as with all the the other types, and then implement a bunch of functions for reading localName, name, namespaceURI, prefix of the form Attr -> whatever, value :: forall eff. Eff (dom :: DOM | eff) (Nullable String) and setValue :: blah.

[garyb]

This is defined as (*>) in Control.Applicative - no need for (>>) in PureScript as Applicative is a superclass of Monad.

[manpages]

Old habits die hard.

[manpages]

My original thought was to just have foreign import data Attr :: *

I like this approach and will implement it, test and force-push.

[manpages]

I'm confused though, quoting IRC —

| garyb: just to clarify. You propose we interface with createAttribute method in order to make an instance of Attr?
| I'm incompetent in the state of Attrs throughout the history of DOM.
| Also, createAttribute reutrns (used to return) AttributeNode...
| But I agree that my API is absolutely terrible.

[garyb]

I'm also not totally up on the DOM and previous versions either, so I'm just trying to stick to whatever the IDLs say in the DOM 4 draft really... it looks like there is no way of instantiating an Attr directly in the current draft - Attr values can be obtained through the attributes collection on an Element.

I appreciate the contribution, but since I'm being so picky about this would you rather I just did it instead?

[garyb]

I wouldn't say your API is terrible either 😉 I just have specific ideas about how this library should be built, to keep it as unopinionated as possible while providing typed access to the DOM API.

That does make it more user unfriendly than normal libraries, but this is supposed to be a starting point to build useful libraries on top of while providing a set of common types that they can share, and prevent the need of resorting to writing code in the FFI for their implementations.