Interop 2022
hacks.mozilla.org
hacks.mozilla.org
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.
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...
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/
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
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?