# Element wrappers, styles and classes **URL:** \ **Category:** Ask us anything\ **Created:** [January 7, 2024, 4:30pm UTC](https://community.weweb.io/t/element-wrappers-styles-and-classes/6252 "2024-01-07T16:30:51Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Antiokh](https://sea2.discourse-cdn.com/flex016/user_avatar/community.weweb.io/antiokh/32/2794_2.png) [@Antiokh](https://community.weweb.io/u/Antiokh)\ **Post date:** [January 7, 2024, 4:30pm UTC](https://community.weweb.io/t/element-wrappers-styles-and-classes/6252/1 "2024-01-07T16:30:52Z")
The problem: different properties are set to different elements inside one element. First of all: I’ve already created a [ticket](https://support.weweb.io/ticket/JL86BbUlsQtTSn/), but it seems like we can’t understand each other, but there is no chat inside support tickets. ![image](https://us1.discourse-cdn.com/flex016/uploads/weweb/original/2X/8/882967d3d007d6c63108828283c4daa0f9a107b3.png) [demo page](https://39e4ed69-2384-4bc6-a8d5-583a27a75297.weweb-preview.io/demo/) 3 cases (using standard elements): 1. I set `marker` class to the first button and set a workflow action. The class is applied to the `button` element, but basic attributes are applied to the wrapper `ww-object`. 2. I set `marker` class to the second button and set a “Link” property to some page. The class is applied to the `button` element, which doesn’t cover all the button, because `a` element has paddings. All the visual properties are still applied to the wrapper `ww-object`. 3. I set `background` property with `css` properties section. All works fine, but the style is applied to the wrapper not to the `button`. It means that I cannot operate DOM model correctly if every time I need to work with different elements. Usecases: - When I need to set some element to “active” state, I want to brush the button BEFORE I receive a data update from the backend. - If I want to apply some visual effect to the button (like material ripples) I have to avoid links and use a workflow instead. But links are better for SEO and accessibility. ## Is there any solution for the standard button element? ---
**Author:** ![dorilama](https://sea2.discourse-cdn.com/flex016/user_avatar/community.weweb.io/dorilama/32/10403_2.png) [@dorilama](https://community.weweb.io/u/dorilama)\ **Post date:** [January 7, 2024, 5:00pm UTC](https://community.weweb.io/t/element-wrappers-styles-and-classes/6252/2 "2024-01-07T17:00:49Z")
I just send a feature request about this two days ago. I 100% get your problem (styling the active button is one of the thing that I am doing) It feels odd that weweb applies some styles, like the background, to the parent element. This is how the platform works and I suppose we need to deal with it. For example if you plan to directly modify the background with css you need to target the wrapper and not the button, or you get the kind of inconsistencies that you describe. At the same time it makes sense that classes, id and attributes are applied to the actual button element and not the parent. My feature request is to add a “wrapper class” property to let us add classes to the parent wrapper. This can ease multiple use cases. As a workaround you can play with the `has` pseudo selector to target the wrapper, not ideal but it works. What I am doing at the moment is targeting the parent this way and set css variables to it, then in the editor I’m binding the properties that I want to change to the css variable, so I don’t need to check where weweb is applying it. ---
**Author:** ![Antiokh](https://sea2.discourse-cdn.com/flex016/user_avatar/community.weweb.io/antiokh/32/2794_2.png) [@Antiokh](https://community.weweb.io/u/Antiokh)\ **Post date:** [January 7, 2024, 5:20pm UTC](https://community.weweb.io/t/element-wrappers-styles-and-classes/6252/3 "2024-01-07T17:20:22Z")
I know this workaround (`has`), but it isn’t really nice because it cannot target the element for sure. There is another DOM bug: if you set some workflow and want to use a `target` property in workflow, it can return you either a button text element or a button element. So every time you need to find out, which element raised your workflow. It IS RIGHT for the DOM JS model, but it is not right when we speak about a workflow, triggered by some element from the nocode framework. ---
**Author:** ![dorilama](https://sea2.discourse-cdn.com/flex016/user_avatar/community.weweb.io/dorilama/32/10403_2.png) [@dorilama](https://community.weweb.io/u/dorilama)\ **Post date:** [January 7, 2024, 5:38pm UTC](https://community.weweb.io/t/element-wrappers-styles-and-classes/6252/4 "2024-01-07T17:38:02Z")
with `has` + a class on the button you **can** create a selector that targets the wrapper. The js thing is not a DOM bug, it is because you have other elements in the button, like the text or the icons and the click can actually start from one of them. Of course you need to address this by checking if the target is the button, or one of its children. [closest](https://developer.mozilla.org/en-US/docs/Web/API/Element/closest) is what you need in this case. ---
**Author:** ![dorilama](https://sea2.discourse-cdn.com/flex016/user_avatar/community.weweb.io/dorilama/32/10403_2.png) [@dorilama](https://community.weweb.io/u/dorilama)\ **Post date:** [January 7, 2024, 5:42pm UTC](https://community.weweb.io/t/element-wrappers-styles-and-classes/6252/5 "2024-01-07T17:42:38Z")
> [@Antiokh](#): > > It IS RIGHT for the DOM JS model, but it is not right when we speak about a workflow, triggered by some element from the nocode framework. Do you mean that you would like to have the `button` element available in the event data of the nocode workflow instead of the real target element? I can see how this can be helpful, and also how it could be confusing at the same time. Personally I just prefer to get the actual target and then just do `target.closest('button')` ---
**Author:** ![Antiokh](https://sea2.discourse-cdn.com/flex016/user_avatar/community.weweb.io/antiokh/32/2794_2.png) [@Antiokh](https://community.weweb.io/u/Antiokh)\ **Post date:** [January 7, 2024, 5:56pm UTC](https://community.weweb.io/t/element-wrappers-styles-and-classes/6252/6 "2024-01-07T17:56:27Z")
> [@dorilama](#): > > with `has` + a class on the button you **can** create a selector that targets the wrapper. Yes, I agree, but I must keep in mind, which type of button I use. Now I made a workaround setting a button class and ID based on dynamic collection data. I agree with your proposal to WeWeb: it’s better to have a control over a wrapper class properties. Maybe instead of `
` wrapper we can always use an `` element without a `href` property set. > [@dorilama](#): > > Do you mean that you would like to have the `button` element available in the event data of the nocode workflow instead of the real target element? I can see how this can be helpful, and also how it could be confusing at the same time. Personally I just prefer to get the actual target and then just do `target.closest('button')` I think you got it right. I can use `closest` and also I have to check, which element is returned, but still, it’s a hack. If I set some workflow from a `button` element, I want to be 100% sure that I will have a “button” as a returned target element, not `span` and not icon. ---
**Author:** ![dorilama](https://sea2.discourse-cdn.com/flex016/user_avatar/community.weweb.io/dorilama/32/10403_2.png) [@dorilama](https://community.weweb.io/u/dorilama)\ **Post date:** [January 7, 2024, 6:34pm UTC](https://community.weweb.io/t/element-wrappers-styles-and-classes/6252/7 "2024-01-07T18:34:55Z")
> [@Antiokh](#): > > I can use `closest` and also I have to check, which element is returned, but still, it’s a hack. If I set some workflow from a `button` element, I want to be 100% sure that I will have a “button” as a returned target element, not `span` and not icon I personally view this in a different way. Once you choose to use js you need to follow how it works. If you click an icon the event’s target is the icon. Checking what element is triggering the event is not an hack, is how the browser works. Overriding the browser behaviour would bring more harm than benefits: look to other nocode platforms that reinvented broser standards in their own runtime, they are a nightmare to work with. Anyway `target.closest('button')` will return the button itself if the target is the button, so no need to add a check. ---
**Author:** ![Antiokh](https://sea2.discourse-cdn.com/flex016/user_avatar/community.weweb.io/antiokh/32/2794_2.png) [@Antiokh](https://community.weweb.io/u/Antiokh)\ **Post date:** [January 7, 2024, 6:44pm UTC](https://community.weweb.io/t/element-wrappers-styles-and-classes/6252/8 "2024-01-07T18:44:25Z")
I’m partially agreed. As I said, yes, DOM works like this: `trigger p>button>a>div.wrapper` or `img>button>a>div.wrapper`. But inside a nocode tool I expect that if I set a trigger to some element, I’ll get this element, not the whole chain. If you add an event listener to some class in jQuery, you will get this exact object, and this is how it works for the developer. In jQuery you will have an object in `this` and you will have the ability to get an actual clicked object from `event.target`. Usually you don’t need this information. ---
**Author:** ![dorilama](https://sea2.discourse-cdn.com/flex016/user_avatar/community.weweb.io/dorilama/32/10403_2.png) [@dorilama](https://community.weweb.io/u/dorilama)\ **Post date:** [January 7, 2024, 7:56pm UTC](https://community.weweb.io/t/element-wrappers-styles-and-classes/6252/9 "2024-01-07T19:56:17Z")
In this case we don’t know where the listener is attached, and we don’t have the `currentTarget` available because the nodoce trigger is not the click handler. Yours is a valid point of view and can be an interesting input for the team, maybe they can find a better nocode way. Maybe this is not available just because nobody asked for it, and now you asked 🙂