>>>>>On a positive note - during testing I encountered a message that had a wide code example in PRE tags, plus some regular text not in those tags. The PRE text was too wide for my browser window, which caused horizontal scroll bars to show, which was as expected. However, I was impressed that the regular text fitted properly in my browser window and was fully readable without horizontal scrolling. This was an improvement over the past, when the regular text would also flow out to the full width of the PRE code, and it required horizontal scrolling to read the regular text. I haven't viewed a message like that since, but I hope that improvement is still in place.
>>>>
>>>>Interesting, isn't it? :)
>>>
>>>Nice fix - was one of the few "not so good" behaviours!
>>
>>

Let's make some ultra wide text in PRE tags to see what happens when certain people want to test out supposedly improved text flow, wider still 1234567890123456789012345678901234567890
>>

>>Now some extremely super wide text not in PRE tags blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah
>>
>>UPDATE: the non-PRE text is OK, at the expense of overflowing of the PRE text (see attached image).
>
>For me that works as expected: IMO that is the intent of the pre-tag, where keeping the lines is important in some languages or a char template is meant to span a certain length. So overflowing is out of context. Keeping the lower buttons visible without scroll and not in the middle of overflow is a definite plus as is the ability to read non-author-preformated text broken down well.

Looks nasty to me. IMO the ideal would be to have the message area expand to the full width of the PRE but still keep the non-PRE text within the user's defined browser window. Dare to dream :)