Interesting. Firefox’s handles deleted nodes in ContentEditable quite differently from other browsers we tested, so I’m glad to see contentEditable at least on the “investigation list”. Here’s my pet issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1735608
Yes, contentEditable is the poster child for why it's a bad idea to base a widely used feature on reverse engineering an implementation, rather than on a standard that had meaningful cross-vendor input from the start. Not only are all the implementations different, the behaviour itself often seems to be "whatever happened to be easy to implement in trident (i.e. IE) at the time". What's worse is that it's become so widely used despite the differences that editing libraries typically have browser-specific codepaths, which can make it hard to align behaviour without breaking things. The spec, such as it is, was written post-hoc and doesn't reflect the behaviours that sites expect today.
As you can see, the whole area is a bit of a mess, and so some substantial work will be needed to clean things up. But that's the point of this kind of effort!
Also, assuming you filed the linked bug, thanks for the detailed report with testcases! It's appreciated.
Oh yeah, tell me about it. I spent 6 months adding text selection across blocks to the Notion editor. At least MutationObserver exists today! And beforeInput is something. It’s not enough, because of IMEs and Android, but it’s something.
When "the web platform" can render the majority of pages in plain text
on my w3m browser, over a low bandwidth or Tor connection, then let's
talk about interoperability.
New things become "already existing specs" the moment two browsers implement them.
Given the proliferation of APIs pushed out by browsers it would be nice if they planned for actual interop of actual useful things beforehand. Not present barely a dozen things as this huge accomplishment that they agreed on It's not an accomplishment. It's an abject failure by all involved to, you know, agree on interop.
Chrome shipped extensions to Canvas API even if Mozilla has reservations about some
parts and is negative about other parts. Chrome couldn't give two craps about Mozilla's position.
Two-five years from now there will be another "Interop 202x" that will gleefully proclaim they will now align their work and implementation of Canvas API?
What means the image with the numbers 71, 74, 73? Amount of compatibility issues from each browser? A score? (x out of 100 I guess?) The image should have footer explaining that. In the text do not say explicitly what it is.
Update: The image alt tag says "Interop 2022 scores. Chrome/Edge 71, Firefox 74, and Safari 73." It also should be in the body text, and is out of 100 I guess.
This was a great question, but the article implies that the numbers are in fact mostly independent of each other:
> Interop 2022 has ten new focus areas:
> There are also five additional areas that have been adopted from Google and Microsoft’s “Compat 2021” effort:
> A browser’s test pass rate in each area contributes 6% — totaling at 90% for fifteen areas — of their score of Interop 2022.
> We believe these are areas where the standards are in good shape for implementation, and where improving interoperability will directly improve the lives of developers and end users.
A "test pass" could just be a test on which all three browsers give exactly the same result. But that would immediately imply that all three browsers would have the same Interop score, which isn't true. So I would guess that the number refers to "compliance with a standard", where you can be objectively right or wrong, rather than strictly to "interoperability", where all that matters is whether you agree with everyone else.
(The other 10% of the score really does appear to be graded on interoperability:
> Interop 2022 has three investigate areas:
> These are areas in which we often see complaints from end users, or reports of site breakage, but where the path toward solving the issues isn’t clear. Collaboration between vendors is essential to working out how to fix these problem areas, and we believe that Interop 2022 is a unique opportunity to make progress on historically neglected areas of the web platform.
> The overall progress in this area will contribute 10% to the overall score of Interop 2022. This score will be the same across all browsers. This reflects the fact that progress on the web platform requires browsers to collaborate on new or updated web standards and accompanying tests)
What I meant is that, in the areas that are not well standardized, and where the browsers don't agree with each other, who is to say that Chrome is right and that Firefox is the one being incompatible/non-conformant? In this sense, the scores are not independent.
Among the areas listed, I understand that at least 10 focus areas are well-standardized and the major browser vendors agree amongst themselves regarding the interpretation of the standard. So that means 60% of the score should be independent. There are 5 other areas that were pulled from Google's and Microsoft's Compat 2021; those might not be well standardized, in which case 30% of the score might be disputable. (UPDATE: I think the 5 additional areas are also well standardized, so I guess you could also say they are independent and not subject to dispute.)
And then the remaining 10% investigative areas are quite probably disputable.
You are correct; the real success in terms of improving the web for users and authors will be if all the browser engines end up aligning on behaviour and getting a good score. Nevertheless having per-browser scores is useful for the browser teams themselves to help them prioritise their own contribution to that overall success.
You're also correct that there are cases where the behaviour as expected by current specs / tests might turn out to not be web compatible and so alignment will require changing the expectations and might reduce scores for implementations that were previously following the spec. That is already a thing that happens (although it would be great if it didn't). In practice, most of the focus areas are quite new parts of the platform with well written standards and not too much existing content. So I don't expect this to be a big effect. The "web compat" area has some cases where this outcome is more likely, but it's comprised of user-experienced problems in real sites, so the incentive to fix the problem is much greater than the incentive to avoid a temporary drop in the interop score.
The investigate areas are specifically those where it's unclear what the path to interoperability looks like, or how to measure interoperability. In those areas, figuring out what we can realistically do to ship the feature in a way that works the same across browsers is the point. Hopefully, if we run this kind of thing again in the future, we have a clear picture of what's web compatible, and can turn those investigate areas into focus areas that are scored on the basis of a testsuite that everyone agrees is useful.
I know that ensuring interoperability across implementations has always been the key to a healthy web platform. I get that Interop 2022 is not about interoperability with individual sites, or about focusing on one browser. But if you want a web that actually has more than one engine so that interoperability initiatives like this even exist or matter, you need to make sure that you still have users.
The top webcompat issue for the past two years has nothing to do with editing, or viewports, or pointer events. It’s Microsoft Teams not working[0][1]. The Bugzilla ticket has the highest priority, highest severity[2], and it is still broken. For two years.
I’m aware of the irony of Editing API being one of the interop problem areas since it was basically a “try to write down how IE works so all the IE-only sites with text editors can work in other browsers” spec, and now here I am advocating for Mozilla and Apple to basically just go do that again, but when you are in a position of weakness sometimes you have to take the L and be pragmatic instead of bleeding users as you say “well it’s Microsoft’s fault so Microsoft should fix their shitty code”.
It feels so tone-deaf to say that that bug reports from webcompat were used to guide decisions on interop focus and then ignore that 3 of the top 5 issues are voice and video. I mean, I’m sure that they were used, but I don’t know how everyone who is in a good position to fix it seems OK with just ignoring this situation.
Solving these types of issues can be a lot more complicated than you might think.
For example, take WebRTC. Lots of places wrote their WebRTC code to Chrome's non-standard "Plan B" dialect. Now all the browsers are transitioning to the standardized "Unified Plan."
Should Mozilla have spent developer resources on implementing Plan B as a stop-gap until the Unified Plan was rolled out by Chrome, and then subsequently thrown away all the code for the former?
Some people might say so, but others might argue that doing so is a terrible waste of resources.
My point here is that the solution is not always cut and dried.
One notable compatibility issue I recently diagnosed was an bug in the GitBook website, causing the page to fail to render on Firefox with narrow window sizes (including mobile browsers). They sorted an array of page widths using a wrong comparison function which always returned -1 (https://github.com/webcompat/web-bugs/issues/89812#issuecomm...), but the code happened to produce the right answer by pure coincidence on Chrome, and the reversed order on Firefox. The exact order of comparison calls is undefined in the spec (https://tc39.es/ecma262/multipage/indexed-collections.html#s...), the code is wrong to begin with, but GitBook hasn't fixed the bug for 2 months despite me handing them the solution. GitBook is the problem, not breaking on Chrome is merely a coincidence, and them not fixing it is a symptom of not caring about correct code, not caring about standards, and not caring about Firefox, and https://www.gitbook.com/contact/contact-us is purely sales contacts, which is a sign they don't care about providing technical support.
The GitBook issue you describe is annoying because it seems so simple to fix.
But there’s also plenty of compatibility issues where the effort required to make it work in a divergent browser is months instead of days. I ran into such an issue with ContentEditable in November. Despite wanting to be a good web citizen and ship in all the browsers, the costs were just too high to build a complicated work-around code path. We cut the feature for that browser.
I was planning to write a little toy WYSIWYG editor for basic html formatting in the near future (mostly for fun). Any general advice before jumping into it?
I'm not sure how to best optimize for fun in this scenario. Since I've sweated this stuff so much building for produciton, I would never do this kind of thing for fun myself.
Do you want to build from scratch? The classic advice is to keep your data model totally separate from the DOM. Treat the DOM as a drawing and input device, not as the source of truth for your document. Probably the easiest way to accept input for a weekend project is to use the beforeInput event and preventDefault() pretty much every event you see, apply the update to your data model, and then render the new data into the DOM yourself. This way you avoid unexpected shenanigans or mutations. The downside is that this approach doesn't work well on Android or for IME languages.
If you want to use a library, check out Prosemirror (low-level) or layers over Prosemirror like Remirror or Tiptap, although I haven't used those abstractions myself. I would stay away from Slate.js -- it has a very nice design, but doesn't support Android well. I think if you're going to invest time with a library, it should be one that can support you into production, be well-proven and bullet-proof. Quill also seems production-ready, but might not support more complex layouts, but it's been a while since I played with it. For a fun/scrappy WYSIWYG kinda toy, any of these libraries are probably overkill.
Yes, I was going to do it from scratch (no libraries), it's supposed to be a very basic WYSIWYG markdown dialect editor, which also supports rich text pasting. It will probably never see the light of day in any practical use, I just want to see firsthand how feasible it is to do something like this, and hopefully learn a thing or two in the process.
Because the desired end result is markdown, and it's supposed to only support very basic formatting, I was planning to have a separate data model anyway, I figured I could use a MutationObserver, parse the editable dom into tokens, then just toss out everything that doesn't fit into the model, and generate new HTML based on the resulting model. I guess this ultimately does still treat the dom as the source of truth in a roundabout way, though.
Interop 2022 organizer here, working on Google Chrome.
By and large, prioritization was driven by web developer signals. Results from State of CSS 2021 [1] were quite influential, but we also referred back to the 2020 MDN Browser Compatibility Report [2] and the 2021 Scroll Survey Report. [3]
I think Subgrid, Viewport Units and Scrolling are clear cases of features that web developers want or struggle with, and which I'm very happy are included in Interop 2022.
This doesn't tell the whole story, though. The Web Compat focus area and "Editing, contenteditable, and execCommand" + "Pointer and Mouse Events " investigation efforts are rather motivated by site compat issues that affect users.
26 comments
[ 3.1 ms ] story [ 67.0 ms ] threadAs you can see, the whole area is a bit of a mess, and so some substantial work will be needed to clean things up. But that's the point of this kind of effort!
Also, assuming you filed the linked bug, thanks for the detailed report with testcases! It's appreciated.
Note how none of the bullet points address anything of significance.
https://open-ui.org/ which would actually benefit users isn't mentioned at all.
It will be the same useless bullshit for the next 10-20 years, sabotaged by Google.
Given the proliferation of APIs pushed out by browsers it would be nice if they planned for actual interop of actual useful things beforehand. Not present barely a dozen things as this huge accomplishment that they agreed on It's not an accomplishment. It's an abject failure by all involved to, you know, agree on interop.
Chrome shipped extensions to Canvas API even if Mozilla has reservations about some parts and is negative about other parts. Chrome couldn't give two craps about Mozilla's position.
Two-five years from now there will be another "Interop 202x" that will gleefully proclaim they will now align their work and implementation of Canvas API?
Just as a thought experiment, imagine you saw Chrome/Edge and Safari being 0, and Firefox being 100? What would that even mean?
> Interop 2022 has ten new focus areas:
> There are also five additional areas that have been adopted from Google and Microsoft’s “Compat 2021” effort:
> A browser’s test pass rate in each area contributes 6% — totaling at 90% for fifteen areas — of their score of Interop 2022.
> We believe these are areas where the standards are in good shape for implementation, and where improving interoperability will directly improve the lives of developers and end users.
A "test pass" could just be a test on which all three browsers give exactly the same result. But that would immediately imply that all three browsers would have the same Interop score, which isn't true. So I would guess that the number refers to "compliance with a standard", where you can be objectively right or wrong, rather than strictly to "interoperability", where all that matters is whether you agree with everyone else.
(The other 10% of the score really does appear to be graded on interoperability:
> Interop 2022 has three investigate areas:
> These are areas in which we often see complaints from end users, or reports of site breakage, but where the path toward solving the issues isn’t clear. Collaboration between vendors is essential to working out how to fix these problem areas, and we believe that Interop 2022 is a unique opportunity to make progress on historically neglected areas of the web platform.
> The overall progress in this area will contribute 10% to the overall score of Interop 2022. This score will be the same across all browsers. This reflects the fact that progress on the web platform requires browsers to collaborate on new or updated web standards and accompanying tests)
Among the areas listed, I understand that at least 10 focus areas are well-standardized and the major browser vendors agree amongst themselves regarding the interpretation of the standard. So that means 60% of the score should be independent. There are 5 other areas that were pulled from Google's and Microsoft's Compat 2021; those might not be well standardized, in which case 30% of the score might be disputable. (UPDATE: I think the 5 additional areas are also well standardized, so I guess you could also say they are independent and not subject to dispute.)
And then the remaining 10% investigative areas are quite probably disputable.
You're also correct that there are cases where the behaviour as expected by current specs / tests might turn out to not be web compatible and so alignment will require changing the expectations and might reduce scores for implementations that were previously following the spec. That is already a thing that happens (although it would be great if it didn't). In practice, most of the focus areas are quite new parts of the platform with well written standards and not too much existing content. So I don't expect this to be a big effect. The "web compat" area has some cases where this outcome is more likely, but it's comprised of user-experienced problems in real sites, so the incentive to fix the problem is much greater than the incentive to avoid a temporary drop in the interop score.
The investigate areas are specifically those where it's unclear what the path to interoperability looks like, or how to measure interoperability. In those areas, figuring out what we can realistically do to ship the feature in a way that works the same across browsers is the point. Hopefully, if we run this kind of thing again in the future, we have a clear picture of what's web compatible, and can turn those investigate areas into focus areas that are scored on the basis of a testsuite that everyone agrees is useful.
Most tests are pretty boring nowadays, green squares like this: http://wpt.live/css/css-sizing/aspect-ratio/replaced-element...
I guess Subgrid tests are a bit more interesting to look at: http://wpt.live/css/css-grid/subgrid/subgrid-mbp-overflow-00...
The Acid tests still live on in WPT though, if you want to smile: http://wpt.live/acid/acid2/reftest.html http://wpt.live/acid/acid3/test.html
I know that ensuring interoperability across implementations has always been the key to a healthy web platform. I get that Interop 2022 is not about interoperability with individual sites, or about focusing on one browser. But if you want a web that actually has more than one engine so that interoperability initiatives like this even exist or matter, you need to make sure that you still have users.
The top webcompat issue for the past two years has nothing to do with editing, or viewports, or pointer events. It’s Microsoft Teams not working[0][1]. The Bugzilla ticket has the highest priority, highest severity[2], and it is still broken. For two years.
I’m aware of the irony of Editing API being one of the interop problem areas since it was basically a “try to write down how IE works so all the IE-only sites with text editors can work in other browsers” spec, and now here I am advocating for Mozilla and Apple to basically just go do that again, but when you are in a position of weakness sometimes you have to take the L and be pragmatic instead of bleeding users as you say “well it’s Microsoft’s fault so Microsoft should fix their shitty code”.
It feels so tone-deaf to say that that bug reports from webcompat were used to guide decisions on interop focus and then ignore that 3 of the top 5 issues are voice and video. I mean, I’m sure that they were used, but I don’t know how everyone who is in a good position to fix it seems OK with just ignoring this situation.
[0] https://github.com/webcompat/web-bugs/issues/25070
[1] https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+is...
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1623340
For example, take WebRTC. Lots of places wrote their WebRTC code to Chrome's non-standard "Plan B" dialect. Now all the browsers are transitioning to the standardized "Unified Plan."
Should Mozilla have spent developer resources on implementing Plan B as a stop-gap until the Unified Plan was rolled out by Chrome, and then subsequently thrown away all the code for the former?
Some people might say so, but others might argue that doing so is a terrible waste of resources.
My point here is that the solution is not always cut and dried.
But there’s also plenty of compatibility issues where the effort required to make it work in a divergent browser is months instead of days. I ran into such an issue with ContentEditable in November. Despite wanting to be a good web citizen and ship in all the browsers, the costs were just too high to build a complicated work-around code path. We cut the feature for that browser.
Do you want to build from scratch? The classic advice is to keep your data model totally separate from the DOM. Treat the DOM as a drawing and input device, not as the source of truth for your document. Probably the easiest way to accept input for a weekend project is to use the beforeInput event and preventDefault() pretty much every event you see, apply the update to your data model, and then render the new data into the DOM yourself. This way you avoid unexpected shenanigans or mutations. The downside is that this approach doesn't work well on Android or for IME languages.
If you want to use a library, check out Prosemirror (low-level) or layers over Prosemirror like Remirror or Tiptap, although I haven't used those abstractions myself. I would stay away from Slate.js -- it has a very nice design, but doesn't support Android well. I think if you're going to invest time with a library, it should be one that can support you into production, be well-proven and bullet-proof. Quill also seems production-ready, but might not support more complex layouts, but it's been a while since I played with it. For a fun/scrappy WYSIWYG kinda toy, any of these libraries are probably overkill.
Yes, I was going to do it from scratch (no libraries), it's supposed to be a very basic WYSIWYG markdown dialect editor, which also supports rich text pasting. It will probably never see the light of day in any practical use, I just want to see firsthand how feasible it is to do something like this, and hopefully learn a thing or two in the process.
Because the desired end result is markdown, and it's supposed to only support very basic formatting, I was planning to have a separate data model anyway, I figured I could use a MutationObserver, parse the editable dom into tokens, then just toss out everything that doesn't fit into the model, and generate new HTML based on the resulting model. I guess this ultimately does still treat the dom as the source of truth in a roundabout way, though.
By and large, prioritization was driven by web developer signals. Results from State of CSS 2021 [1] were quite influential, but we also referred back to the 2020 MDN Browser Compatibility Report [2] and the 2021 Scroll Survey Report. [3]
https://github.com/web-platform-tests/interop-2022/issues/4 is a good example of how the sausage was made.
I think Subgrid, Viewport Units and Scrolling are clear cases of features that web developers want or struggle with, and which I'm very happy are included in Interop 2022.
This doesn't tell the whole story, though. The Web Compat focus area and "Editing, contenteditable, and execCommand" + "Pointer and Mouse Events " investigation efforts are rather motivated by site compat issues that affect users.
An issue like https://github.com/webcompat/web-bugs/issues/25070 is certainly very important to Firefox users, but it's not clear if it could be fixed by aligning browsers on some specific set of tests. My understanding is that Mozilla did look over their top site compat issues and included bugs that seemed tractable within Interop 2022, and some of those are in https://github.com/web-platform-tests/interop-2022/labels/co....
[1] https://2021.stateofcss.com/en-US/opinions/#browser_interope... [2] https://insights.developer.mozilla.org/reports/mdn-browser-c... [3] https://web.dev/2021-scroll-survey-report/