feat: support data-smark-<option_name> attribute syntax for individual component options

[Copilot]

Allows SmarkForm component options to be specified as individual HTML attributes (data-smark-type="list") in addition to the existing JSON form (data-smark='{"type":"list"}'). Primary motivation: CSS targeting without needing manual class annotations.

<!-- Before: only way to set type -->
<div data-smark='{"type":"list","name":"employees"}'>…</div>

<!-- After: equivalent, and now CSS-targetable via [data-smark-type="list"] -->
<div data-smark-type="list" data-smark-name="employees">…</div>

Changes

• getNodeOptions() — after parsing the main data-smark JSON, scans node.dataset for entries matching {propertyName}{UppercaseLetter}… (e.g. smarkType, smarkName). Values are JSON-parsed with string fallback ("true" → true, "42" → 42). Throws DUPLICATE_OPTION if the same key appears in both data-smark JSON and a data-smark-* attribute with different values; same-value duplication is silently accepted to support list-template clone normalization.

• me.selector — extended from [data-smark] to [data-smark],[data-smark-type],[data-smark-action] so elements that carry only individual attribute options (no bare data-smark) are discovered and enhanced.

Notes

• Option name mapping follows the HTML dataset camelCase convention: data-smark-export-empties → exportEmpties. Existing snake_case options like min_items cannot be targeted this way (data-smark-min-items would create minItems, not min_items); use data-smark JSON for those.
• Attributes are not removed from the DOM after processing, preserving them for CSS selectors.
• New test file test/data_smark_attrs.tests.js covers type/name resolution, JSON type coercion, DOM attribute persistence, list-item cloning, and the DUPLICATE_OPTION error path.

Original prompt

Following the SmarkForm's philosophy, I mean: like the "value" property that can be both defined as a property of the options object (what is passed, as a string, through the data-smark attribute) or as an actual "value" attribute of the actual DOM node being enhanced because of having the data-smark attribute, for the tagnames allowing it, as long as it is not defined both ways (in order to avoid ambigüity).

…I want you to modify the component base class so that every property of the options object (like the "value" option itself) could also be specified using a dedicated property with a name of the form "data-smark-<option_name>".

For instance, in the case of the "type" option, the idea is to allow it to be specified both as, for instance, data-smark='{"type": "list"}' or data-smark-type="list".

The goal is, by allowing them to be specified that way, making possible to target them more easily from CSS without having to manually add css classes to each and every component.

Like in the case of the "value" option, repetition should not be allowed to avoid inconsistencies.

Please, analyze it beforehand gathering all the information you need to understand every detail and ask me any question you have beforehand and, specially, tell me if you see any possible drawback or gotcha in this idea.

After that, and in case we don't find any reason against, please go ahead and create a new pull request implementing this feature.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.