search

web-platform-tests / interop-2022-editing

Work on the editing investigation for Interop 2022
Other
3 stars 3 forks source link

contenteditable Interop #5

Open jgraham opened 2 years ago

jgraham commented 2 years ago

Differences between the browsers' models/behaviour for contenteditable cause observed compat for users, even though libraries have sophisticated mechanisms for working around these differences. Fully aligning these models is considered out of scope, but there are some areas where incremental progress is likely to be impactful to users. As part of the investigation we should:

The aim is that the identified tests would be a candidate for an Interop 2023 focus area around editing that browsers would be able to commit to.

jgraham commented 2 years ago

Please let me know if the summary as written isn't right, doesn't cover something important, or covers something it shouldn't.

jgraham commented 2 years ago

https://bugzilla.mozilla.org/show_bug.cgi?id=1776332 is a test @masayuki-nakano has written to cover an interop difference we found in https://bugzilla.mozilla.org/show_bug.cgi?id=1735608 which is a case where contentEditable differences are causing problems on real sites (and Chromium has a weird behaviour that we probably don't want to standardise).

Note in particular that issue was reported to break editors, even when they tried to use a DOM-diffing approach. So it seems like the kind of fundamental that we need to get right even if browsers don't have to agree on all higher level operations.

masayuki-nakano commented 2 years ago

@jgraham Thank you for your follow-up.

I also added new tentative WPT for insertParagraph (typing Enter for testing) in <span contenteditable>. Chrome and Safari create invalid HTML structure in some cases (inserting <div> etc). I found this issue when I handle bug reports of <span contenteditable> support. Number of the reports is not so high, but I'm thinking that there are some scenarios which web developers want to use. Therefore, I'd like to support it more, but this is a big issue which I don't want to align to Chrome/Safari's behavior. https://wpt.fyi/results/editing/other?q=insertparagraph-or-insertlinebreak-in-inline-editing-host.tentative.html&run_id=5740060539355136&run_id=5749653281701888&run_id=5726347648303104&run_id=5644101574721536

And I'm working on adding new WPT for handling elements outside <body> element. Such odd element is typically used for a placeholder of pasting content or something which should be invisible because of temporary use. Currently, Gecko does not allow to edit elements outside <body> in its general rules, but partially allows it for such use case. I want to Gecko fully support editing outside <body> for potential web-compat risks. However, deleting backwards/forwards from start/end of an element which is a child of <html> or <head> causes odd result in Chrome at least. I'm currently thinking that elements which are direct child of <html> or <head> should not be split nor joined each other for avoiding creating complicated rules for this edge case. I think I can merge them in next week (I'm currently not fully recovered from sick leave, so it's hard to say I'll finish the work by this day).

masayuki-nakano commented 2 years ago

However, deleting backwards/forwards from start/end of an element which is a child of <html> or <head> causes odd result in Chrome at least. I'm currently thinking that elements which are direct child of <html> or <head> should not be split nor joined each other for avoiding creating complicated rules for this edge case. I think I can merge them in next week.

I'm still working on this, and I change my mind for backward-compatibility. Currently, at least Chrome allows to join/split direct child of <html> and <head> elements, and some web apps may depend on this behavior accidentally. Therefore, I'm currently thinking that browsers should allow to join/split nodes if and only if they are normal elements which usually appear in <body> and visible. But <head>, <body>, <meta>, <title>, <style>, <script>, <link>, <base>, <template> should not be deleted, joined nor split by users' operation for avoiding edge case handling and odd visual result.

jgraham commented 1 year ago

We have an Interop 2023 submission here: https://github.com/web-platform-tests/interop/issues/188

I'd suggest that represents about 50% of the work for this item; if we aren't able to get support for working on the selected set of tests, that seems like it would be a failure, so we shouldn't regard the proposal alone as completing this area.

jgraham commented 1 year ago

Updating the score here to 70% per the meeting, on the basis that there's less high priority work here than expected. But the next step is still to review the Interop proposal, since that would help drive alignment on some compat-affecting contenteditable behavour.

jgraham commented 1 year ago

I propose we update the score to 100% here since we submitted an interop proposal. However I would also say that's based on dramatically reducing the ambition of what we wanted to achieve during the year, and there's still a great deal of work to do in this area.