It seems there’s another mismatch between editor view and front-end, specifically in my example the pseudo class of ‘nth-child(2n)’ won’t load correctly in the editor (for example it loads it for every section instead of only ever 2nd section as defined), however it renders correctly on the front-end. Screenshots included.
Here’s how I’ve set it up on a section/container element:
Here’s how it renders in the editor (notice it shows the background on every section):
I’m not so sure, as I tried it in Oxygen before and it works as expected. Additionally it’s loading fine on the front end, just not in the Bricks editor. Why that discrepancy?
If you compare the builder source with frontend source, you will notice that in the builder, each element is followed by a style tag that contains the inline CSS of the element, which causes the nth-child to break (unlike nth-of-type). And that makes it work on the frontend but not in the builder.
I’ll talk to Thomas next week about whether we can’t just push the style tags to the end of the canvas, which will fix the problem effectively. In the meantime, however, you can use nth-of-type as suggested earlier, which should work because it has fewer conditions than nth-child.
Hmm, I’d rather stick to what the community is recommending generally for how to style odd/even rows, but I’ll consider that as a workaround for now.
Hopefully this bug can be rectified though in the next version, as there ideally would be no difference between front end and editor. I’ve found too many instances lately in 1.4 editor not showing as it does on the front end which is kind of concerning to me.
Looks like I was able to use :nth-of-type(2n+2) for my case here as a workaround, however it still required the editor to be regenerated as at first it still showed the changes on every single instance of the section. So no matter what, there’s definitely a bug here in that the editor isn’t showing properly for the front-end. In the first case, it was no matter what in the editor, and in the second case using the workaround it was on the first load still an issue in the editor. Hoping this can be fixed for the next release, please.
I noticed the “status” of this is WAIT instead of WIP… is this waiting on more details from my side at all. If so, please let me know.
Just to summarize: Even using your recommendation of :nth-of-type* doesn’t change the behaviour in the editor at first at least, but thankfully shows properly after reloading the editor completely. With that said, the recommended pseudo class for my use-case is supposed to be the :nth-child-of* instead which never shows properly in the editor (but always does in the front-end thankfully).
I’m hoping that this will be resolved in the next release if possible, as it seems like a pretty large bug for anyone using the ‘nth’ pseudo classes. Seeing things in the editor differ greatly from the front-end is a very large annoyance. haha.
It was in WAIT status so was just checking to make sure it was going to be addressed and wasn’t held up waiting on more info from me. Trying to help you guys out. Thanks for updating the status.
From another thread it looks like this is being worked on currently, the elements inside that cause the issue with the nth-child should be being moved out.
Yes, that’s the problem. The ul.actions which show the edit button, padding, width etc. in every element and temporary style tags cause problems in the case of nth-child or partly also nth-of-type, because they are part of the DOM and the “calculation” doesn’t work anymore.
I’m using a first-of-type pseudo class on the repeating element (query loop), and while it does render fine on the front-end, it’s buggy on the backend. If the pseudo class is not selected in the builder, displays correctly, but once I select it (pick from the existing applied pseudo classes), it applies the styling to all other repeating elements as well. I guess it’s more like an undesired side effect, than a real bug.
Thanks for developing Bricks! It’s becoming a geat builder!
Thanks for the welcome message! I’m already so flattered by the whole forum and the conversations I see here. It’s something that reminds me of the good old days of phpBB communities
Looking forward to work with Bricks and do my part on helping it become the best page builder ever!