Bricks Version: 1.5
Browser: FF Dev
OS: Win 11
Hey guys,
It happens only on one page, as far as I know, using the same custom class and no pseudo element added to the ID.
Phantom:
Normal:
Many thanks
Mick
Hey Mick,
Thanks for reaching out!
If you set the tag of the basic text element in your phantom example to div or span, the problem solves itself (as it does in your “normal” example).
The default styles p:last-of-type + h(x) provide spacing between paragraphs and headings that would otherwise stick together. Otherwise, you’d have to give every heading a margin-top, so this doesn’t happen, or remove the margin-top very frequently - and that would be quite inconvenient.
Best regards,
timmse
Hey Stefan,
I hope you are well (Have you been on your summer holidays?)!
I understand what you have mentioned, but just for more context
The two images are of a ‘heading element’ set with an h3 tag with the same class. One inherits this margin, and the other does not? I have approx 10+ service pages, and 8 are fine, and 2 inherit this margin (so far) still have some to manually convert.
Many thanks
Mick
Hey,
No, Covid knocked me out 
In the first example, the h3 follows a p. In the second example, it follows a div.
So p:last-of-type + h3 kicks in in the first example, but not in the second because there is no p 
Dang sorry to hear that mate, hopefully you are fighting fit again now.
In relation to the issue here is the builder set up for both (exact same)
And the one without the margin
Ah, you mean the basic text element above it adds the margin to the next element?
Again: It is not about the heading, it’s about the basic text above the heading: the first one is set to “p”, the second one is a “div”
You can see that in your first two screenshots:
Hey @stefan
Thought best to reopen this rather than create a new ticket.
in 1.7 Beta - when a class is added, and you remove the default styles (in this case, top margin) it does not accept it, It will only accept it on the ID level.
So the ID has the shaded default value, and the custom class has 0 added. The shaded default value takes precedence.
Let me know if you prefer me to create a new ticket for it.
Many thanks
Mick
Hey Michael,
I was curious so I gave this a try just now but the only way I’m able to replicate it (even in 1.7-beta) is if I put a margin-top on the element id and then try to cancel it with the class.
This makes sense because id has higher priority than class, so id wins. Is this by chance what’s happening to you?
Here’s a screenshot of what happens when I set a margin-top in the theme styles but then override it with a class, which works.
Hey Curtis thanks for taking a looksee for me.
No I did check that, but the id has a value but it is greyed out, as it comes from this default styling
So there is no manual insertion, the only manual insertion is on the custom class itself which I had ‘0’ added, pre-update was fine, just after updating to the beta it does not have any effect.
Also @cmstew just edited as looked more closely at your example, it happens with regards to a p tag followed by a heading tag 
1 Like
Hey Michael,
Is it possible that the problem is caused by this bug? When I read Basic Text and something about tags, my alarm bells start ringing:
Please download/re-install 1.7 beta again - we have already included a fix.
Ah sorry mate, forgot to add it was the last beta released a couple of hours back. Which I think was the last one.
Ok, I just looked at it. This is a classic specificity problem because the :nth+h selector is more specific than the class itself. Working on it 
2 Likes
Hi guys,
We’ve fixed this bug in Bricks 1.7.1, now available as a one-click update in your WordPress Dashboard.
Please let us know if you are still experiencing issues.
Best regards,
timmse