WHEN (situation): as a developer,
WHAT: I want to be able to specify all the HTML attributes that apply to the component,
WHY: so I don't have to edit the component with every unknown attribute
Acceptance criteria
each component accepts all valid HTML attributes that are bound to the HTML tag
Implementation notes (optional)
can be inspired by the types in typescript, where such lists already exist
a set of constants is created
Each Twig component has its own list of allowed HTML attributes that can be passed to it. If you need to pass it an attribute that is not allowed in the implementation, you must explicitly allow it.
The - list of allowed attributes expands on demand.
→ Blocking for the product that Spirit is using. Developers must look for a temporary solution to deal with the absence of an attribute.
+ The component is in complete control of the attributes it accepts.
→ Prevention from XSS, etc.
Some components do not mention in the documentation which attributes they override in the element (e.g. TextArea and autocomplete attribute).
- Component implementation is a black-box for many DS users. They don't know which HTML attributes can be passed to elements. Explicit mention in the documentation would encourage proper use of the component and make its behavior more transparent.
WHEN (situation): as a developer, WHAT: I want to be able to specify all the HTML attributes that apply to the component, WHY: so I don't have to edit the component with every unknown attribute
Acceptance criteria each component accepts all valid HTML attributes that are bound to the HTML tag Implementation notes (optional) can be inspired by the types in typescript, where such lists already exist a set of constants is created
https://www.notion.so/almacareer/Twig-HTML-atributy-de7b63bdc992477394a93155d4449642
Each Twig component has its own list of allowed HTML attributes that can be passed to it. If you need to pass it an attribute that is not allowed in the implementation, you must explicitly allow it. The - list of allowed attributes expands on demand.
→ Blocking for the product that Spirit is using. Developers must look for a temporary solution to deal with the absence of an attribute.
+ The component is in complete control of the attributes it accepts.
→ Prevention from XSS, etc.
Some components do not mention in the documentation which attributes they override in the element (e.g.
TextAreaandautocompleteattribute). - Component implementation is a black-box for many DS users. They don't know which HTML attributes can be passed to elements. Explicit mention in the documentation would encourage proper use of the component and make its behavior more transparent.GitHub: https://github.com/lmc-eu/spirit-design-system/pull/957#pullrequestreview-1566810299
Jira: https://jira.lmc.cz/browse/DS-836