On Thu, Mar 10, 2016 at 10:50 AM, Hallvord Reiar Michaelsen Steen < hst...@mozilla.com> wrote:
> On Thu, Mar 10, 2016 at 4:23 AM, Johannes Wilm <johan...@fiduswriter.org> > wrote: > > > Once I get back to work, I will start to program a version 5.0 of my > editor > > that handles the new eventtype correctly. > > > > Anyone still not having upgraded from version 4.35, the editor doesn't > end > > up doing crazy/uncontrolled stuff when receiving voice input. It simply > does > > nothing on voice input > > That's sort of the polar opposite of Gary's goal that new stuff should > "just work" :) > > It also means that you do *not* consider it a goal of your spec > development to make it easier to handle stuff the developer hasn't > explicitly thought of - like IMEs, accessibility helpers and possible > future input stuff - in a way that would have a chance of "just > working"? > I just don't think this is technically possible for any editing action to "just work" in all the different editors that all work extremely differently. We have to interrupt just about every other user action, including simple things such as hitting the space bar, backspace/delete, or making bold. But whether or not it's feasible for browsers to just provide this functionality or not is an everlasting argument that we don't need to reach a conclusion for here. And lets say that you guys are right and voice input happens to "just work": the editor developers will enable it, run their 2000-10000 automatic tests and if everything just works fine, I am sure they will enable it immediately in their production version and push out an update ASAP. After all there are several editors out there, so there is no reason to have any less features than any of the others. I am sure if any of you browser people were off scuba-diving and a major library you depend on would change and give the user new ways of communicating with the application comes out, you would want to test building your browser with it, and not just automatically have it be bundled and shipped to the entire world. > I'd consider it a brilliant technological achievement if voice input > fired key insertion beforeInput events (and potentially > keydown/up/press - why not? /me <3 back compat :-p) and your app "just > worked" with the new Apple device while you were scuba diving (and > more importantly: on the 10 000 sites that never bothered updating to > the new version of your JS lib at all). > indeed, brilliant. But not necessarily possible. > > Anyway - however much fun we can have imagining the future, this > discussion is sort of off-topic when we're arguing whether to replace > specialised paste and drop events with a general beforeInput > eventType=paste and eventType=drop approach. > > The idea is here to argue whether or not it is a good idea to give the script author a "guarantee" that the beforeinput event will carry all user intentions about changes to a contenteditable element. Of course we can also say: clipboard and drag/drop events stay as they are, but all future editing events will get a beforeinput event. That would be more or less the same type of guarantee. It would just be slightly more inconsistent. > Johannes also wrote: > > >> Easier to read because there's less if() branching and switch() > >> statements. > > > You mean in the JavaScript code? Well, it will be maybe three-four event > > more event handlers and then maybe 25 cases in the beforeInput/input > event > > handler. > > 25 cases is a lot :) > > >> Easier to debug because if you want to debug pasting, you ask your > >> debugger to break on a paste event. > > > I assume you are here thinking of the debugging issues it gives in the > > browser code. This I know nothing about. > > Not meant as boasting but just to explain where I'm seeing things > from: I've been debugging random issues on random websites for the > last 14 years or so, usually working on code I have not had the luxury > of prior knowledge of, I've been dissecting heavily obfuscated code at > least since GMail hit the web. 25+ cases inside one event handler > inside an obfuscated script is hard. 25+cases inside a non-obfuscated > script still means you might have to step over quite a few statements > to get to the code you want to see running. > my respect. Obfuscated code is a mess. > > > In the JS code I cannot see why this wouldn't be solveable by filtering > > through the events with a switch and then just debugging the part of the > > code that is executed for a specific action. > > Browser people who advocate for this solution should be tasked with > creating a usable debugger UI for this :) > Most debuggers already have UI for breaking on a specific event type. > This is a solved problem. None have UI for creating conditional > breakpoints on a specific event type AFAIK - not saying it can't be > done, but it's harder. > > -Hallvord > -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
