- From: Johannes Wilm <notifications@github.com>
- Date: Wed, 12 Aug 2015 18:04:31 -0700
- To: w3c/editing <editing@noreply.github.com>
- Message-ID: <w3c/editing/issues/66/130494279@github.com>
> I don't think we necessary want to eliminate `contenteditable=true`. We're adding `contenteditable=events` now because spec'ing the former is really hard, and we can't easily reach an interoperability but we should aim to eventually reach interoperability between browsers. In a way, you could think of `contenteditable=events` as "desugaring" `contenteditable=true`. In that case, spec'ing `contenteditable=events` and adding more primitives should help browser engines to slowly converge to an interoperable implementing of `contenteditable=true` over time (like in 10-20 years). Yeah, that is a possibility. I think what we all agree on is that we want to have a way to turn events and possibly later modules (clipboard, typing enter caret, etc.) modes on all at the same time, no matter whether the term is "true" or "all" or whatever it will be. Effectively that should correspond more or less to all the functionality that cE=true has now, jsut more standardized and bug-free-er. As for whether cE=true itself can be fixed or not -- the various browser people, such as you, have given different explanations. Some say it cannot be changed because too much content is relying on today's broken implementations and that some websites will never update and therefore it can never change. Others say it can and should be standardized. So it's hard to know what is the case. Sitll, unless you see a reason for it, I would think it would be the most simple to try to just make it impossible to nest the two contenteditable types inside of oneanother, both because that is easier to define, and I would imagine also less cause for weird browser bugs. Or what do you have in mind? --- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/66#issuecomment-130494279
Received on Thursday, 13 August 2015 01:05:00 UTC