v3.0 Updated Convention: Creating New Widgets (For Improved Performance)

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.

Liked This Article?

We have a lot more where that came from! Join 2,333,586 subscribers who stay ahead of the pack.
By entering your email, you agree to our Terms of Service and Privacy Policy.

About the Author

Shilo Eish Yemini
Shilo Eish Yemini
Shilo is Elementor’s Editor Product Manager. He loves innovative products, pays attention to the small details, and is passionate about solving puzzles.

Share on

Share on facebook
Share on google
Share on twitter
Share on linkedin

Comments

11 Responses

  1. 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

  2. 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.

  3. Oh good, long overdue refactoring and bloat cleanup.
    Some fundamental performance issues which need to start with the DOM.

  4. 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).

  5. 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!

Leave a Reply

Your email address will not be published. Required fields are marked *

Never miss an update
Subscribe to our developer’s newsletter for every latest update