Components that us id selectors

The power of components is that you can duplicate much of the html and only edit image src or anchor href to customize each instance to a particular purpose.

That seems to work well enough as long as the component does not employ the use of the id selector (class or element only).

Because as soon as you have two instances of the component on the same page, there are now duplicate elements with the same id… which is bad and causes no end of confusing behavior.

Am i missing something or has PG yet to implement a way to handle unique id for component instances?

1 Like

@droidgoo Did you ever find a solution to this problem? I’ve been trying to use components to simplify my workflow, but this keeps biting me in the button from an accessibility standpoint. Lighthouse shows the following warning:

IDs of active elements must be unique: Document has active elements with the same id attribute: submenu-trigger

And axe DevTools shows a similar accessibility issue.

How about declaring the ID attribute as editable with an Editable area? And then set the ID on each instance to a unique value.

1 Like

@matjaz: thanks for the suggestion, but I don’t think it’s going to help in the use case I’m working on at the moment.

Goal: I’m creating a page with multiple menu areas all sharing the same structure and style. For example, the main (top) menu and menu in the fly-out mobile panel will be duplicates of each other, similar to the design you have in your Flex demonstration. I’m using Interactions to control the dropdown menu behavior for keyboard, mouse, and touch events, and I was referencing targets by ID.

As soon as I used PG Components to duplicate the menu in the main menu location and the mobile panel I saw the issue. Granted, I should have used class selectors with the “$” and “^” prefixes instead of IDs from the get-go but it got me thinking about whether this could create a bigger problem.

The more I noodle on it, the more I’m thinking that there may not be a good reason to use IDs vs classes in a component and I should just suck it up and fix the few places I made that mistake.

On the off-chance that there is a good reason for using IDs in components, thereby creating this issue, I’d love for someone smarter than me to chime in.

(Once again, I’m getting myself into trouble by pretending to know what I’m doing instead of just letting my developers do what they do best)

Not really experienced with Pinegrow. But I have a lot of experience in using GSAP (the library behind interactions). If that helps you in deciding I can only give my +1 for using classes instead of IDs in that case. You can guarantee that you can reuse the interactions in any scenario and don’t have to worry about anything.

What I normally do is creating classes which don’t hold any styles but referring to a specific Animation. For example <div class="fade-in-left"></div> . And the fade-in-left class is the target of my GSAP/Interactions animation.

Cheers

2 Likes

That’s exactly how I’ve changed it, and it’s working beautifully. Thanks for the confirmation.

2 Likes