Symphony.

in s1.7, if there was ever a XSL error, a nicely formatted error page would come up with all the errors without any scrollbar.

in s2, that has since been replaced with an overflowing box with scrollbars with the error message on one line. I find this much more difficult to read since you can never read the entire error message when it exceeds the width of the box.

Alistair said since error messages are of undetermined length this is why it is handled in this manner.

I personally would think the s1.7 (or some iteration of it) would be a more successful and easier way to view these error messages since the entire error can be read without any scrolling, which I find distracting.

Is this something that is set in stone or up for discussion for the final release?

Sure, this can certainly be fixed, but can you firstly give me a specific use-case where the overflowing information is important?

My approach to debugging is to follow the links listed above each XSL file, since the information contained there is usually more imporant to me than the specific processor error messages, and helps me solve the problem faster. Have you tried that?

Not sure that I really follow your commment, Scott. In my opinion, I think it's easier to see the entire error message two to three lines rather than one line that you have to scroll. then you can easily see what the actual error is and what is associated with that error rather than having to scroll.

here's an example of when it overflows

http://s2.whatthedale.com/

I also find the error messages difficult to read because of the horizontal scrolling. However, as you say, Scott, the debug page highlights the problem area in red, so it's much easier to pinpoint the problem. Brilliant!

Ah, good example Dale. I hadn't thought about compile errors. So yes, I'll see what I can do to fix this for the next beta update. (You don't get the line number highlighting if there aren't any lines with errors to highlight!)