As part of our effort to simplify and minimize the markup created by Elementor, we have decided to truncate the prefix we use for any Elementor CSS classes, from .elementor- to just .e-.
This move is joined by another important step in our journey of performance enhancement – reducing the number of wrapper HTML elements used by our widgets and by the system in general.
What does it actually mean?
In all of our new widgets, controls, and all-in-all system markup, we will be prefixing all of our classes with .e-.
We will NOT be changing pre-existing widgets, controls, or any other system elements, in order to allow for backwards compatibility and avoid causing serious problems in existing Elementor websites.
As opposed to the wrapper removal step, this is not a breaking change, so it’s not a big deal – if you see a change in our conventions, we just wanted you to let you know that it’s legit and share with you the reasoning behind it.
How does this affect me as an Elementor user or extension developer?
First of all, there is no need for you to make any changes to pre-existing widgets or system elements. If you are developing extensions that manipulate existing system elements, controls or widgets, and used the .elementor- prefix before – we recommend you to follow this guideline and start using .e- instead in your new developments.
11 Responses
Nice one! Looks like company start doing code refactoring!
I have no idea whether this feature is in Development or still considering –
1. Code Splitting not by default but by user action. What i mean is that instead of code splitting by default users can select whether to split the code or not.
2. Less JS dependencies – right now removing JavaScript is a nightmare because when i tried to remove one JS libraries all the JS wouldn’t load.
And Thank you for considering Performance
Good move! I was thinking exactly the same thing few days ago.
Great work Elementor team, many of us will really appreciate this move.
Really looking forward to this. ✌️
Great idea but i think that the best solution will be when users can deactivate the unused widgets removing so the code not necessary.
Give a look to this https://github.com/helloideabox/elementor-widget-manager and take ispiration 🙂
I’m looking forward for the update! Anticipating a cleaner output with v3.0. 🤩
Finally, this would definitely reduce a lot of unnecessary codes in the CSS, especially the frontend.min.css which currently weighted around 102kb(free) and 200kb for (pro).
We don’t want to see it grows up to 400kb like Visual Composer just for the CSS alone.
Please reduce absolute nested selector especially in the frontend.min.css so developer or front-end coder can overrides some of the styling providing more flexibility and customization.
imagine
“.woocommerce div.product.elementor .elementor-add-to-cart–align-right form.cart:not(.grouped_form):not(.variations_form) div.quantity”
just for 1 style alone…..
Modular CSS load would be definitely helpful in many way so it would only include necessary styles and scripts.
Kudos to the developer team who really did a deep thoughts on optimizing this for a cleaner, lighter and flexibility for us.
Oh good, long overdue refactoring and bloat cleanup.
Some fundamental performance issues which need to start with the DOM.
Great move.
Please reconsider how you implement HTML5 semantic tags. It should be easy and not relying only on the visual elements like section, columns and inner section (BTW, why don’t you remove inner section and simply have section).
Thanks Acor,
You can set per document semantic HTML5 tags as mentioned here: https://elementor.com/blog/introducing-full-site-editing/
This is amazing news! Adding granular configuration on widgets would also save resources. Please look into this Shilo. Almost all third-party widgets have this feature so I think the foundation should also include it 😀 Thank you for listening to us!