Comment by csnover | Hacker News Reader

Comment by csnover | Hacker News Reader

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

[1] https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+is...

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1623340

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.

Not to mention that MS Teams uses user agent sniffing, so to get it to work Firefox would also have to emulate a chrome or edge user agent.

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.

Thanks for taking the time to respond!

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]

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/

Reply on news.ycombinator.com