SOLVED: Default element selector — bad UX currently

Hi, I recently bought Bricks Ultimate, and I also frequently use Webflow and Oxygen, and I have one frustrating UX issue in Bricks that disturbs/breaks the workflow while building the pages.

When I add an element, add a class to it and style that class… Then click away/do other stuff. When I click back on that first element again, selector that’s being automatically chosen is ELEMENT ID, instead of the class that I just added. This is especially frustrating when working with multiple/combo classes, so whenever I click on an element to readjust some properties, I have to manually click the dropdown and choose the latest combo class instead of an element ID, which is always being chosen by default.

By having elements to always switch back to ID as a main selector, the whole purpose of introducing CSS classes as a system for globally styling website’s components is kinda thrown away.

This current UX suggests that most prominent thing that you expect users to use for styling is - ID, and NOT classes, since that’s what you fixed as preferred, automatic choice.

Will this please be fixed? I really, really, really want to abandon Oxygen and use Bricks instead in future, but I can’t until things like this are fixed.

Thanks!

2 Likes

Hi Lj,

welcome to the forum!

I can understand your trouble and recently thought about that as well, as it will improve the workflow a lot. I will discuss your suggestion with the team and if all goes well, it will be implemented in one of the next versions.

Best regards,
timmse

3 Likes

Perhaps when you add a class, keeping the class selected during that editing session but once you leave the builder and come back, no classes are highlighted for editing. This would make sense for the user who knows that they are editing the class and those who might be looking to make small adjustments later on.

1 Like

I have to agree with @LjLj

If you have added a class to an element then you would assume that would take priority. Unless i am missing something but why would you want to edit the element ID, to an element you have added a class to?

I also find that if you have a class associated with an element it provides more of a visual representation too. I appreciate you have a the little number present, but it is not as clear as the class box highlighted in yellow

1 Like

Overall, I totally agree with you guys!

Yes and no. In terms of specificity, the ID has always a higher priority than the class. But you are totally right, if a class has been added, it should be automatically be selected (at least the last one added or edited). It happens faster than you get it that you´ve applied some styles to the ID instead of to the class… and then you have the mess that the styles of your ID override your class. This can lead to confusion very quickly…

Agreed. This also applies to the pseudo-elements, which are really hard to keep track of at the moment (my personal opinion). But we´re currently thinking and working on that one as well :smiley:

2 Likes

Ah my bad i didn’t explain clearly, I meant user priority (not CSS priority) :slight_smile:

1 Like

Hi guys,
I have good news for you!

We will implement auto-selecting the previously-selected CSS class. This means, if you’ve added a class to an element, this class will be automatically selected when editing the element next time instead of the ID. This ensures not to unintentionally override your class styles with the ID styles.

This together with my suggested class lock feature on the idea board would supercharge the editing workflow. Think about adding some utility classes for your paddings, colors, font size, you can use on your entire website, it would be nice to lock those classes to prevent unintentional overriding. Or think about a “card” container with all styles applied. Lock it when you’re finished with editing and you don’t have to worry about overriding your styles next time you select the element.

Best regards,
timmse

3 Likes

That is so awesome! Yes, the workflow will be great with those features introduced, definitely a power-up to the experience of using Bricks! I didn’t expect the change to come so soon, I am practically shocked (positively ofcourse)!

Thank you @timmse and whole Bricks team, love this team and this product!!

3 Likes

CAN’T WAIT for this right here. This would remove 90% of frustration I have when building currently. Is this expected in the next release?

2 Likes

Hi Eric,

yes, this feature will be a part of Bricks 1.3.7 :v:t2:

Best regards,
timmse

1 Like

Short update: the feature has been integrated into Bricks 1.3.7 as promised. The Class-Lock feature I mentioned above will be introduced in Bricks 1.4.

2 Likes

Hey Stefan,

Did this not make its way through in the end? If it did get implemented, then it does not seem to work in 1.4b - If you could let me know if this should be working, I will send you a screencast regarding an accordion issue I have and include this in it.

Thanks bud :+1:

Hi Michael,
As far as I know, the “auto-select the last selected class” feature works as before (except for locked classes in 1.4beta), within a session. As soon as you close the tab, the session is ended and the ID is again the default selector.

Please share the screencast here and tell me more about your problem.

Thanks for the quick reply Stefan (especially on a Saturday) I did actually send through a ticket with a screencast via email, so hopefully that will be with you :slight_smile: