NOTE: All of the following examples should be considered prototypes, as they contain the bare minimum of error catching.
I would break down your request into two parts:
1. How to handle User Custom Settings on the current web-browser.
I would use the Setting API to handle that as it allows you to add Toggles and Lists to the built-in Settings Dialog, and the state of these settings are automatically persisted in the current web-browser's local storage.
eg. If you implement the widescreen based handler & addToggle() call examples from the Setting.addToggle documentation within your story's Story Javascript area, and add the following CSS to your story's Story Stylesheet area:
html.widescreen {
background-color: green;
}
... then Play the story and select the Settings button in the left side bar you should see a new toggle option, and using that option should result in the background colour instantly changing each time you toggle it.
Obviously you would want to implement other settings than the widescreen example but the principle is the same.
2. Allow the Use to transfer their Custom Settings between web-browsers.
There are (at least) two potential ways you can use the built-in Save API to handle the persistence of this data, both of these ways make use of the Config.saves.onSave handler & the Config.saves.onLoad handler and the related save object's metadata property.
WARNING: One issue with using the onSave / onLoad event handlers is that they are called for both the Slot based functionality as well as the Disk based, and the only semi-reliable means I could find to differentiate between the two types of Save/Loading was that the save object passed to the Slot based functionality included a title property where as the Disk based functionality didn't.
2a. Persisting/restoring the Custom Settings data during the Save to Disk and the Load From Disk processes.
The following Javascript example demonstrates how to persist & restore the current state of the above widescreen setting within the save object's metadata property, using this method means that the state of the custom settings will not change when a Slot is loaded.
Config.saves.onSave = function (save) {
/* WARNING: The following method of testing for the "Save to Disk"
* onSave event is extremely brittle and could fail for future versions
* of SugarCube 2.
*/
if (! save.title) {
save.metadata = {'widescreen' : settings.widescreen};
}
};
Config.saves.onLoad = function (save) {
/* WARNING: The following method of testing for the "Load from Disk"
* onLoad event is extremely brittle and could fail for future versions
* of SugarCube 2.
*/
if (! save.title) {
settings.widescreen = ((save.metadata) ? save.metadata.widescreen : false);
settingWidescreenHandler();
}
};
... notice the call to the settingWidescreenHandler() handler defined previously, this is needed to simulate the toggling of the related option.
2b. Persisting/restoring the Custom Settings data during the Slot Save and the Slot Load processes.
Using this method means that loading a Slot could potentially change the current state of the custom settings.
Config.saves.onSave = function (save) {
/* WARNING: The following method of testing for the "Slot Save"
* onSave event is extremely brittle and could fail for future
* versions of SugarCube 2.
*/
if (save.title) {
save.metadata = {'widescreen' : settings.widescreen};
}
};
Config.saves.onLoad = function (save) {
/* WARNING: The following method of testing for the "Slot Load"
* onLoad event is extremely brittle and could fail for future
* versions of SugarCube 2.
*/
if (save.title) {
settings.widescreen = ((save.metadata) ? save.metadata.widescreen : false);
settingWidescreenHandler();
}
};