- From: Johannes Wilm <notifications@github.com>
- Date: Thu, 04 Oct 2018 22:23:10 +0000 (UTC)
- To: w3c/editing <editing@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/editing/issues/166/427188876@github.com>
> I don't understand why [...] I think the explanation here is that they serialize it all into plaintext before applying the spell checking. And then when applying the spell checking then don't really have an easy and effortless way of reapplying the styling. I think a lot of this is about cultural differences. And I'm not talking culture differences between countries, religions or socio-economic differences. Browser devs seem to have a different experience of how it's all used than JS devs who are into this area. The browser devs seem to mostly have in mind cases where very little or no JavaScript is being used and where elements use the semantic meaning they have and where browsers can by default do DOM modifications that are specific to the platform they are on. Say on an iPhone, the browser may move the entire word into the `<strong>`, whereas on a PC it deletes the `<strong>` because that is how other, native richtext editors behave on those platforms and they want to preserve that behavior when it comes to the web. All the JS devs working in this area that I have spoken with so far, on the other hand, almost don't seem to care about any platform specific behavior and are more concerned about being able to create JS editors that behave the same (and work at all) on all platform combinations. So the compromise we came up with was kind of that the browsers do whatever DOM modifications they need to do, but that those can be replaced by defining alternative behavior using the `beforeinput` events. Unfortunately Chrome ended up implementing the beforeinput event in a way where most things are not cancelable, so to make it cancelable anyway, one needs to combine with a DOM diffing mechanism that can then roll back the native browser changes before reapplying them... And yes, I know what a pain that is. But opinions change and we can try to debate this again. And yes, the `<strong>` => `<b>` doesn't seem to make sense to me either. About 3-4 years ago, it was still creating a bunch of `<font>`-elements though. So it's an improvement. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/166#issuecomment-427188876
Received on Thursday, 4 October 2018 22:23:33 UTC