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.
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.
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?
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.
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.
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 is what you need in this case.
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')
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 <div> wrapper we can always use an <a> element without a href property set.
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.
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.
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.
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
