Hello,
I am trying to develop an interface in perspective that is truly dynamic in regards to the screen/viewport size of the viewing device/window. To clarify: Dynamically scaling base components to different and/or actively changing screen resolutions is simple enough using flex containers (or even % coordinate containers), but getting the embedded text elements to scale the same way has been an entirely different challenge.
I'll spare you the ear-beating of how I got the text-scaling to work decently well; My current problem is getting icons--specifically those embedded into other base components--to scale nicely and dynamically like the other elements on the page (including the button itself).
Specifically, I have a simple button component with both a text label and an icon defined within its component properties. Now, I can use my dynamic font-scaling trick to get the button text to scale up/down proportionally with changing screen/viewport dimensions, but I noticed that the embedded icon's width and height properties will only accept unitless integers for their respective values (those integer numbers representing fixed pixels; see screenshots #1 and #2 below). Because of this, if the screen size changes, all of the graphical elements on the screen will scale up/down proportionally except for the button's icon, which remains at a fixed "_px by _px" size despite the changing size of the button itself.
Here's where it gets interesting (and confusing): If I try to set a percentage value for the embedded icon's width and height properties, I get an error that reads "string found, number expected" (see screenshot #2 above). However, if I ignore this error/warning message, the icon actually does scale in size dynamically precisely the way I want/expect it to...
Refer to screenshots #3 and #4 below to see what I mean. In both screenshots, the top button (labeled "SETPOINTS") is using "invalid" %-based values for the icon's width and height properties (and thus are currently throwing errors/warnings in my designer), while the bottom button (labeled "METRICS") is using fixed integer values for the icon's dimensions (as seemingly intended). Screenshot #3 shows what both buttons look like when the interface is displayed on the "base" screen/viewport resolution that the interface was designed around. Both icons look fine, because their fixed properties were designed with this specific resolution in mind. In screenshot #4, you can see what happens to each button's icon when the viewport is shrunk down significantly. As expected, the "METRICS" button icon looks way too big for the rest of the button, since its pixel-by-pixel real estate did not shrink with the viewport resolution. However, and more interestingly, the "SETPOINTS" button icon does actually scale down proportionally with the other components/elements. This is exactly what I am aiming to accomplish, just ideally without throwing errors/warning in my designer!
So, a few questions:
- Do the above-referenced "width" and "height" properties for embedded icons really only support fixed integer values ("pixels"), as my designer is indicating? Or am I perhaps seeing some sort of "vestigial guardrail" that was accidentally carried over from a version of Ignition that didn't support % values for these properties?
- Would it be a bad practice to use % values for these icon properties, despite the designer's warnings, since doing so results in the functionality I am seeking?
- If % values are fine to use for these properties, is there any way I can disable the associated warnings in the Ignition Designer?
- If using % values is not recommended, is there any alternative method I can use to dynamically scale the size of a button's embedded icon? I was flirting with the idea of using "page.props.dimensions" properties in an equation to yield a pixel-by-pixel icon size that scales dynamically with screen or viewport dimensions, but that seems like it could get real messy real quick...
Any input/feedback is greatly appreciated 
Whatever value you set is going to emitted verbatim into the DOM, so look in the browser devtools to confirm, but it doesn't surprise me that this 'just works'.
Answering #2, the only case where this would get you into trouble is if you've set the button's image.position to center, because then we do rely on the value being integer pixels:
if (image.position === 'center' && textNotEmpty) {
const imgHeight =
image.height != null ? image.height : imageDefaults.height!;
const imgWidth = image.width != null ? image.width : imageDefaults.width!;
return {
...baseImageStyle,
position: 'absolute',
top: `calc(50% - ${imgHeight / 2}px)`,
left: `calc(50% - ${imgWidth / 2}px)`,
zIndex: 19,
};
As for #3, no - you either have to change the values or live with it.
That said...I'd probably just live with it, myself 
Workarounds may be possible using the stylesheet or whatever, but having the behavior be 'local' to the thing you're editing is pretty nice.
This is fantastic insight and exactly the information I was looking for. Thanks a bunch, Paul.
I inspected the svg element of my button icon using chrome's devtools like you mentioned, and the % values are indeed reflecting in the DOM with their units included. So, as long as this functionality remains consistent, I will just ignore the warning in Designer and move on with my life. I mostly wanted to know that I wouldn't be shooting myself in the foot later by doing this, so thank you for providing me that peace of mind.
Also, thank you for pointing out that specific scenario with the "image.position" set to "center"; I was already thinking about setting it up that way for the mobile view (with the button text removed to save real estate), so having that extra detail in mind will save me from heaps of trouble later.
Cheers!
You'll likely end up diving into the world of rem units and cqw.. Enjoy - some things are relatively easy to get to scale, others not so much. As you saw, just because a field says it wants a px value, you can shove other things in at times as long as it's valid for CSS. But others, like dock sizing, are only px. Working around that gets quite complex. I've got it mostly figured out other than I currently can't have the docks be resizable.
You'll find a number of topics on here with some pretty lengthy discussions with @nminchin
I ended up using a calc() definition for my font sizes to achieve the results I was looking for. The calc function takes both vh and vw into account, and then applies three scaling factors (one general and one for each dimension) to make the scaling mostly consistent across a range of viewing resolutions. I actually took this idea from a 2022 article written by Sam Alvares (DMC) on Dynamic CSS Font Sizing, and I found it to work very well after playing with the scaling factors.
Funny you mention dock sizing specifically; I was just brainstorming on how to make the dock scale dynamically as well, but I decided to just leave the dock + header fixed in lieu of spending hours in another rabbit hole 
But now that you mentioned a workaround for scalable dock sizing, I am very curious if you would be willing to share how you accomplished that. Did you end up referencing the "page.props.dimensions" properties? That's where I was heading, but if there is a different approach/solution I would love to hear it!
This appears to mostly work. I only am handling bottom and left dock pushes, as that is all I have pushing. My right is cover, and I don't use a top.
I set the variables elsewhere in rem units.
Push docks have to be un-resizable. If you figure out how to handle resizing, let me know.
/* =========================================================================
DOCKED VIEW SIZING
========================================================================= */
.docked-view.docked-view-left { width: var(--left-dock-width) !important; }
.docked-view.docked-view-left[style*="left: -"],
.docked-view.docked-view-left[style*="left:-"] {
left: calc(-1 * var(--left-dock-width)) !important;
}
.docked-view.docked-view-right { width: var(--right-dock-width) !important; }
.docked-view.docked-view-right[style*="right: -"],
.docked-view.docked-view-right[style*="right:-"] {
right: calc(-1 * var(--right-dock-width)) !important;
}
.docked-view.docked-view-bottom { height: var(--bottom-dock-height) !important; }
.docked-view.docked-view-bottom[style*="bottom: -"],
.docked-view.docked-view-bottom[style*="bottom:-"] {
bottom: calc(-1 * var(--bottom-dock-height)) !important;
}
.docked-view.docked-view-top { height: var(--top-dock-height) !important; }
.docked-view.docked-view-top[style*="top: -"],
.docked-view.docked-view-top[style*="top:-"] {
top: calc(-1 * var(--top-dock-height)) !important;
}
/* Catch Left/Right docks when Bottom is pushing, regardless of Designer px settings */
.docked-view.docked-view-left:not([style*="height: calc(100% - 20px)"]),
.docked-view.docked-view-right:not([style*="height: calc(100% - 20px)"]) {
height: calc(100% - var(--bottom-dock-height) - 0px) !important;
}
/* Adjust main view to deal with dock widths */
.center:not([style*="max-height: calc(100% - 20px)"]) {
max-height: calc(100% - var(--bottom-dock-height) - 0px) !important;
margin-bottom: var(--bottom-dock-height) !important;
}
.center:not([style*="max-width: calc(100% + 0px)"]) {
max-width: calc(100% - var(--left-dock-width)) !important;
margin-left: var(--left-dock-width) !important;
}
Impressive work, thank you for sharing! I haven't started polishing my docked views yet, but this is a great reference to have for when I do.
I doubt I'll be able to contribute much more to what you have here, but if I do, I will certainly let you know! Thanks again!
Thanks. Lots of help from Gemini and watching what changes in Chrome's Dev Tools when you expand/collapse the dock.
