Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

contenteditable Interop #5

Open
jgraham opened this issue May 19, 2022 · 7 comments
Open

contenteditable Interop #5

jgraham opened this issue May 19, 2022 · 7 comments

Comments

@jgraham
Copy link
Contributor

jgraham commented May 19, 2022

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:

  • Identify the areas in which model differences result in user-visible behaviour differences, using bug reports to browser engines as a guide.
  • Identify existing tests covering those areas.
  • Propose a model for how to handle the problematic situation (e.g. as a spec PR if it requires spec changes) and get agreement from vendors that it makes sense to align on that model.
  • Add additional test coverage as required.

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
Copy link
Contributor Author

jgraham commented May 19, 2022

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

@jgraham jgraham mentioned this issue May 19, 2022
Closed
@foolip foolip mentioned this issue May 26, 2022
Closed
@jgraham jgraham mentioned this issue Jun 16, 2022
Closed
@jgraham
Copy link
Contributor Author

jgraham commented Jul 14, 2022 •
edited
Loading

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
Copy link

@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
Copy link

masayuki-nakano commented Jul 20, 2022 •
edited
Loading

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 jgraham mentioned this issue Jul 20, 2022
Closed
@hsinyi hsinyi mentioned this issue Aug 9, 2022
Closed
@jgraham jgraham mentioned this issue Oct 5, 2022
Closed
@jgraham
Copy link
Contributor Author

jgraham commented Oct 19, 2022

We have an Interop 2023 submission here: web-platform-tests/interop#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 jgraham mentioned this issue Oct 20, 2022
Closed
@jgraham
Copy link
Contributor Author

jgraham commented Oct 20, 2022

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 jgraham mentioned this issue Nov 17, 2022
Closed
@jgraham
Copy link
Contributor Author

jgraham commented Dec 15, 2022

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.

@jgraham jgraham mentioned this issue Dec 15, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jgraham @masayuki-nakano