How to provide a good experience in the page editor
Below, learn about best practices to avoid issues when your code is rendered in the context of HubSpot's editors.
It’s important to test your assets in HubSpot’s content editors before delivering them. By testing in the editor, you can identify styling conflicts to create a more seamless experience for the content creator.
I's recommended to test the following functionalities in the editor to ensure your asset works as expected:
- Text formatting using the Style dropdown menu as well as other toolbar options such as alignment and colors.
- Insert options in the rich text toolbar, such as embed codes, images, links, and personalization tokens.
- Inline rich text element configuration options that appear on click, such as when editing an inserted hyperlink or image.
This function will run when there’s a click on the body element. Because the code calls
event.stopPropagation(), the event will not bubble up to the
window. If there are event listeners on those elements, the code in those listeners will not run. The issue with the above code is that the click handler will run on every click, which causes problems in the inline editor because it adds click handlers to the window element via React. Instead of listening for every click, it would be more appropriate to only add the click handler when needed — for example, after a user has clicked a button to open a side menu — and then removing the handler once the click has fired.
Problems can occur in CSS when using selectors that are generic like
label. When possible, you should instead use selectors that are specific to a portion of the webpage, such as
Being more specific with CSS selectors allows you to pinpoint the elements you want to style without impacting other elements unintentionally. You can also take advantage of our boilerplate CSS file to have a better sense of selectors that should be used to avoid CSS bleed issues.
Avoid using !important tags
!important tags are used to make styling rules take precedence over others. While you can use an
!important tag when styling is being overridden, it's not recommended to use this tag on bare element selectors like
For example, you might consider applying an
!important tag for styling the
<label> element, with the intent to ensure that all
<label> elements in a form are white.
While this rule theoretically works when content is rendered on your live website page, it will also render all
<label> tags in the content editor as white, as shown below.
Instead, you should use more specific selectors, as shown in the code below, to target only the form module labels.
Below, learn about the different methods of conditionally rendering content based on whether it's rendered in HubSpot or on the live page.
The editor uses an iframe to load a preview of the content into HubSpot’s content editor, and the
<html> element within this iframe is assigned a class of
.hs-inline-edit. Using this class, you can write CSS that conditionally renders based on the presence of that iframe.
For example, the following CSS takes advantage of the pseudo-class
:not() so that the rule does not apply when loaded in the editor:
As another example, if you're seeing that the rich text toolbar in the editor is being hidden behind a page's header due to a z-index rule, you could update your CSS to apply a lower z-index value to the header. By using the
.hs-inline-edit class, the new rule will only apply in the editor, not the live page. For reference, the rich text toolbar's z-index is
When content is loaded in the editor,
window.hsInEditor will return
HubSpot provides a set of HubL variables that will return
true in various editor and preview contexts. This includes variables that can check for any editor or preview context, as well as specific editor and preview contexts.
For example, the if statement below would render its content only when the user is in the blog post editor.
Thank you for your feedback, it means a lot to us.