How are container components ordered?

i come from a long webdev background. in my containers (which i see as <div>s [thank you @pascal.fragnoud]), i drop in components but have no idea how they are ordered. so if i want to target items with CSS, i'm not sure how to 1) target components and 2) properly cascade styles. i am trying to use the interface as much as i can because my wont is to just open up a stylesheet and go hard, which i'm sure i will at some point once i understand how things are targeted, etc.

because i can just drop things into a container and place them wherever, how can i translate this in my head to something i can reliably target with styles, positioning, &c.?

i hope this makes sense. because it seems to me the biggest obstacle to getting the final *click* to how this is all hanging together. and to those who've read my other posts, you probably see my coding background has been more of a detriment than a boon, so far.

TIA, you fabulous bunch! :smiley:

From the designer you can create style classes that can then be assigned to the various components and sometimes parts of components.

You can also just add valid CSS to the styles manually and they will be used, though sometimes you will need to use the !important override to insure your style is observed.

Depending on the version of Ignition you have you may have access to style sheet resources which will make all of this seem much more familiar to you.

Finally your browser of choice's developer tools are your friend. Don't be afraid to inspect your views inside of the browser to find the classes and id's you need to develop appropriate selectors when you need or want to do some things that haven't been readily baked into the first party component.

Do a search for @victordcq to see some examples of just exactly how far you can stretch things is a bit of understanding.

With a webdev background, I would say you're a fair bit ahead of the curve when it comes to perspective.

1 Like

Keep in mind though that the class might not be given to the highest level tag of the component.
The best way to make sure is to use your browser's dev tools.


okay. so what i'm hearing is that HOW the components are ordered is the order they are added to the container (this post was very helpful), BUT i can specifically target them and use flexbox ordering to rearrange as necessary. is that correct? if so, that means CSS specificity should be manageable. awesome! :smiley:

to extend this logic a bit, i see the breakpoint container has only two breakpoints. can we override that in a stylesheet and make more? or have i gone too far? we have four different device dimensions to deal with...

I don't believe there is a supported way to override the number of breakpoints for the container, but nothing keeps you from nesting breakpoint containers.

Here is an old, but still relevant post about when to use different container types.

@lrose thank you. that was useful.

my struggle as i am striving for pixel perfect layouts, which is not unreasonable, i can't seem to figure out how that is done. when i started this project i built a working prototype, db included, in six hours just using my usual webdev toolset. i've been bashing at making the same thing in Designer for a week now and i'm still stuck on the friggin' header! forgive me if my frustration is bleeding over here, i see the capability, i'm just not connecting. i think i need a day just to deep dive the manual because how things are broken out are colliding with terminology and structures from a different development world. like POSITION is broken out from PROPS, which makes no sense because position IS a property... things like that are running me into walls that my experience says are tunnels. like having a testStyle and a style in the PROPS. which has precedence? and can i turn off those blue boundary boxes so i can SEE the thing i'm working with??

anyway. i think today i just deep dive the manual and try again tomorrow. there has to be a click somewhere. thanks for the help and patience. very much appreciated.

I wouldn't wait for a 'big click' that will map your web dev experience to ignition.
Some of it will translate, most likely through several 'little clicks'. Like "Oh, those are actually react components !", "So, style classes are just css classes !", etc.
But mostly, you'll learn the tricks of the trade along the road, little tricks, little bits of knowledge, little things that'll make you go "Hey, I can do that !". It will take time, no doubt prior experience will speed the process up, but as you said: It's a whole different kind of dev. Even if it's based on things you know, you just don't use them the same way. It can be frustrating, frankly I curse some 'features' everyday. I'd build things way faster with just html, js and css. But there's just so much power in ignition that it's a small price to pay.

I mean this has always been unreasonable in webdev, since phones has so many sizes.

Something nice to know since you should know how it works. in a coordinate container if set to fixed (not percent), you can set position, width and height with 100% or calc(100% - 15px) ect. (even if the designer might give a warning) Im from a webdev background too and this is something i used a lot when position mattered


God bless you, sir. thank you. you guys are giving me such great help. you do one thing for a decade, it's tough to switch gears. especially when it walks like a duck (kinda), talks like a duck (sometimes), and then feels like a pig. throws a guy for a loop. i think, also, i have to stop thinking like a contractor and start thinking like a staff member: i have some time and that's expected.

You can also add a domId prop to any component's meta property which you can then use to ref in CSS. Ive never used this personally though

@nminchin yeah, i read about that. can't say i'd find it useful either. classes, on the other hand: very much so. given how much is built in to Designer (i'm learning!), it would be a very niche build that would make good use of domId.

thanks for the heads-up.

Could be used to target something that's unreachable through classes, though the recent addition of has in css makes it less useful. Could still make the selection easier/cleaner.

Real case example I've used: I needed to hide something in a power chart. On a very specific power chart, and a very specific part of it. domId made it easy to target the right powerchart, without having to make a special class just for it.

yeah. that's a perfect use-case scenario and exactly where i'd expect that to be used.

i can't say how much i appreciate you guys sharing your knowledge and experience so freely and so kindly. i've been around a long time and getting up to speed on Designer has been the most pleasant software ramp-up experience because of that. :+1: thank you for not being douchebaggy tech-snobs. :smiley: