I made a little video… sorry it’s a bit rambly and my voice is a bit scratchy… but i walk through:
your example (or something close to it, i think) and come to the conclusion that you’re right – you don’t get the color you expect – and that sucks
then i walk through a way to guarantee that you always get the color that you want – and that’s awesome.
And then I ramble on a bit about ways to test these things and even a way to get some agreement between ALL OF THE THINGS – or, well, most of them anyway. Give it a look.
@isaiah Wow what can I say, but many thanks for such a thorough and long detailed video.
Your video shows the core issue when setting a particular colour using the stacks colour well when compared to adding the colour as CSS. I noticed that you used an already corrupted colour code as the second colour comparison, and that as the corruption is more noticeable with some colours such as #0F76ED than others, it may not suffer any further corruption.
However, and this is a huge however, you did the terrible thing which is the RW equivalent of eating all the yellow snow and then crossing the beams and then dousing the Gremlins with water. You used the MacOS picker which is the event that triggers the corruption, and then used a picker to examine the colour.
If you wanted to, and not suggesting you need to, you could do the following experiment.
Firstly reboot your Mac (to reset the bug) and then using your new test colour stack, add #0F76ED as a colour directly into the Pickers hex box and into your CSS box. The colours will look the same but do not use the eyedropper or loupe or picker examine tool. Instead, check the page code and you should see #0F76ED. As a control, here, use another of your favourite web creation tools that use the MacOS colour system. E.g. I can repeat this using Blocs App with the same correct colours. I can also safely use SiP to pick a colour correctly from the screen. So the hex colour value had made it’s way into the code. All good so far.
Now here comes the issue trigger. Use the MacOS eyedropper or loupe or picker examine tool to examine the blue colour (or any part of the screen I suspect).
Now repeat the same RW thing with some random colours to force a colour change, and then repeat with #0F76ED and you will now see the colour difference. Check the CSS and you will see a different colour in the code for the stacks colour well colour and the correct colour for the css entered hex code. So the bug is now triggered and will remain triggered until the Mac is rebooted AFAIK.
Now here is an interesting thing that I found today. Repeat this with Blocs App, and the blue now looks wrong in the preview and also in Chrome as expected. However, and I wasn’t expecting this one, checking the Blocs code, reveals the correct #0F76ED in the code. So it looks like maybe the calibration is altered. In addition, using SiP to examine a colour produces the wrong colour. So SiP is now screwed.
So there is a lot happening here and most of it, is outside of our control.
The quick solution as outlined at the top of this thread, is to use a CSS method to set important colours such as BG colours as this will always work correctly, instead of adding colours into a colour well. There is I suspect an ongoing risk that if you re publish a site in the future, when the bug is triggered, that your newly published site will have corrupted colours for colours entered into the colour well.
When I have time I will investigate adding an rbga input method to one of my stacks the uses the colour well. Not sure at this stage if this will work alongside the colour well, but that would be my ideal solution to guarantee that the colour code you enter is used in the code.
I created this video using Blocs to show how colours can be entered into the code correctly when the bug is triggered and to also show how the screen colours or SiP are also corrupted. I think the screen colours are corrupted because the blue looks wrong to me, so perhaps SiP is working correctly. Not trying to say Blocs works and stacks doesn’t but this is another piece of this puzzle that may be useful.
Are you saying that an existing colour in which you have typed/pasted a hex code or RGB values into the color picker actually changes when that colour well is NOT SELECTED in the stacks settings?
As per @Isaiah’s video, when using the generic RGB colour palette I can never get an existing colour to change in the stack settings -i.e. I can perfectly reliably set an unequivocal colour and know that this is the code that will be rendered into the web page.
So, for me, the way to “create accurate BG colours” is merely to use the RGB palette and exercise click caution when a colour well is selected. I habitually click on another setting so that the colour well is never left active.
No. This is about entering a colour as typed/pasted hex code or RGB values into the colour picker. The colour value always remains the same when examined by the reading the value in the picker - not by using the eye dropper to examine the colour. I only ever select colours by pasting a known colour code directly into the colour code box.
Yes, I get that bit but I don’t understand when you get a different hex or rgb value actually written to the web page after doing do - i.e. steps to reproduce in order to get a different hex or rgb code written to your page than what was entered into the colour picker. I can’t get mine to change ever.
I don’t get how I don’t get the same hex value written to the web page every time! The issue is intermittent and occurs after using a picker to read a screen colour. Also as it doesn’t affect all colours in the same way, you may not notice it without examining every colour to check for it. It is most noticeable when used for single colour large area BG’s, using certain colours such as #0F76ED, and it helps (or makes it worse) if you are not colour blind. It never effects white or black.
we’ve gone round and round here. i think i’m with @tav, in order to move forward a set of steps seems like a good idea.
let’s take a step back and start fresh with a simple set of steps we three can all do precisely. this will let us all talk about the same thing and be precise.
make sure to note at which step things behave unexpectedly and what you expect the value to be.
This issue is proving a really slippery one to define what causes it. The issue has now corrected itself for me and I didn’t do a restart, but what was previously an intrusive problem is no longer a problem.
I have created a simple project here that when previewed, will illustrate the colour corruption if the issue is present.
Basically if you have the issue, you will see 2 shades of blue and if you don’t have the issue, you will only see a single colour.
If you try it and find that you see the 2 shades of blue, please report it here and if you can, also report what may have led up to it starting to happen. E.g. if you used the colour picker to sample a screen colour then that would be good information and your version of MacOS would be useful to know too.
Looks fine. I should say that most users will probably not see the corruption, but if you think that your colours are not quite right, then you can use the test project file as test to confirm it.
If there is a problem then you should see something like this:
This is somewhat puzzling. Using Digital Color Meter, I checked all colors in my sample and in yours.
My sample reads:
R:58 G:119 B:234 (does not correspond to neither of your samples)
Your upper sample:
R:0 G:94 B:227
Your lower sample:
R:0 G:119 B:232
So, now we have three different color values in the same screen readout. I’m guessing this is due to the difference in color calibration of our monitors?
Ignore what any colour reading tool shows. You may see variation from pixel to pixel. Also the act of using such a tool may trigger the issue.
Use the Page Inspector to examine what exact colour is being used is what matters. (Right click on a portion of the BG colour in Preview and with a bit of perseverance you should be able to see the colour that the BG is being set to in the code).
I did not explain myself adequately. I know what you mean, but no matter how critical a color might be to us, other people will inadvertently see the same color values in different ways. So, perhaps we should not be too particular about critical nature of colors in our designs, since every viewer’s monitor, tablet and phone is representing these colors in a different way. Most people NEVER calibrate their screens, they have no idea how to do it and they simply don’t care. I do care, because I am a photographer, but I gave up long ago on preaching the importance of monitor calibration.
And I’m sorry if I strayed from the main point you are making about color-well values being corrupted.
No I understood your point. The inconvenient issue that I find with colour corruption is that if you butt 2 stacks up to each other, and you want them both to have the same colour, then you need 100% accurate control over the colours. A good example is trying to create an image mask with a BG colour to butt up to a page section with a solid colour entered via Stacks. So you create an image in your graphics app with a BG colour of #0F76ED and then set the BG of a page element in RW to be #0F76ED and then when previewed, they don’t look like the same structure. If the colours are not exactly the same then the effect is lost. The same thing happens when creating your own shape dividers and many more advanced techniques…
The other issue is that the colour is no longer a good match for the pallet you have chosen.
I cannot tell you how many hours I have wasted on this issue over the years.
That’s why using BWD and Source SVG and Custom CSS BG’s is a such a good solution, for this issue, if you have this problem.
My way of dealing with any perceived difference in color between web design elements and graphics made in external apps is to make a graphic first and then tweak the color in RW to match that of a graphic element. That, at least partially, alleviates the color-corruption issue.
Your project is not especially simple and requires many stacks that i don’t have. That likely includes hundreds of lines of CSS. This muddles the issue with many other things and makes it tough to follow.
If you can state this clearly in a few steps or demonstrate in some built in stacks I’ll follow up. :-)
I tried to build a simpler one but it’s a balance of having to use a simple theme everyone will have and some stacks. This Source based one is using the super light weight Source theme and the project is simple and lightweight in many ways. This particular layout has proven itself by showing the issue so we know it works.
The project is just 2 containers with a Header and Paragraph in each. The first use the colour well with the colour #0F76ED pasted in for the BG, and the second has the same BG colour set via CSS.
It is more about trying to gather the evidence of steps that lead up to the issue being triggered. If we can create these steps and cause the problem then it would be a 2 minute build to create a stack with a colour well BG and a 2nd stack with a BG colour set via CSS that will show the corrupted colour in the code.
I think @Isaiah is referring to a test case like this:
I’ve used the built in RM Affero theme and just two Stacks One Col stacks each with a text stack inside them just for identification.
The first has the background colour set via the colour well in the settings.
The second has a custom class assigned to it via the stacks settings (.bg-col) and the CSS code is in the page inspector as follows:
.bg-col{
background-color:#0F76ED
}
@Webdeersign or @everyone If you can now provide a few simple and reproducible steps that cause these colours to be different when rendered to the page then there will be something concrete to go on.
(Obviously you should not resample the colour well in the settings on itself or another copy of the colour as this would involve the monitor calibration.)
Slightly off topic but I did exactly what you did but using the Blank theme. It is so blank, I am not sure where it came from but I think it is Joe’s theme… The CSS BG would not work and I could not figure this out. If I change your theme to the Blank theme, then that also doesn’t work and the CSS colour doesn’t show. Why is that?
the point is not that i don’t have it, it’s to avoid contamination from other possible sources of error.
every added stack, every added theme, every added line of code – all of it – has to be eliminated by someone in order to separate wheat from chaff and find the kernel of the bug that is responsible for the problem.
i gave it my best but apparently “crossed the streams”.
@tav has provided a perfect template for this bug report. the only thing left is to make the bug happen. and only one person really knows how to do that.
if it can’t be made to happen within this template – then i think it’s safe to say the bug lies somewhere else – either in the other stacks and themes of your previous example, or perhaps just s simple mistake – a typo – in a files somewhere, or maybe just a misunderstanding.
