Some issues / questions regarding hover effect / colors / scrolling

first of all: I am thrilled with the purchase of foundry and really linke the overall experience. I am getting close to finishing my website and was pleased that using third party stacks is not a big deal at all.

but some aspects are a mystery to me … :slight_smile:

if I understand it correctly, hover colors are kind of an automatic process (darker tone of the link color)
in my opinion it would be nice to leave that decision to the user an offer a color swatch in the custom color dropdown for defining hover colors to my needs.

for example: if I have chosen a dark link color which works fine on white background, it gets unreadable - at least least less striking - if the automatic hover effectt (darker tone of the link color) is used on dark backgrounds (e.g. for modals, sideslips, the focus stack etc.)
to sum it up: colors are an essential part of the design process and I simply consider it to be a limitation in means of concept and creativity that the hover color is predefined by the developer :wink:

another effect I noticed is:
when I choose to make button stacks “block buttons” the hover effect colorizes the entire button (fine)
if I choose to make a sideslide stack button a “block button” the hover effect only colorizes the “button label” area (the text area) these different kind of buttons side by side are looking pretty unprofessional.

what would also be nice: instead of having a strikeout option für text links hover effect (who uses strikeout???) it would be nice to see other options like bold / uppercase, colored background etc.)

last but not least I am getting mad about a “funny” scrolling behavior in edit mode which takes me way to the top every time a make a little change to a stack at the bottom. I ended up to place the layout part I am currently working on to the top and putting it in place after the changes are done.

first of all: I am thrilled with the purchase of foundry and really linke the overall experience. I am getting close to finishing my website and was pleased that using third party stacks is not a big deal at all.

Glad you’re enjoying it.

if I understand it correctly, hover colors are kind of an automatic process (darker tone of the link color)
in my opinion it would be nice to leave that decision to the user an offer a color swatch in the custom color dropdown for defining hover colors to my needs.

for example: if I have chosen a dark link color which works fine on white background, it gets unreadable - at least least less striking - if the automatic hover effectt (darker tone of the link color) is used on dark backgrounds (e.g. for modals, sideslips, the focus stack etc.)
to sum it up: colors are an essential part of the design process and I simply consider it to be a limitation in means of concept and creativity that the hover color is predefined by the developer :wink:

Simplicity is key for me in Foundry. While it seems like a small aspect adding in an additional color picker for anything that has a hover property is a lot. I won’t rule it out, as I don’t like to rule anything out totally, but currently having a secondary color picker devoted to hover colors for each item with a hover property isn’t on my roadmap at this time.

when I choose to make button stacks “block buttons” the hover effect colorizes the entire button (fine)
if I choose to make a sideslide stack button a “block button” the hover effect only colorizes the “button label” area (the text area) these different kind of buttons side by side are looking pretty unprofessional.

From the sound of your report it seems like a bug. Can you ZIP up your project file and send it to me at adam at elixirgraphics dot com and indicate which page I need to have a look at with this problem so I can investigate it?

what would also be nice: instead of having a strikeout option für text links hover effect (who uses strikeout???) it would be nice to see other options like bold / uppercase, colored background etc.)

Bold and uppercase have a tendency to adjust line-heights, widths, etc. This would result in related, adjacent text jumping around. This is why they are not options. Colored backgrounds would require padding on both sides. This would require the link to have the padding applied before the hover, or to apply the padding when hovered over. The former adds odd spacing about the link and the later creates the same effect as the bolding, which results in adjacent items jumping around. Hope that clarifies why I chose not to have any of those as options for link hover types.

last but not least I am getting mad about a “funny” scrolling behavior in edit mode which takes me way to the top every time a make a little change to a stack at the bottom. I ended up to place the layout part I am currently working on to the top and putting it in place after the changes are done.

This indicates something out of place on the page… This not a bug with Foundry but is a problem that is mostly seen when there is a wrongly specified Google Font name on the page or custom code that is not correctly setup. It can happen in any setup within Stacks. If you send a ZIP file containing your project file to me, and indicate the page you’re seeing this problem on I will take a look at it.

I get your point – you want to avoid adding color pickers all over the place
but what if you give the user a bit of global control e.g. within the global settings of the foundry control stack…?
if I could choose a global hover color among the given brand colors that would already mean a huge progress to me.
or maybe it would already be helpful to have global choices in addition to a slightly darker hover color: e.g. slightly lighter, complementary color or stuff like that.

imagine the scenario that a client asks for relaunching his website and you cannot use foundry for that task just because there is no option (other than tweaking CSS) to define the exact link and hover color combination the client used in the past…

or maybe it would already be helpful to have global choices in addition to a slightly darker hover color: e.g. slightly lighter, complementary color or stuff like that.

An option to have links either darken or lighten would be a possibility, and a good option. I’d have to look at the Bootstrap code for the buttons and other elements though. Those are hardcoded into Bootstrap, and overriding them, while possible, could prove to not be worth it in the balance. In other words – the framework is used to reduce code. If I dump a ton of extra code into going against how BS works, then I’ve defeated one of the main purposes of using the framework.

I’ll add this to the issue tracker to have a look at when possible.

Also, I’m glad to help with the other to things you mentioned in your original post, I just need a copy of your project file, like I mentioned in my earlier reply, in order to assist with those things.

ooops - i have sent it to the noreply@elixir.support :slight_smile:
i send you a message via the board instead…

OK. Got your project file –

I’ll start first with the Side Slide button issue. Not a bug thankfully. I took your footer and isolated it in a project file of its own so I could see more clearly if there were any problems with conflicts. Turns out you set the background of the button using the default Stacks’ background color picker. This isn’t used for the button, or the stack as a whole really. You can see what I mean here:

So first things first, turn that off. Also, it seems you’ve not turned of the Block Button feature in the Side Slide’s button, as can be seen below:

Go ahead and enable the Block Button feature. You should now be good to go after those fixes.


As for the page jumping back to the top when editing certain things on the page –

You’re defining Open Sans’ font weight at 200 in the Headers Pro stack. Open Sans does not have a 200 weight font. It starts at 300, so this is throwing an error and in return Stacks doesn’t know what to do, and is jumping back to the top of the page.

If you fix any wrongly setup Google Fonts you should see your problem go away. Always be sure to check to see which font weights Google Fonts supports. In this case this is the available font weights for Open Sans:

3 Likes

thank you so much, Adam!! That was A++ support!

and - uh - such silly mistakes!!! (… as always when something does´t work as expected) :wink:
I thought that header pro is providing all the options which are available in the dropdown… should have known better.

again: thumbs up for helping me so quickly!

thank you so much, Adam!! That was A++ support!

Not a problem.

I thought that header pro is providing all the options which are available in the dropdown… should have known better.

Unfortunately a stack has no way of knowing that info. We can’t populate fields, drop downs, etc. based off of outside sources. They have to be hard coded into the stack.