CSS for Embedded forms Loads Layout CSS when it shouldn't

[derekcavaliero]

Something must have changed recently with how HubSpot loads in CSS for embedded forms.

Generally speaking, we usually disable all the default styles on embedded forms to make them match ours (or our clients) brand without having to fight against existing stylesheet rules loaded in by HubSpot.

We did this using the documented form embed code property as seen below:

css : ''

That used to work brilliantly. Until someone decided to make the layout CSS that is loaded into the page for forms (such as multi-column fields) part of the CSS payload that is loaded for when the cssRequired option isn't disabled on the form embed.

This is a problem, mainly because it started breaking form layouts for forms that used to work perfectly fine prior to whatever change has been implemented.

What's worse - is that the only way to get rid of it is to remove the cssRequired - which 95% of the time is OK - but if you need to use a datepicker field - you're stuck between a rock and a hard-place. Rewriting the datepicker CSS is a pain (and I don't actually think you can without breaking the functionality).

Here's an example of the CSS im dealing with being loaded even though the css: '' is enabled in the embed code.

TL;DR; layout CSS shouldn't be part of the cssRequired payload.

Why: HubSpot can't know the context of where the form is being embedded, the developer or site should control the layout without having to write !important tags on CSS rules to override layout defined by HubSpot.

[scottburton]

Bumping this since it's a big problem for me too. Another thing: the `cssRequired` option doesnt do what it says in the docs. The docs say "CSS string specific to validation error messages. Empty string == no style". But setting this option to empty string eliminaters *all* hubspot css. It seems like `cssRequired` does what `css` is supposed to do according to the docs.

[derekcavaliero]

Thanks for bumping @scottburton. No good news yet - I have a long support ticket thread open that hasn't gone anywhere yet. Engineers/support are basically telling me how to write CSS  which isn't the core issue at hand here.

I'll keep you posted what I hear back.

[lscanlan]

Hey guys,

I am looking to get some clarification on this one. Derek had sent over a link and some info in a direct message that was helpful. For what it's worth, at the very least I think we can include more info in our docs about what these options do. In testing, it does seem like the cssRequired option removes quite a bit more of the default CSS than the css option does. So I'm not sure if this is working as expected right now.

I'm also looking to see if we can better document what these options do specifically (like maybe document the entire rule sets). And also if maybe we can document empty rules with more specific selectors to make it easier to over-rule default CSS. And also if possible, to allow for more control in terms of what CSS should be brought over in an embedded form. Because like Derek said, HubSpot can't know the context of an embedded form.

[derekcavaliero]

@lscanlan appreciate the follow up. Yeah, I agree that something with the documentation or expected behavior of that form embed setting isn't right... Updating the documents would be a good start, though - any changes to CSS/HTML that is added/rendered by HubSpot would in my mind be a breaking change that should be announced in a very public fashion. 

[lscanlan]

Hey guys, so here is what I've been told regarding the embed options. The css option has been deprecated. We're going to update our documentation here: https://developers.hubspot.com/docs/methods/forms/advanced_form_options to reflect that.

It sounds like nothing regarding the css option has changed recently though. With that option applied to the embed code, some basic "required" CSS is and always has been applied to those forms. So this is for things like columns (some of the layout CSS), legal consent, recaptcha, etc.

While the css option is deprecated, it's supported for the past, but no longer recommended. For a better experience, we should be using the "Unstyled form" toggle in the form editor. I've just added another post where I've re-written the default CSS for embedded forms, which has slightly more specific selectors. You can find that here: https://community.hubspot.com/t5/Share-Your-Work/Over-rideable-default-CSS-for-unstyled-embedded-Hub.... That will make it easier to over-ride the default CSS that gets injected with an embedded form. This way you can use the selectors that I've written up, instead of having to come up with your own selectors. You also won't need to use !important tags to over-ride specificity altogether.

Let me know if you have any questions here.

[derekcavaliero]

Thanks @lscanlan 

I do not think taking away the ability to override the "styled vs unstyled" form via the code embed is a wise decision. Clients often don't understand why we would "want" and unstyled form (in their mind - it should be styled).

I fear if you fully depreciate the css form embed options, all of our legacy forms that were created before that "unstyled" toggle existed - might revert to the styled mode and served through an iframe (which is why we wouldn't ever use that option).

Hopefully you can see/understand my concerns. When you have 30+ portals with thousands of forms - 1 (seemingly) small change like this can inflict a great deal of unintentional pain.

[lscanlan]

Hi @derekcavaliero,

I'll look into what's been changed and why. In the meantime, could you link me to a page where you've embedded a form? I'll do some testing myself, but it'll be helpful to have an example from you as well.

 - Leland