7.4.0 Beta 1 | Feedback list

Beta
#1

Hey @charlie – absolutely great work on this update. Really excited for what the future holds for CS. I’m working on an actual building using this beta to try and push it through my regular workflow. Noticed a couple of items that I’m going to list here. Some of these may have been addressed in some other people’s posts as well.

1. I may be nuts but I typically use the following CSS quite often on my builds to create sticky divs:

/* Make Element Sticky */ .sticky { position: -webkit-sticky; position: sticky; top: 200px; z-index:99; } body { overflow-x:visible; }
I typically Add a div into a column and give that div a class of sticky and it has always worked flawlessly. However, for some reason in this beta it requires !important declarations throughout. Not a huge deal if that is known but that will likely break a lot of sites that were doing something similar.

2. Quite a few element dragging issues throughout the build process. Mostly minor issues but seeing them more often.

3. When typing numeric values into an inspector field (such as padding or width, etc) – the preview is sometimes quite delayed in rendering and/or doesn’t render at all.

For example if I type 70px the first integer (7) will be recognized but not the second integer (0). Even though it will be rendered properly on the frontend the preview will not look correct. Simply requires typing something else and then typing your two digit integers again. Seen this one regularly throughout.

4. FA icons are slow loading and cause the builder to lockup. Also many icon previews were missing for days. Suddenly started all showing up several days later.

5. This is a side note not related to beta, necessarily, but I think it might be nice within CS settings to allow for the enabling or disabling of the automatic image alt tag fallback.

Currently, if no alt tag is included CS falls back to a generic alt tag of “Image” which is awesome and I think should remain as the default. That said, there are some instances where users might rather have the ability to leave alt tags blank – especially when working with decorative images. Allowing for alt="" (https://www.w3.org/WAI/tutorials/images/decorative/)

I created this element here which I believe solves the problem but would be nice to see a setting (btw straight up incredible that CS parameters allows me to essentially create my own fully custom elements)

https://buildingonwp.com/elements/custom-image-element/

6. Again, I might be nuts but I don’t seem to see any perceived difference when changing the new dropdown (interval, timeout, and sensitivity) values. I’ve even tried going to the extremes.

2 Likes
#2

Would be nice to see 1. in CS. A cute little checkbox to set a column to be sticky :heart:

3 Likes
#3

Hey thanks for these notes!

1. Divs default positioning of relative seems to messing with this. Think I just need to place custom CSS after generated styles and this will be okay. Never actually heard of the sticky position value.
2-3. Not really seeing these, does this happen on the beta site as well?
4. Changing the defaults to not include Sharp will probably help, that was just left over from development. It probably won’t be great performance wise without infinite scrolling. The issue with FA5 icons cached should be fixed in Beta2.
5. I see this has been requested throughout the years. We’ll prioritize adding in like a decorative checkbox to make sure these accessibility guidelines are met.
6. Yeah there is an issue with the regular “Dropdown”, the Navigation Dropdown uses a separate system and that has thrown me off. We’ll have this fixed in Beta3.

#4

1. Yeah comes in really handy for some design things. For example I used it on the table of contents here and it’s a nice touch. As @eres mentioned could be cool to even have a sticky option within the div element.

2. Performance issues were minor. Some had to do with drag target but now I’m not seeing them as often so perhaps it was something on my end.

3. Recorded a video in secure note for you.

4. Roger that.

5. That would be slick.

6. Awesome!

2 Likes
#5

+1 for sticky div!

3 Likes
#6

7. Adding an item that just surfaced on a build today: If you add an interaction effect to a slider with Marquee enabled all works (transforms, etc) but the duration is ignored.

Disable Marquee and the duration works again.

Screen Shot 2023-10-18 at 3.02.06 PM
Screen Shot 2023-10-18 at 3.02.06 PM851×905 51.5 KB

1 Like
#7

8. Perhaps I’m doing something incorrectly but I noticed that sticky headers don’t work like they used to (not sure this is a beta thing).

  • Adding a logo in an image element and enabling “scaling” doesn’t doesn’t have any effect.
  • Using the “sticky shrink” parameters requires an offset value in addition to the shrink amount to work.
  • If there is an offset value, however, the shrinking effect is then lost and it just looks like a separate bar popping down from the top vs actually scaling the bar in-view.
1 Like
#8

I think after beta3 I’m caught up with 1-6.

7 Very similar to that div issue you were experiencing, the specificity of the selector is overwriting this elements transition time. Which is not something I have ever encountered with CSS before actually. I’ll have to take another look at this one. We can get this handled after or during the release.

8 I did change this earlier in the year. The problem originally being that every very top fixed header would flicker after you scrolled 1px. It seemed unnecessary to force the fixed state to wait for a scroll as the default behavior. To bring back the functionality I’d like to have a “shrink offset” control and prevent the offset being controlled at the same place unless explicit using it as that. We could even default to 1px to bring back the old look and feel. My real ideal is an agnostic scroll position based styling system similar to what you see in this Elementor doc, but don’t have any intention to remove the current control.

Thanks for the notes. Have a great day!

1 Like
#9

That’s great. Thank for all the hard work @charlie!

One more I noticed:

9. If you setup a query in the new query builder that breaks things. Then switch to another provider format like query string. The breaking change remains on the frontend of this site. Need to fully reset the query builder fields even though I’m not using it.

#10

10. Not sure if this is new to the beta but it looks like many (most) of the mini-cart native customizations are not working. Things like thumbnail size, button colors, item padding, etc.

#11

9 I will release a fix where the meta query add-onchecks that it’s the query-builder looper provider. From the debug notes you posted that will fix the warnings from happening. Appreciate that!

10 I am not seeing this however, I have reverted this bugfix outlined here in the current beta branch Update to Pro 6.4.0 b3 - image element width issue and this issue affected a lot of elements so it’s probably already fixed in the next release. Is this custom CSS we are talking about or just the controls? Let me know if this persists.

Have a great weekend!

1 Like
#12

Thanks @charlie. You as well!

Regarding #10 this video walkthrough should help showcase the issue. Oddly enough while I was putting the video together I noticed that it appears that the element renders differently (and with the issue) on a WC Single Product page vs a standard page. In a nutshell though:

On a standard page: Issue appears to just be with preview rendering of buttons
On a WC Single layout: Issue is throughout

You’ll also notice that they render the image in a completely different order even though they are the same element.

1 Like
#13

I checked a couple of builds and this seemed fine. It does sound like the issue I mentioned from before so we might be good. If you still have this issue after the RC releases, could you send me a site to look at?

Does adding this help? Any WC plugins on this site?

add_filter("cs_debug_css", "__return_true");
#14

Hi @charlie – just wanted to followup on #10. I’ve disabled every plugin except for WooCommerce core. Also updated Woo to the latest version. Still didn’t change the ability to edit the mini-cart when on a Woo Single Layout.

11. One new one. If you have dynamic rendering enabled on an off-screen element (modal or canvas) and you have a gravity form with ajax enabled inside of that off-screen element it breaks the submit button and ajax confirmation but does still submit the form (even though it doesn’t look like it on the frontend).

#15

Have just updated to 7.4 (love what I’ve seen so far).
Following @DoncoMarketing’s point 11 - the submit button on the form doesn’t work with dynamic rendering on. Turned off and with AJAX on it submits fine but then stays in the submit status if you close and then reopen the modal without refreshing the page.
It’d be great if, with dynamic rendering and AJAX on, that the form submits, shows the message and on modal close resets to the default form state.

#16

10 okay appreciate the info. I’ll have that fixed next release. It’s a jQuery load timing issue, but I think this fix should fix some issues we were having with the product gallery in the preview.

This color was missing an ID so I added one. I was trying to cross some things off at the time, but it wasn’t the issue.

image

11 Unfortunately if a JS based element outside of CS isn’t setup for Dynamic Rendering it’s probably not going to work. It rewrites HTML internally when the modal opens. However, a general form reset is something we can add to our off-screen elements. I don’t think it would be tied to Dynamic Rendering though. Maybe even another control or it just works like that by default. I’ll add in the request for sure. Have a great day!