- From: <bugzilla@jessica.w3.org>
- Date: Mon, 14 Oct 2013 11:00:09 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12235 --- Comment #22 from Aryeh Gregor <ayg@aryeh.name> --- (In reply to Carl Smith from comment #21) > That doesn't handle tabs, and there's other problems with it. It handles tabs exactly the same as <xmp>, AFAICT. How does it handle tabs differently? And what are the other problems with it? > It takes a long time on the server to actually do all the cgi escapes, and > `output = output.replace( '<', '<')` stuff. Tabulated strings also have > to be converted to HTML tables. It's just a lot of work that isn't needed in > a time critical part of the code. When you hit enter in a shell, you expect > output with no delay. This can't take tenths of seconds without making > things feel crappy. Doing a replace of two characters on the whole string does not take tenths of seconds. It requires two compares and one copy per byte, which should take less than a millisecond on any string you'd display in a shell. Please provide a benchmark that demonstrates this takes a perceptible amount of time for strings you'd expect to find in a shell if you want to support your case. > Dirty hacks have been the normal way to do web programming for years, but > that's not the way forward. We'll end up with a 3rd party <x-xmp> tag before > too long, or more than one. > > Please reconsider. You have not yet presented any advantage of <xmp> over <pre> plus escaping that I can see. Only that it handles tabs differently (without demonstrating that this is true, and I'm quite sure it's not); that it takes tenths of seconds to replace & and < (without demonstrating that this is true, and I'm quite sure it's not); that there are other problems (without saying what they are); and that you think it's a dirty hack (which is a matter of opinion and I happen to disagree). If you would like anyone to change things, you should provide more evidence and reasoning to support your case. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 14 October 2013 11:00:13 UTC