Java Card

The item in this case opens up a small modal page that has the data to be selected. The question now is, the same item and function exists in Oracle APEX, and it has an option to choose between "modal dialog" and "inline". Is there a way to set this in the parameters given to the item?
Is there a way to achieve this multiple search in this custom apex_item.popup_from_lov?
In both cases, the answer is "no". The terms "popup" and "LOV" are all these things share. They are completely different components with totally separate implementations.
Here's how it looks
It looks a bit odd. What APEX version and theme are you using?
Please don't crop screenshots. Show the entire browser window to provide some background context.
Basically this doesn't look like a viable long-term solution. The apex_item API is considered a legacy feature and is not recommended for use in new applications, and the Popup LOV template has just been desupported in APEX 22.1.
I would suggest that you provide an expanded description of your requirements to enable us to suggest a better approach.

Sorry, I was worried about not showing anything data related.
Here is a full screen of the page. My Apex version is 21.2, and the theme is just a css color choice.
The reason for implementing this html generated through the PLSQL procedure is because the idea is to have a report with these "cards" to show, and we want to be able to set what the amount of lines and columns we can have. I've attempted the same with the classic report cards, but the settings to select the amount of columns is limited to what we would like. Only having the options to have a 1, 2, or 5 columns doesn't quite work.
Another issue with using the classic report cards is that, the apex_item generated inside it, even though able to be selected as if to type something in it, acted as a read-only, and there wasn't any way to enable writing in the item.

What problem are you actually trying to solve here?
That's not a UI that I would ever consider creating, which leads me to suspect that everything else about this would be equally alien to me.

Sorry I haven't been presenting the problem properly.
I would like to, if the component is capable of doing so, to have each of these little boxes to have a apex_item.popup_from_lov item (generated through the PLSQL procedure) that opens a window like this, where you can type some information related to what you might be looking for, and the results adjust themselves, rather than having a single column to search.

I would like to, if the component is capable of doing so, to have each of these little boxes to have a apex_item.popup_from_lov item (generated through the PLSQL procedure) that opens a window like this, where you can type some information related to what you might be looking for, and the results adjust themselves, rather than having a single column to search.
No, that's not possible using apex_item.popup_from_lov. It is based on legacy LOVs with 2 display/value columns.
I don't understand what you mean by "the results adjust themselves"?
Why have 50 of them?
What source(s) of data are being queried? Is it the same for all of the items?
What happens next?

The reason for wanting the several columns popup_from_lov is mostly to do giving our users the most options when performing a search. They might remember the description of the entries they are looking for, but sometimes they may want to search for the phone number linked to that description, for example.
The data sets are separate into, mostly, a description, 2 other columns of information, and a phone number. When they typed data matching any of these, they could then select the one they wanted, which then would fill up the boxes shown above.
Using the example I from this "Employee" from the proper apex component popup_from_lov, I would search for Allen and a choice of data would be displayed in the "card".
The idea would be to replicate the display in the popup_from_lov, but in the apex_item variant. It's a shame it's not possible then, I might have to look into other options. Thanks for the clarification, fac586!