Ehren

No promises for 5.0.0, but I'll see if the developers have a solution! 🙂

A couple of issues with that are: 1. You're forcibly removing the background from all areas using !important (which you should always avoid if possible), and then applying a "hard-coded" rgb background to areas which you want to keep. 2. "none" isn't a valid background-color value. This should be "transparent" instead. 3. The hard-coded rgb backgrounds won't change when you adjust the colours using the Theme Editor. 4. There's an extra ; at the very end A safer solution would be to only remove the value from certain elements. And as always, make sure to comment your code so future-you and future-developers know why it was added 🙂 /* Transparent boxes in dark mode */ :where([data-ips-scheme="dark"] :is(.ipsBox, .ipsWidget)){ --i-box--ba-co: transparent; --i-widget--ba-co: transparent; }

I believe this was fixed a couple of weeks ago, but maybe the changes aren't live for you yet. The topic overview had a UI refresh so it no longer looks like that. 🤝

Yes, adding that will remove the background color from all content areas, including popup boxes and the mobile menu. I can look into using different variables for these elements so they don’t all rely on the box background color variable, but since the Theme Editor GUI doesn’t include a transparent/opacity feature, this issue will only occur when you specifically remove the colour in your CSS.

Have you changed any CSS? Those menus don’t use transparency by default. That issue is happening because either the background colour for the off-canvas menus has been removed or the background variable has been broken in the CSS somewhere. The semi-transparent effect which you’re seeing is the “backdrop overlay” which is positioned below the menus but above the main content.

Hi there, Thanks for letting us know. I’ve come across this too, but it’s simply the way browsers handle tall content being appended to the DOM (when the new content is positioned using position: absolute) The footer is already pushed to the bottom of the browser window (even on short pages) using flexbox, but when an element is appended to the document (like the profile hover cards), they’re “absolutely positioned” which means they don’t affect the position of anything else. The footer doesn’t realize a hover card is adding extra space to the end of the document, so it thinks it’s still positioned correctly even though it isn’t. I don’t have a non-hacky solution for this, but I do have plans to revamp the hover cards in a future 5.x update which would solve this, so it won’t be a permanent issue 🙂

ipsGrid has moved to a more fluid concept in version 5. With version 4, you'd typically add ipsGrid and then each child would need to use a ipsGrid_spanx class which told it how many columns to span (out of 12). On tablets and phones, these grids would automatically collapse to 1 column. That concept was fine a decade ago, but with the limitless amount of devices these days, fluid/dynamic concepts are better. In version 5, when you assign ipsGrid, all children are automatically assigned to a grid (the span class is now redundant). By default, grids have an ideal column width of 260px, but you can change that by adding a basis class, such as i-basis_350 which will make all columns 350px, or by changing the --i-basis CSS variable for that element. Columns will automatically grow/shrink/add/remove depending on the available space on the screen. If you need to restrict the grid to a certain amount of columns (lets assume you never want more than 3 columns for some reason), you can add ipsGrid--max-3 to the parent. If you need to use the old grid system and force content into a 12 column grid (like v4), you can use .ipsSpanGrid on the parent, and then ipsSpanGrid__4 (for example) on the children. But the new fluid code is better 🙂

If it’s happening on some devices and not others, it’s potentially a cache thing. Browsers seem to heavily cache favicons and share images. Just to confirm, is it now working correctly on a device which wasn’t working correctly in the past? If so, I’ll assume this is just a browser quirk with cached data rather than a HTML issue 🙂

Hey @Chris59 Can you send me the URL to the affected site, either as a reply here or via DM if it's private? The preview.invisionalph5.com site didn't have a custom favicon uploaded, which is why it showed the "letter in box" design.

Hi @ghinton Is this the area you're referring to? It seems to work correctly on my install:

The is happening because the top widget is set to "Mini Grid" and the bottom is set to "Grid". The UI of Mini Grid was simplified in a recent update in an attempt to reduce bloat, and the decision to favour the original topic creator was made. You'll be happy to know the code for the most recent replier is still in the HTML, so it can easily be shown/hidden with CSS. I just need to make some minor adjustments to the HTML to fully enable this, but you'll be able to easily add the last replier to the UI of Mini Grid in the next update using the following: /* Display most recent replier in Topic Feed Mini Grid */ .ipsData--topic-feed-widget.ipsData--mini-grid{ --i-data--show-last-author: ; --i-data--show-last-reply: initial; }

Good enough reasoning for me. All fixed. 🤝

Yeah you're right. I'm so confident this was working for me in all browsers last week, but a recent Chrome update may have broken it again. I've just removed the blur effect from all browsers until Chrome learns to render it correctly 🤝

Already reported, thanks! 🙂

This technically isn’t a bug as the different size (and colour) is purposely used to establish hierarchy. But I’m happy to adjust it if you think it looks odd 🤝