Is it wrong to expose data and actions that should (inputs, and buttons) be made on these data in tables?
Example in the figure below is showing data and actions that should (inputs, and buttons) be made in the form of a table (in red) marked with a green arrow this header and blue table contents, this form of exposure is correct (remembering tableless )?
Right or wrong is relative. I doubt that there is a definitive answer for each case. You have to do what is ideal for the situation. In fact you need experience to hit every case, especially when it seems like two solutions are workable. And this is important. The problem of using the table as a formatter (what happened in the past) is that it made it unfeasible, for one reason or another, a lot.
For me, I do not have a lot of experience with web development, especially over current technologies, at first I would not see much of a problem in using a table in this case because you are going to build a data table. It's clear, especially from the header, that you have a table there.
But you have to ask yourself if you are dealing with a data table or only with presentation formatting. This should be the criterion.
If it's a table, it seems to be, have to see if it's made up of multiple rows and just one column. Or whether it will have multiple columns per row. Again you must ask yourself if this row data is separate from the table, is it really a cell, or is it separated by formatting only. Having multiple columns does not look wrong.
I do not like having action buttons in a column. They are not dice. But I'm not saying it's all wrong. The checkbox is also an action and I think few people will say that it is an abuse to put it on the table.
I still think they should be somewhere else, possibly in a split on another layer and maybe even just appear when passing the mouse . Even if they get fixed they look like intruders in the middle of the data. The "Status" also has a button but it does not seem intrusive, it seems suitable as UI to change the state of the contained data there. The problem with others is that they appear to be related to the whole line and this needs to be better demarcated.
Maybe a hybrid will go well, as in almost anything. You can use divisions pretty much anywhere. Use table where table is but where it is not clear that an element is a data cell, use the division.
Making it clear that the exclusive use of divisions is perfectly doable as well and some people would prefer this path. An example . This solution can give you more power and flexibility, although it is slightly more complex to build a table. Consider these points. What is more important in this case? Think about the future too.
I gave a researched in known projects what was the choice and its motivations. It seems that no one has a definite word because they chose to use divisions exclusively. They are probably more guarded using something more modern and complete. I have seen in many cases that they could have used table without problems. That is, it does not really seem right or wrong but there is a clear preference for divisions.
Of course this makes a lot of sense in libraries that will be used by many, the extra work (which is not even great) pays off. For a quick thing I do not know if it makes up for it. But also if you do something that can be reused at other times, maybe it will pay.
I gave you some subsidies, talking about what is right will be my opinion.
