5 ms·

Just for what it’s worth, “word processors” are a logical starting point specifically because the APIs for text manipulation in the DOM are abysmal, and every i

Just for what it’s worth, “word processors” are a logical starting point specifically because the APIs for text manipulation in the DOM are abysmal, and every in-browser WYSIWYG text editor is a steaming pile of hacks. Some of them work well despite this, but, it’s a horrible set of code to maintain and very, very hard to make a good user experience. One of the very hardest things to do well in the browser, actually. Thus I wouldn’t necessarily interpret Google Docs making this move as the start of an inescapable trend. It may be, or it may just be that certain kinds of applications (like Docs and Games) can work a lot better by providing their own rendering engine.

kmeisthax 5y ago
Furthermore, actually implementing your own text renderer and input engine in WASM is a different horrible nightmare, because you've now forfitted any chance of supporting IMEs (e.g. touch keyboards, pinyin/romaji/kanji input, iPadOS Scribble), you need to implement your own text selection inputs, your text won't show up in the accessibility tree, and you can't copy-paste without additional, browser-specific tweaks. The only reason to actually do this is if you can't use HTML. Source: I am a Ruffle developer and have had to do exactly this to support text input in old Flash games.
- pmontra 5y ago
  > you can't copy-paste without additional, browser-specific tweaks Expect an AI-based OCR browser extension to copy text to the system clipboard. Possibly by sending screenshots to some centralized service ;-)
  - kbenson 5y ago
    This would be more funny if it was less prescient.
bri3d 5y ago
A million times this - having worked in this space, nobody wants to do this. I understand the cynicism, but the affordances provided by the browser for things like accessibility are very painful to give up. This isn't some dark pattern attempt to cut out whatever "openness" remains on the web, or to convert the browser into a display-streaming client for some sinister DRM reason. In my past job, we rewrote our spreadsheet rendering to use canvas and gained massively in simplicity and maintainability. And there was no obfuscation angle to it - we even shipped source maps! Handling accessibility and text input was hard (we ended up adopting a hybrid-DOM model where some things like input fields were still native ones, or shadowed by native ones), and even then it was still easier than dealing with browser rendering. This is simply a reasonable way to work around the DOM being trash. The way to fix this trend would be to reimagine the presentation layer of the browser as something other than a stack of hacks over hypertext, but so far nobody seems to have a good solution.
- mixmastamyk 5y ago
  Once the trail has been blazed by pioneers, expect a gold rush. What would a good API look like, I wonder?
- vagrantJin 5y ago
  The dom isn't trash. Its good enough. We just need to stop making it do things it wasn't supposed to. That's why things like electron make sense a little bit. Not perfect but sensible.
  - nindalf 5y ago
    > We just need to stop making it do things it wasn't supposed to This is a thread about Google Docs. Your suggestion to the Docs team is to ... stop? Just shut down their product?
    - vagrantJin 5y ago
      Oh no. They're google. They make a godforsaken browser. They can pay people to do nothing more than think about code. By all means. They can launch a satellite with css if they want. But the rest of us plebs...
      - scotty79 5y ago
        Btw for NASA css is shorthand for Control Stick Steering, which is something you did at later stages of landing with a space shuttle.
    - todd3834 5y ago
      I read this as sometimes you need to use an exit hatch like Canvas instead of a bunch of hacks to make a WYSIWYG editor strictly with the DOM. Google seemed to come to the same realization and that is why they are using Canvas
    - closeparen 5y ago
      Just send LibreOffice files as attachments via your personal email server, what’s the problem? /s
jcuenod 5y ago
I had this instinct as well but I think this is about rendering, not necessarily editing. The document link is not to something editable. Granted, perhaps these will merge.
nailer 5y ago
> The APIs for text manipulation in the DOM are abysmal I develop an NLP labelling interface (which is similarly document-focused) in JS all day and can attest to this. Here's some specific examples: - To work out where some text is being being laid out, eg to display some UI around it, the Selection/Range/Rect APIs will help but Rects are always viewport-relative, so you'll need to convert them to element-relative to position your UI, which sucks. - Firefox supports multiple DOM Ranges per Selection (ie allows non continguous text selection), but nearly all other browsers support a single range. - You can't truncate text across multiple lines (the CSS line clamp spec is an experimental fix) - If you want to pop up an interface while some text is selected, you'll need to capture and reimplement selection because as soon as another item is focused the selection will no longer display. If you're into JS and building anything document related, I've written a bunch about the some of the issues at https://humanloop.com/blog/how-to-build-an-ml-labelling-interface-in-javascript/ https://humanloop.com/blog/how-to-build-an-ml-labelling-inte...
intpx 5y ago
teach markdown in schools. who needs word processors anyway? need something fancier than headings, lists, block-quotes etc? learn LaTeX. Text rendering can be fantastic in the browser. I'm half joking, but I think the world would be a better place if folks had fewer, more precise ways of making words look the way they want
- nindalf 5y ago
  I love markdown, all my blog posts, TILs, book notes are in it. Even my presentations are written in markdown. But this comment is so obtuse and user hostile. Millions of people know how to use word processors. Let's not take that away from them or even imply that they're doing it wrong. They're fine. Software can always be improved, like the Docs team is attempting here. But we can't overnight tell people that their skills are obsolete because some developers somewhere like Markdown and Latex.
- discreteevent 5y ago
  To me this is like saying that because we are no longer able to make good bicycles people should walk everywhere.
- jamiek88 5y ago
  Shouldn’t software serve people rather than the other way around? This comes across as a ‘you’re holding it wrong’ type argument.
baybal2 5y ago
> every in-browser WYSIWYG text editor is a steaming pile of hacks. Xforms 2.0, and other opportunities to have rich text in browser not suck were there for the browser maker to take in the last 15 years. Instead they tried almost everything instead of choosing the most obvious solution, and fixing it.
tablespoon 5y ago
> Just for what it’s worth, “word processors” are a logical starting point specifically because the APIs for text manipulation in the DOM are abysmal, and every in-browser WYSIWYG text editor is a steaming pile of hacks. If that's the case, it probably would have been better to standardize some better APIs.
- slver 5y ago
  You assume the developers of Google Docs are the developers of Chrome and WHATWG
austincheney 5y ago
Whether or not it’s a trend will come down only to the commonality of skills in the marketplace for a given rate of pay.

kmeisthax 5y ago

Furthermore, actually implementing your own text renderer and input engine in WASM is a different horrible nightmare, because you've now forfitted any chance of supporting IMEs (e.g. touch keyboards, pinyin/romaji/kanji input, iPadOS Scribble), you need to implement your own text selection inputs, your text won't show up in the accessibility tree, and you can't copy-paste without additional, browser-specific tweaks. The only reason to actually do this is if you can't use HTML. Source: I am a Ruffle developer and have had to do exactly this to support text input in old Flash games.

pmontra 5y ago
> you can't copy-paste without additional, browser-specific tweaks Expect an AI-based OCR browser extension to copy text to the system clipboard. Possibly by sending screenshots to some centralized service ;-)
- kbenson 5y ago
  This would be more funny if it was less prescient.

bri3d 5y ago

A million times this - having worked in this space, nobody wants to do this. I understand the cynicism, but the affordances provided by the browser for things like accessibility are very painful to give up. This isn't some dark pattern attempt to cut out whatever "openness" remains on the web, or to convert the browser into a display-streaming client for some sinister DRM reason. In my past job, we rewrote our spreadsheet rendering to use canvas and gained massively in simplicity and maintainability. And there was no obfuscation angle to it - we even shipped source maps! Handling accessibility and text input was hard (we ended up adopting a hybrid-DOM model where some things like input fields were still native ones, or shadowed by native ones), and even then it was still easier than dealing with browser rendering. This is simply a reasonable way to work around the DOM being trash. The way to fix this trend would be to reimagine the presentation layer of the browser as something other than a stack of hacks over hypertext, but so far nobody seems to have a good solution.

mixmastamyk 5y ago
Once the trail has been blazed by pioneers, expect a gold rush. What would a good API look like, I wonder?
vagrantJin 5y ago
The dom isn't trash. Its good enough. We just need to stop making it do things it wasn't supposed to. That's why things like electron make sense a little bit. Not perfect but sensible.
- nindalf 5y ago
  > We just need to stop making it do things it wasn't supposed to This is a thread about Google Docs. Your suggestion to the Docs team is to ... stop? Just shut down their product?
  - vagrantJin 5y ago
    Oh no. They're google. They make a godforsaken browser. They can pay people to do nothing more than think about code. By all means. They can launch a satellite with css if they want. But the rest of us plebs...
    - scotty79 5y ago
      Btw for NASA css is shorthand for Control Stick Steering, which is something you did at later stages of landing with a space shuttle.
  - todd3834 5y ago
    I read this as sometimes you need to use an exit hatch like Canvas instead of a bunch of hacks to make a WYSIWYG editor strictly with the DOM. Google seemed to come to the same realization and that is why they are using Canvas
  - closeparen 5y ago
    Just send LibreOffice files as attachments via your personal email server, what’s the problem? /s

jcuenod 5y ago

I had this instinct as well but I think this is about rendering, not necessarily editing. The document link is not to something editable. Granted, perhaps these will merge.

nailer 5y ago

> The APIs for text manipulation in the DOM are abysmal I develop an NLP labelling interface (which is similarly document-focused) in JS all day and can attest to this. Here's some specific examples: - To work out where some text is being being laid out, eg to display some UI around it, the Selection/Range/Rect APIs will help but Rects are always viewport-relative, so you'll need to convert them to element-relative to position your UI, which sucks. - Firefox supports multiple DOM Ranges per Selection (ie allows non continguous text selection), but nearly all other browsers support a single range. - You can't truncate text across multiple lines (the CSS line clamp spec is an experimental fix) - If you want to pop up an interface while some text is selected, you'll need to capture and reimplement selection because as soon as another item is focused the selection will no longer display. If you're into JS and building anything document related, I've written a bunch about the some of the issues at https://humanloop.com/blog/how-to-build-an-ml-labelling-interface-in-javascript/ https://humanloop.com/blog/how-to-build-an-ml-labelling-inte...

intpx 5y ago

teach markdown in schools. who needs word processors anyway? need something fancier than headings, lists, block-quotes etc? learn LaTeX. Text rendering can be fantastic in the browser. I'm half joking, but I think the world would be a better place if folks had fewer, more precise ways of making words look the way they want

nindalf 5y ago
I love markdown, all my blog posts, TILs, book notes are in it. Even my presentations are written in markdown. But this comment is so obtuse and user hostile. Millions of people know how to use word processors. Let's not take that away from them or even imply that they're doing it wrong. They're fine. Software can always be improved, like the Docs team is attempting here. But we can't overnight tell people that their skills are obsolete because some developers somewhere like Markdown and Latex.
discreteevent 5y ago
To me this is like saying that because we are no longer able to make good bicycles people should walk everywhere.
jamiek88 5y ago
Shouldn’t software serve people rather than the other way around? This comes across as a ‘you’re holding it wrong’ type argument.

baybal2 5y ago

> every in-browser WYSIWYG text editor is a steaming pile of hacks. Xforms 2.0, and other opportunities to have rich text in browser not suck were there for the browser maker to take in the last 15 years. Instead they tried almost everything instead of choosing the most obvious solution, and fixing it.

tablespoon 5y ago

> Just for what it’s worth, “word processors” are a logical starting point specifically because the APIs for text manipulation in the DOM are abysmal, and every in-browser WYSIWYG text editor is a steaming pile of hacks. If that's the case, it probably would have been better to standardize some better APIs.

slver 5y ago
You assume the developers of Google Docs are the developers of Chrome and WHATWG

austincheney 5y ago

Whether or not it’s a trend will come down only to the commonality of skills in the marketplace for a given rate of pay.