5 ms·

Interop 2022

115 points by feross 5y ago

jitl 5y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1735608
- jgraham 5y ago
  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.
  - jitl 5y ago
    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.
nonrandomstring 5y ago
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.
dmitriid 5y ago
My reaction to this is, I quote: Note how none of the bullet points address anything of significance. https://open-ui.org/ 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.
- Deukhoofd 5y ago
  Interop is to make browsers comply to already existing specs. Why would they add new stuff to that...
  - dmitriid 5y ago
    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.
    - dmitriid 5y ago
      Example: https://news.ycombinator.com/item?id=30556054 https://news.ycombinator.com/item?id=30556054 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?
pentagrama 5y ago
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.
- pentagrama 5y ago
  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.
  - k_sze 5y ago
    Furthermore, I think the meaning of these numbers is a bit hard to grasp because the three numbers are not and cannot be independent from each other. Just as a thought experiment, imagine you saw Chrome/Edge and Safari being 0, and Firefox being 100? What would that even mean?
    - thaumasiotes 5y ago
      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)
llimos 5y ago
The Acid Tests were funner
- foolip 5y ago
  You're right! Unfortunately, a single test to cover lots of important details makes it much harder to understand what works and what doesn't. Most tests are pretty boring nowadays, green squares like this: http://wpt.live/css/css-sizing/aspect-ratio/replaced-element-022.html 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-001.html 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/acid2/reftest.html http://wpt.live/acid/acid3/test.html http://wpt.live/acid/acid3/test.html
csnover 5y ago
Honestly, I understand this, and I don’t. 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 https://github.com/webcompat/web-bugs/issues/25070 [1] https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+is... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1623340 https://bugzilla.mozilla.org/show_bug.cgi?id=1623340
- dblohm7 5y ago
  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.

Interop 2022

115 points by feross 5y ago

jitl 5y ago

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 https://bugzilla.mozilla.org/show_bug.cgi?id=1735608

jgraham 5y ago
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.
- jitl 5y ago
  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.

nonrandomstring 5y ago

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.

dmitriid 5y ago

My reaction to this is, I quote: Note how none of the bullet points address anything of significance. https://open-ui.org/ 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.

Deukhoofd 5y ago
Interop is to make browsers comply to already existing specs. Why would they add new stuff to that...
- dmitriid 5y ago
  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.
  - dmitriid 5y ago
    Example: https://news.ycombinator.com/item?id=30556054 https://news.ycombinator.com/item?id=30556054 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?

pentagrama 5y ago

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.

pentagrama 5y ago
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.
- k_sze 5y ago
  Furthermore, I think the meaning of these numbers is a bit hard to grasp because the three numbers are not and cannot be independent from each other. Just as a thought experiment, imagine you saw Chrome/Edge and Safari being 0, and Firefox being 100? What would that even mean?
  - thaumasiotes 5y ago
    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)

llimos 5y ago

The Acid Tests were funner

foolip 5y ago
You're right! Unfortunately, a single test to cover lots of important details makes it much harder to understand what works and what doesn't. Most tests are pretty boring nowadays, green squares like this: http://wpt.live/css/css-sizing/aspect-ratio/replaced-element-022.html 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-001.html 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/acid2/reftest.html http://wpt.live/acid/acid3/test.html http://wpt.live/acid/acid3/test.html

csnover 5y ago

Honestly, I understand this, and I don’t. 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 https://github.com/webcompat/web-bugs/issues/25070 [1] https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+is... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1623340 https://bugzilla.mozilla.org/show_bug.cgi?id=1623340

dblohm7 5y ago
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.