I would still like to move this code to a module of its own.
It's distinct from the rest and easy to separate. I hope you can agree with this.

Of course!
more mular = more good ;-)

@wimrijnders Just to make it clear: All existing options and settings are still the same and function like documented? Than I see no reason not to finalise your big code cleanup...

Thanks. Settings module on my TODO.

Yes, confirm: all existing options and settings are identical to previous. For the (external) user there is no difference. This was an internal restructuring.

mular - It's a typo, but I think we need to give it a definition and make it a standard term.
(sorry couldn't resist)

I see this PR is still open; I'll add the changes for creating the Settings module here, OK? I hope that was your intention as well.

Sounds good

OK done with Settings module. No more changes for this PR, you can merge if you approve.

Moving the settings code to a module was a straightforward translation, with the following exceptions:

• I really like having DEFAULTS on the top of Graph3d.js. So Settings.js just stores a reference to it.
• Partly because of previous, I added some extra parameter checking. Scan for isEmpty() in Settings.js.
• I had to make a choice where to put enum STYLE; I put it in Settings.js because this makes easier handling.
• Also moved the style names to Settings.js; reworked it to a hash, renamed _getStyleNumber() to getStyleNumberByName().