Redesign / Identification of element function in markup

[furilo]

This is a potential version of the new menu in a space:

As a reference, the "original":

As you see, it includes icons that match with the component. There are several ways to implement this variation depending on the default "design" of the markup. If no reference to the component exists in the markup, the implementation would require overwriting views.

If we included something like this (I'm ignoring here the classes needed to style the actual element):

<ul class="space-menu">
  <li class="component-about">About the process</li>
  <li class="component-proposals">Proposals</li>
  <li class="">Meetings</li>
  ...
</ul>

Adding these extra classes would make trivial to just include the icons via CSS, without the need to edit any view.

On the cons side, we would be adding classes in the HTML that may not be used for nothing, but I think this small extra cost is totally worth the potential savings of avoiding overwriting partials.

I propose we take this into account everywhere it makes sense. If we agree, we may outline some guidelines regarding 1) which elements to "tag", 2) naming conventions, 3) reusing of not classes for other purposes...

cc @decidim/product @ahukkanen @Crashillo @entantoencuanto

[ahukkanen]

One thing that comes to my mind is that I believe the SVG "sprites" (i.e. the hidden symbol references) don't work through CSS definitions, which is going to be a problem if you've decided to go with the remixicon SVG version. And here I basically mean that what if I wanted to use an icon from the iconset for my module? I remember this bothered me especially in the beginning when starting with Decidim.

Another problem it can pose is that it can potentially increase the amount of requests to the server if all modules define separate icons through CSS. This wouldn't be a problem anymore once HTTP/2 and/or HTTP/3 become widespread as discussed at #8783 but I always route for maximum compatibility which means to assume HTTP/1 for the time being.

[carolromero]

@furilo thanks for the proposal and the explanation of cons and pros.

After careful consideration, we have decided not to introduce icons in the menu for the following reasons:

• Maintaining simplicity: the new design emphasizes simplicity and a clean user interface. The inclusion of icons in the menu might introduce visual complexity that could potentially confuse participants.

• Consistency in markup: Our aim is to keep the markup as clean and straightforward as possible. Adding extra classes, even for styling purposes, might complicate the markup unnecessarily.

• Avoiding unused classes: Adding extra classes to elements that may not use them for any functional purpose could lead to unnecessary clutter in the HTML, potentially impacting load times and overall performance.