I think these are actually two separate problems.
- Tweaking very specific details
- Wanting to do stuff beyond the scope of the course
The former is potentially harmful.
Stress that they will get no points for having a good looking website and that they only get points for functionality.
Perhaps even enforce this by restricting the students to using a colour palette that you have selected or requiring that they only use default colours if the environment provides them.
If students are forced to use a restricted colour palette then they cannot spend time tweaking the colours.
Perhaps also consider being specific about where their elements should be placed. For example, require that button X should be in the bottom right hand corner and that button Y must be in the left hand corner.
They can still move things by a few pixels if they're that obsessive, but they won't be burdened by the desire to keep reshuffling all the elements.
Alternatively, make the students design their UI before doing any programming and penalise students for deviating from their design for cosmetic reasons.
(Allow deviations for things that genuinely cause an issue, but require that the student documents the issue.)
These suggestions not only kill the problem, but they also force students to exhibit skills that they might need in a work environment (documenting changes and fulfilling the customer's requirements).
The latter on the other hand should be encouraged.
Wanting to learn beyond the scope of the assignment is a good thing.
It's a sign that the students want to be doing this and that they have the potential to become good programmers because they're inquisitive and willing to put in effort.
Don't crush this, simply tell them that they are only allowed to do extra things like that when they have fulfilled all the other requirements.
Perhaps enforce this by making students show you their work when they are finished so that you can give them permission to start adding extra functionality.
Make it clear that the assessment is about providing "what the customer wants", not about showing off, and that any 'extra features' will be completely ignored and won't impact anyone's grades.
There's also nothing wrong with admitting that you don't know the answer.
A little anecdote:
(TL;DR: encouraging students to check the documentation instead of asking you is a good thing in the long run.)
When I was learning programming at college my programming teacher didn't know how to use the open file dialogue in winforms, so I simply went away and asked the internet instead. That was a good thing, it gave me practice at referring to the documentation and made me realise that in fact my teacher did not know as much as I originally thought.
Once I had gotten used to the documentation I stopped asking my teacher and started referring to the documentation first.
Before long my teachers were sometimes asking me questions.