Define when should we use the id attribute.

[dgdavid]

Some time ago, we were asked by @qe-yam team to use the HTML id attribute for each element in HTML DOM element that they need to handle

I had a short chat with @imobachgs about it and checked that all Agama form elements have unique identifiers. Thus, we asked them to tell us what other nodes they need to be identified to take a look and, somehow, define a guide/rule to follow.

However, it was pending to reason about why not put the id attribute everywhere.

Unless I'm wrong, there is no technical or performance problem with using the id whenever is needed. I found neither, browser limitations nor strong recommendations in the documentation. The only rule is to respect its uniqueness, which can be a bit challenging if we start using it indiscriminately.

The idglobal attribute defines an identifier (ID) which must be unique in the whole document. Its purpose is to identify the element when linking (using a fragment identifier), scripting, or styling with CSS.

https://developer.mozilla.org/en-US/docs/Web/API/Element/id

Aside from rules and/or challenges, some of us are (or were) against relaying more than needed in such an attribute because we are a bit old-school and we were there when people used to use an id for CSS fixes because it usually wins due to its weight in the specificity algorithm.

Slightly related to this, note that we also avoid using the data-testid attribute when writing test for the components. But here we're just following the React Testing Library recommendation.

In the spirit of the guiding principles, it is recommended to use this only after the other queries don't work for your use case. Using data-testid attributes do not resemble how your software is used and should be avoided if possible. That said, they are way better than querying based on DOM structure or styling css class names. Learn more about data-testids from the blog post "Making your UI tests resilient to change"

https://testing-library.com/docs/queries/bytestid/

With all this in mind, I think we should define our own rules to know when we should use an id. We can start with something simple and reevaluate it when new and justified needs arise. Thus, my initial proposal would be to use them in

• form elements, of course.
• clickable actions and navigation elements (to ease the work of @qe-yem team)
• clickable sections headers (which are navigation elements at the end)

Ideally, we should try to define a naming pattern too.

Please, comment below. I'm eager to read your ideas on this topic.

---

Related to https://suse.slack.com/archives/C02TLF25571/p1694591663458129 (internal link)

[joseivanlopez]

I agree. I think there is no reason to add and ID to all the elements. I would only add the ID if (for some reason) we need to identify the element. And, as you said, CSS should not be a reason anymore. The main reason for having IDs in Agama is integration testing. So, as a general rule, I would add an ID to all clickable elements.

[dgdavid]

So, as a general rule, I would add an ID to all clickable elements.

And also elements that are going to be used for aria-describedby and aria-labelledby. But these will ask you for the id as soon as you need to reference them.

Form elements, as said, are also candidates to have an id from the very beginning. But it's true that they are already in the clickable elements set.

[joseivanlopez]

And about naming pattern, what about something like this? ${page}-${section}-${context}-${id}

• overview-storage-link (page=overview, section=storage, context=, id=link)
• storage-settings-lvm-switcher (page=storage, section=settings, context=lvm, id=switcher)
• storage-settings-lvm-options (page=storage, section=settings, context=lvm, id=options)
• storage-settings-lvm-options-form (page=storage, section=settings, context=lvm, id=options-form)
• storage-settings-lvm-options-form-sda (page=storage, section=settings, context=lvm, id=options-form-sda)
• storage-settings-lvm-options-form-submit (page=storage, section=settings, context=lvm, id=options-form-submit)
• storage-settings-fstable-add (page=storage, section=settings, context=fstable, id=add)
• storage-settings-fstable-home-edit (page=storage, section=settings, context=fstable, id=home-edit)
• storage-settings-fstable-home-delete (page=storage, section=settings, context=fstable, id=home-delete)

[dgdavid]

I'm going to keep this closed by now. We're in the middle of UI reorganization after remaking it almost form scratch. We' can revisit this topic later.