> +pre{
> + white-space: pre-wrap;       /* css-3 */ 
> + white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
> + white-space: -pre-wrap;      /* Opera 4-6 */
> + white-space: -o-pre-wrap;    /* Opera 7 */
> + word-wrap: break-word;       /* Internet Explorer 5.5+ */
> + padding:1.0em;
> +}

We also have something similar here:
http://hg.python.org/tracker/python-dev/diff/7661716411a5/html/style.css


> html/issue.item.html
> ====================
> <textarea tal:content="request/form/@note/value | default"
>             name="@note" wrap="soft" rows="5" cols="80"></textarea>
> 
> (I changed the wrap="hard" to wrap="soft", and in combination with the 
> <pre> stylesheet-settings, it wont break long urls, because then they 
> become unclickable, and also it will prevent the 'search'-field 
> dissappearing from the screen which happened with long content)

We removed it altogether from our instance because it's not valid HTML
(http://www.w3.org/TR/html401/interact/forms.html#edef-TEXTAREA) and it
was causing problems with Konqueror
(https://bugs.kde.org/show_bug.cgi?id=220005).


> Think about it: first information, then editing-forms :)

We experimented with something similar but it didn't work too well.
This is a solution we tried:
http://hg.python.org/tracker/python-dev/rev/fa0c45837434
This was something similar but applied to the history at the bottom:
http://hg.python.org/tracker/python-dev/rev/525d3e387a65
Both got reverted, mainly because people didn't want to go through an
extra click before being able to reply to the issue and/or to read
information (it should be mentioned that this feedback came from
developers, hiding the form is probably OK for casual users).  Our
solution didn't completely hide the form, just turned it in a shorter
read-only summary of the most important fields.

We also try to keep the UI as clean as possible, avoiding extra clutter
and unnecessary information (or at least that's the general idea) -- you
might find some of ours solutions browsing the hg history.

Your big "edit" button seems nice though, so maybe we will experiment
again in the future.  (FWIW bigger buttons are a usability win, so I
made the "submit changes" button bigger:
http://hg.python.org/tracker/python-dev/rev/7540b96110c9)

FTR you can find this on http://bugs.python.org/



> But I can see it being a valid use case, I just think it makes for a
> poor work flow so should be optional and controllable on a per tracker
> basis by an option (rather than having to cut the code out of the
> template).

Not sure that's a good idea.  I think providing a default template and
let users customize it as they want it's already OK, otherwise you might
end up with several (possibly conflicting) options for different tweaks.
 OTOH it would be nice to collect somewhere snippets that can be added
to the default template to obtain different results.