3 ms·

Or we could take a look at the example Google Doc linked in TFA - https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview https:

Or we could take a look at the example Google Doc linked in TFA - https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS... Seems like it's fast (on my machine at least), can select text and Ctrl+F works. I totally understand the urge to complain and doom say, but could we at least stick to the example at hand? I'm sure if you went through this doc you'd find things to complain about. That would be more relevant to the discussion.

capitainenemo 5y ago
After trying it for a few seconds, noticed X select-to-copy was broken, as well as the browser spellcheck feature that my daughter relies on heavily in Google Docs (where a text area can be spellchecked in french or english depending on the active spellcheck). I didn't spend more than a few seconds on it, but those were the features I immediately noticed. This is going to be a painful transition for us since she uses both of those a great deal with her schoolwork. Since the doc was read-only, I couldn't test IME/XCompose - hopefully those work at least.
- nindalf 5y ago
  And they speak about plugins being broken in TFA. I'm not surprised that your daughter's plugin doesn't work today, because they announced the change today. Presumably, those plugins can be rewritten to adapt to canvas. Just give them time.
  - capitainenemo 5y ago
    Well, I was referring to the built-in browser spellcheck and the X windows copy/paste. Both of those probably rely more heavily on normal native widgets. Not saying it is impossible of course. The X windows copy/paste could be done using the invisible text approach firefox uses in PDF.js. That would also help with accessibility somewhat. But I'm not sure how they could integrate with browser spellcheck without basically going back to a less canvas-y approach. Invisible text areas surely would have layout problems aligning with the rendered font. But, I guess we'll see. I'm guessing Linux users are not a major factor in their decisions though. Firefox users probably even less so.

capitainenemo 5y ago

After trying it for a few seconds, noticed X select-to-copy was broken, as well as the browser spellcheck feature that my daughter relies on heavily in Google Docs (where a text area can be spellchecked in french or english depending on the active spellcheck). I didn't spend more than a few seconds on it, but those were the features I immediately noticed. This is going to be a painful transition for us since she uses both of those a great deal with her schoolwork. Since the doc was read-only, I couldn't test IME/XCompose - hopefully those work at least.

nindalf 5y ago
And they speak about plugins being broken in TFA. I'm not surprised that your daughter's plugin doesn't work today, because they announced the change today. Presumably, those plugins can be rewritten to adapt to canvas. Just give them time.
- capitainenemo 5y ago
  Well, I was referring to the built-in browser spellcheck and the X windows copy/paste. Both of those probably rely more heavily on normal native widgets. Not saying it is impossible of course. The X windows copy/paste could be done using the invisible text approach firefox uses in PDF.js. That would also help with accessibility somewhat. But I'm not sure how they could integrate with browser spellcheck without basically going back to a less canvas-y approach. Invisible text areas surely would have layout problems aligning with the rendered font. But, I guess we'll see. I'm guessing Linux users are not a major factor in their decisions though. Firefox users probably even less so.