When Shadow DOM is attached in contenteditable, it causes a lot of crashes while editing. To make Shadow DOM go further, we should consider disabling Author Shadow DOM temporarily. Adding User Agent Shadow DOM, which is used for <input>, <textarea>, <meter>, etc, should be OK though. Note that we should be able to enable Author Shadow DOM for debugging in DRT!
(In reply to comment #0) > When Shadow DOM is attached in contenteditable, it causes a lot of crashes while editing. I don't think that's an acceptable solution. We can't disable a bunch of features that don't work well inside shadow DOM arbitrarily. We need to fix editing code to work well with shadow DOM.
(In reply to comment #1) > (In reply to comment #0) > > When Shadow DOM is attached in contenteditable, it causes a lot of crashes while editing. > > I don't think that's an acceptable solution. We can't disable a bunch of features that don't work well inside shadow DOM arbitrarily. We need to fix editing code to work well with shadow DOM. I understand it, but... We're just thinking a kind of alternative plan.
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > When Shadow DOM is attached in contenteditable, it causes a lot of crashes while editing. > > > > I don't think that's an acceptable solution. We can't disable a bunch of features that don't work well inside shadow DOM arbitrarily. We need to fix editing code to work well with shadow DOM. > > I understand it, but... > > We're just thinking a kind of alternative plan. I think we should discuss this idea first. I am kind of ambivalent about what's the right thing to do here. We did this with disabling author shadows on inputs, and now we nearly trained the few peeps who experiment with shadow DOM that inputs are not usable with shadow DOM, which seems like a bad thing. On the other hand, we don't want to be crashing like drunk monkeys in ferraris. Let's put it this way: I am confident in your abilities to climb HTML editing learning curve and identify the root issues (I am sure there are only a few of those) and fix this in a reasonable timeframe :)
(In reply to comment #3) > I think we should discuss this idea first. I am kind of ambivalent about what's the right thing to do here. We did this with disabling author shadows on inputs, and now we nearly trained the few peeps who experiment with shadow DOM that inputs are not usable with shadow DOM, which seems like a bad thing. On the other hand, we don't want to be crashing like drunk monkeys in ferraris. Right, this is not a desirable solution if we want a good consistent API for the Web and want other browser vendors to implement it :) For example, why would Microsoft or Mozilla should disable contenteditable in their shadow DOM if their editing code was much more sound than ours? > Let's put it this way: I am confident in your abilities to climb HTML editing learning curve and identify the root issues (I am sure there are only a few of those) and fix this in a reasonable timeframe :) I'm more than happy to look at those crashes if you guys can send a list of crashes with stack trace & reduction.
Probably not.