domq
commented
1 year ago Since the data-foo use cases enable declarative (JavaScript-free) use-cases, and they are parameters (inbound) only, they should probably stay the way they are.
Since we already have a $.fn.epflElements, this sounds like as good a place as any to start. We propose to make the following getters / setters work:
const svgPath = $('body').epflElements("svgPath");
$('body').epflElements("svgPath", "/icons/foo.svg");
const consented = $('body').epflElements("cookieConsent");
$('body').epflElements("cookieConsent", "notRequired");The latter would address #610.
In addition to (or instead of) that, we could turn window.svgPath, window.featherSvgPath and window.cookieconsent into data-epfl-elements-icons-uri, data-epfl-elements-feather-icons-uri and data-epfl-cookieconsent attributes of the <body> tag, respectively.
Like every program of some size, the JavaScript code in epfl-elements takes a number of parameters and manages state.
Right now, the following flavors of parameters and state are used:
jQuery.dataAPI: for instance$galleryNav.data("gallery"), intended as a parameter (example use-case);$(".social-share-copy").data("success"), intended as a parameter (example use-case)window.fooattributes: for instancewindow.svgPathandwindow.featherSvgPath, intended as parameters,window.cookieconsent(which is intended as state, but can be twisted into being used as a parameter),window.flickityInstances, which appears to be dead code.We might want to provide uniformity here.