3 ms·

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 (

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#issuecomment-1006967983 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#sec-array.prototype.sort 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 https://www.gitbook.com/contact/contact-us is purely sales contacts, which is a sign they don't care about providing technical support.

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

jitl 5y ago

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.

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