First: have a look at this nice talk, Florian Haas gave at the FROSCON (GER). It is about the practical impossibility of doing scrum at all.
The good news: Since scrum is impossible to implement, you are free to do whatever you want.
The bad news: Don't call that scrum.
That frees you up from the question: »Am I doing scrum right?« (Answer: No you don't) and you could go on to the practical questions of life, that matter.
We do not have a UI/UX designer and the developers work the UI/UX with the product owner
This is a not uncommon situation. But AFAIR scrum is against specialization: everybody should have the same skillset and could work interchangeably.
Everytime we are about to create the backlog and we do not define the exact UI/UX design before the beginning of the spring we end up spending too much time during the sprint trying to finalize the UI/UX design.
Yes, I now that situation all too good. I worked in a team, where we had to deal with very broad backlogitems like »As a user, I want to see information x« and that was it. Then the item landed on the sprint board. One dev took it. Solved it. After implementing it, a first peer review took place, where discussion started about how the UI should look like.
Then the QA-Phase came and discussion started all over again.
After the sprint, we did as scrum demands the review where the design was ripped apart by the PO. Unfortunately our customer didn't make it to the reviews, so he did not see the software at that point.
But then the cycle began all over again until PO was satisfied.
And then came the customer...
From this war story you see, that this (special kind) of process is hellishly ineffective.
What worked for us in the end was throwing scrum over board.
But that's not the solution to your question ;)
Do you think that every possible detail about a feature should be given to the developers before the start of the sprint or should it be a task within the features?
A solution to this dilemma would involve tight feedbackloops between a) the customer itself and the PO, so that the criteria are relatively tight formulated. b) A tight feedbackloop between scrum-team and PO to minimize the chance to drive off the road.
I would break some (more) scrum rules to define one backlogitem: a »working dummy«. Which could be fast reviewed by PO and customer to minimize developertime spent on a simple item.
What should be the input of a scrum team?
Enough information to meet the specs in as little time as possible.
We don't do scrum anymore. We do not do estimations. We kept the sprint board. We don't do sprints. We develop features / fix bugs and release ASAP. When new features are implemented, they go ASAP to a public server where we could discuss further design with customers as tight as possible.