Enterprise: Toolbar: Misaligned close button in searchfield

@rob2d wondering if you could revisit your changes to the Searchfields? It seems this issue's cropping up in a handful of them. The searchfield inside the Lookup fields here has the same issue: https://master-enterprise.demo.design.infor.com/components/lookup/example-index.html

I think it's related to using transform: translateY() instead of pixel values:

• Here's one spot
• Here's the other

I didn't remember this when we talked about the original ticket but we'd specifically avoided doing this type of alignment with transforms in the past (I can't remember the context for why) -- bottom line is we should probably revert this and go with pixel values for alignment.

@EdwardCoyle the y-offset was needed for about 5-6 cases with the last ticket for going too far down into fields/cutting off visually which I couldn't get via absolute positioning because of the structure of how other cases were wrapped in the field (so that spawned the other issues), and there were nuanced cases where it didn't but I missed it.

I'll try to look at this and isolate it next time I check it out -- maybe can inject a class with more context in these specific cases at component level because it seems there's some conflicting rules. Tried to avoid it since it was my first ticket before and wasn't familiar (though... not the most in that one but hopefully enough).

See also https://main-enterprise.demo.design.infor.com/components/swaplist/example-search.html in addition to the minor issue with the field being just down a couple pixels. If you type in the field the X is entirely invisible. I think this could be the same issue as here. So if you want to review that page as well that would be great.

https://github.com/infor-design/enterprise/issues/5080

Two more issue have been posted https://github.com/infor-design/enterprise/issues/5096 https://github.com/infor-design/enterprise/issues/5090

I think they all can be fixed together....

@tmcconechy the first and second issue are actually unrelated.

I targeted the CSS for the second one/fixed and testing... but if it continues, holistically it could be better to re-think these close buttons since alignment is hard coded in many different ways that conflict -- makes sense/understandable if feature were added in retrospect but its just kind of feels a little like wack-a-mole as there was no solution that doesn't create some bad cases without absolute/flex position (that's what caused the first issue where they went down in some cases).

Wack a mole is exactly what it is. But maybe just make some css for each case that works. Im not sure what else you can do as it was done in a way that forced this. See what you can come up with.... End of the day it doesnt have to be pretty just work

@tmcconechy this one is actually a little bit different from the rest; it's actually functional and is an issue we just didn't realize so far -- that is related to styling properly. There's a menu that is getting cut off, so the style was never fixed but it pops in/out of flow. But there is also an is-open class randomly getting removed when flow changes (I think due to this?). Setting the container to display: inline-flex solves the hiding but then introduces the new rules so we can consistently style it.

See the div it's hiding here, it actually is just overflowing in the smaller res.

This seems like a small can of worms, but also heads up that we may need to refresh some screenshots for this one to be fixed properly.

Yeah - understandable with the tests. We'll get it. You might just want to target the fixes more specifically given that this code is older.

@tmcconechy tried to look in and didn't seem feasible to fix very specifically. Tried to look at code generating the classes, but there were some esoteric concepts/rules added there that required understanding/context, one of which is triggering classes to stutter when the flow changes. So will try to restore the menu via an inline layout rule and hope it helps target these issues popping up based on my post above.

OK but there are a few cases like

https://main-enterprise.demo.design.infor.com/components/swaplist/example-search.html -> could target swaplist classes
https://master-enterprise.demo.design.infor.com/components/lookup/example-index.html -> could target lookup-modal

Some of the others can target tabs or toolbar ect. It isnt pretty but if you dont come up with something better.

@tmcconechy yep thanks, on swaplist I have a fix for the class. Was just talking about the one in the screens on this page.

(there is a completely different bug with layout e.g. the menu is just disappeared from overflow but it looks like it was intended to be there? ** or vice versa since it comes back then disappears)

edit: just for context, giphy:

Will focus on just styling for the moment though.

QA Passed. Thank you.