- From: <bugzilla@jessica.w3.org>
- Date: Wed, 10 Oct 2012 02:56:38 +0000
- To: public-webapps-bugzilla@w3.org
- Message-ID: <bug-19414-2532-dREo2Kg9iq@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19414 --- Comment #4 from John A. Bilicki III <jab_creations@yahoo.com> --- Compared to nearly a year's worth of work on just a rich editor alone a hundred pages would still be a summary. I neither have the time nor desire to put a test case together. What I have described should make plenty of logical sense and besides this can be tested out on my blog with public comments at jabcreations.com. My point is simple, I shouldn't have to hack my code by using setTimeout when it's very clear that finishPropagation is what should be used, that's a clear conflict of the context in which it is used for. In fact I'm absolutely astonished and dumbfounded that finishPropagation was not in DOM Level 1 for goodness sakes. The fact that you even THOUGHT to suggest using setTimeout as an acceptable route should stop you immediately in your tracks. I'm not telling the computer to wait, I'm telling the computer to finish executing an event, those are completely different contexts. Even if I was told finishPropagation was slower than setTimeout I would still use finishPropagation instead because it is crystal clear that is what it is intended for. Using setTimeout is a clearly undeniable hack used to get around the limitation of the DOM and when ambiguities start to arise the specification can either clarify by doing what is right or sit back and watch sites begin implementing hacks leaving bad examples of code to live on for years while simultaneously misguiding people who are learning when they come across it. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 10 October 2012 02:56:40 UTC