My immediate testing: doesn’t share the system search pasteboard, so hobbles search on Mac, they don’t allow editing of their sample so I have no idea how IMEs are going to work, they have to because IMEs include accessibility inputs.
I have yet to encounter any GUI API (web or otherwise) that does digital typography decently. Does anyone know of one that, for example, supports the notion of a baseline grid? See also: font size is useless; let’s fix it.
Because digital typography for the masses is a bad idea. The whole concept of showing a paper page on a screen as a canvas (no pun intended) and use typographic elements as your artist brush is intricate per se.
I think the average Joe would be better served with something in the lines of markdown if only it was what they first had exposure to. WYSIWYG editors have this aura of being simple and direct but their complexity explodes in your face after less than a handful of elements.
I’m using “API” as an umbrella term. Over the years I’ve played with a variety of tools, sometimes called “APIs” or “SDKs” or “toolkits” or, in the case of the web, an amalgam of standards… which include APIs. Whatever you call them, I’m thinking of tools developers use to build software applications with graphical user interfaces (GUI). Here are some examples of what I mean:
HyperCard + HyperTalk
Swing
Qt
BabylonJS GUI
And, of course, native web APIs
There are others that I’m curious about but am less familiar with (SwiftUI comes to mind). I’m genuinely curious to know if any of them give developers the means to lay out text using principles that have established in the graphic design world for almost a hundred years now by luminaries such as Robert Bringhurst or Josef Müller-Brockman. All of the tools I’ve used seem to treat typography as an afterthought.
I think that’s overly pessimistic. The specific problem here is trying to embed one docment layout system in another. Few apps need to customize the specifics of eg. text layout to nearly the same extent as Google docs.
And though I empathize with the idea that it needn’t be this way, I haven’t found many better systems for application distribution than the web. Though maybe I really do just need to sell my soul to QT.
Your argument about “I haven’t found many better systems for application distribution than the web” is somewhat defeated by the very nature of web browsers.
Google distributes an application to multiple platforms with regular automated updates. It’s called Chrome. It’s a POS memory hogging privacy abusing whore of satan, but that’s not really related to it being native or not - Google manages to push those qualities into browser based ‘apps’ too.
But instead of knocking a few layers off the stack and starting again from something akin to the webrender part of what would have been Servo, they’re just re-inventing a lower layer on top of the tower of poop that is the DOM.
I guess it still works offline, so not quite just a X-server style thin client, but I like to say the browser is a separate platform - it has more in common with, say, Linux or Windows than it does with Notepad and Paint. It offers its native ui in html then its own ipc, filesystem, and networking, and most the other services you expect from a higher level operating system.
But this kind of thing moves even further than that; it pushes the browser more and more toward just being a peculiar VM. How long until someone is like “all we need to do is push pixels to the screen” and invents Waybrowser? lol
Anyway I’d imagine there might be some benefits here in abstracting to provide “native” apps for mobile and such too and break out of the browser. If you only use lowest common denominator features, it is a bit easier to abstract them out. (I use scare quotes btw since in my mind if you aren’t using the native ui facilities, it isn’t really a native experience. And that brings some good questions here: will I still be able to copy and paste out of a google doc? Use my beloved middle click? Maybe only on google chrome….)
But this kind of thing moves even further than that; it pushes the browser more and more toward just being a peculiar VM. How long until someone is like “all we need to do is push pixels to the screen” and invents Waybrowser? lol
GTK+ supports the “Broadway” backend, which runs GTK+ apps in a canvas element in a browser. The future is now!
This was my thought as well, but it’s parallel evolution. Looking at the DOM, everything is still labeled kix (the Docs internal framework). I doubt the Docs team would bet such a critical product on Dart/Flutter.
We haven’t been “together” as a team in 16 months, for any reason…
I’m all ears for a good workflow that handles collaboration on docs on the scale we have to deal with, though. If I were designing a standard publication workflow, that’d be one thing - unfortunately we have to ingest content from all over the organization and includes many, many hands in the content before it winds up in the CMS.
Oh! And a second similar tale - at one client we wanted to manage docs in GitHub, but they had a corporate wiki where all such stuff was expected to live (Jive, I think?)
Anyone one enterprising developer wrote a tool that used Jekyll (IIRC) to publish the Markdown content in GitHub to HTML, then stuffed it into Jive with a footer linking back to the original GitHub repo.
Back at Lonely Planet, years before Docs existed I think, we built an add-on for OpenOffice that allowed authors to submit content to an HTTP API from within OpenOffice itself. That allowed non technical staff to work with familiar tooling - a word processor - but still integrate tightly with our publishing system.
Presumably you could do a similar thing with Google Docs - some sort of a “publish to the CMS” button, or an automated job, or something. The challenge would be two-way sync, if people are also editing in Drupal.
(Modern?) Rich editors on the web use browser APIs to provide custom implementations of copy; it’s very unlikely that when you copy from Google Docs you’re just getting the browser’s default behavior.
The previous iteration of Docs isn’t even using ContentEditable - they draw the cursor with a div & CSS animation already.
CKEditor for instance used to take the HTML produced by the browser’s contentEditable implementation, parse it, attempt to normalise it a bit into some kind of vaguely comprehensible HTML and then serialise the HTML. I assume it still does?
As someone who works on rich editors for the web (https://notion.so), this move makes complete sense for both performance and reliability. With Canvas/WebGL & a custom framework, Docs has much complete control over rendering, and render latency. They have much lower exposure to user agent differences. And, as a megacorp with infinite engineers, they can bear the much higher cost of building everything themselves.
My immediate testing: doesn’t share the system search pasteboard, so hobbles search on Mac, they don’t allow editing of their sample so I have no idea how IMEs are going to work, they have to because IMEs include accessibility inputs.
Are you sure you were looking at a canvas version? I’m still seeing their DOM-based “kix” editor.
I used the example doc that they linked to
Ah. I missed that. Thanks.
It’s almost like Google is acknowledging that a browser isn’t the best place for non-trivial applications.
I have yet to encounter any GUI API (web or otherwise) that does digital typography decently. Does anyone know of one that, for example, supports the notion of a baseline grid? See also: font size is useless; let’s fix it.
Because digital typography for the masses is a bad idea. The whole concept of showing a paper page on a screen as a canvas (no pun intended) and use typographic elements as your artist brush is intricate per se.
I think the average Joe would be better served with something in the lines of markdown if only it was what they first had exposure to. WYSIWYG editors have this aura of being simple and direct but their complexity explodes in your face after less than a handful of elements.
what exactly do you mean by GUI API?
I’m using “API” as an umbrella term. Over the years I’ve played with a variety of tools, sometimes called “APIs” or “SDKs” or “toolkits” or, in the case of the web, an amalgam of standards… which include APIs. Whatever you call them, I’m thinking of tools developers use to build software applications with graphical user interfaces (GUI). Here are some examples of what I mean:
There are others that I’m curious about but am less familiar with (SwiftUI comes to mind). I’m genuinely curious to know if any of them give developers the means to lay out text using principles that have established in the graphic design world for almost a hundred years now by luminaries such as Robert Bringhurst or Josef Müller-Brockman. All of the tools I’ve used seem to treat typography as an afterthought.
I think that’s overly pessimistic. The specific problem here is trying to embed one docment layout system in another. Few apps need to customize the specifics of eg. text layout to nearly the same extent as Google docs.
And though I empathize with the idea that it needn’t be this way, I haven’t found many better systems for application distribution than the web. Though maybe I really do just need to sell my soul to QT.
Your argument about “I haven’t found many better systems for application distribution than the web” is somewhat defeated by the very nature of web browsers.
Google distributes an application to multiple platforms with regular automated updates. It’s called Chrome. It’s a POS memory hogging privacy abusing whore of satan, but that’s not really related to it being native or not - Google manages to push those qualities into browser based ‘apps’ too.
But instead of knocking a few layers off the stack and starting again from something akin to the
webrenderpart of what would have been Servo, they’re just re-inventing a lower layer on top of the tower of poop that is the DOM.[Comment removed by author]
I guess it still works offline, so not quite just a X-server style thin client, but I like to say the browser is a separate platform - it has more in common with, say, Linux or Windows than it does with Notepad and Paint. It offers its native ui in html then its own ipc, filesystem, and networking, and most the other services you expect from a higher level operating system.
But this kind of thing moves even further than that; it pushes the browser more and more toward just being a peculiar VM. How long until someone is like “all we need to do is push pixels to the screen” and invents Waybrowser? lol
Anyway I’d imagine there might be some benefits here in abstracting to provide “native” apps for mobile and such too and break out of the browser. If you only use lowest common denominator features, it is a bit easier to abstract them out. (I use scare quotes btw since in my mind if you aren’t using the native ui facilities, it isn’t really a native experience. And that brings some good questions here: will I still be able to copy and paste out of a google doc? Use my beloved middle click? Maybe only on google chrome….)
GTK+ supports the “Broadway” backend, which runs GTK+ apps in a canvas element in a browser. The future is now!
I can’t imagine Google will break that.
Nah you’ll have a “share” icon hidden in a hamburger menu somewhere, that will take someone else to your particular snipped on Google Docs.
Sadly it’s been semi-broken for years already. You can use keyboard shortcuts but not context menus to paste (at least in Safari).
Dogfooding Flutter?
This was my thought as well, but it’s parallel evolution. Looking at the DOM, everything is still labeled
kix(the Docs internal framework). I doubt the Docs team would bet such a critical product on Dart/Flutter.We use Google Docs and then paste content into Drupal. I’m wondering if this will have any impact at all in terms of carrying over styles to Drupal.
I hope that at least once a year, you get together as a team and burn effigies of the developer who bequeathed you that workflow.
We haven’t been “together” as a team in 16 months, for any reason…
I’m all ears for a good workflow that handles collaboration on docs on the scale we have to deal with, though. If I were designing a standard publication workflow, that’d be one thing - unfortunately we have to ingest content from all over the organization and includes many, many hands in the content before it winds up in the CMS.
Oh! And a second similar tale - at one client we wanted to manage docs in GitHub, but they had a corporate wiki where all such stuff was expected to live (Jive, I think?)
Anyone one enterprising developer wrote a tool that used Jekyll (IIRC) to publish the Markdown content in GitHub to HTML, then stuffed it into Jive with a footer linking back to the original GitHub repo.
Back at Lonely Planet, years before Docs existed I think, we built an add-on for OpenOffice that allowed authors to submit content to an HTTP API from within OpenOffice itself. That allowed non technical staff to work with familiar tooling - a word processor - but still integrate tightly with our publishing system.
Presumably you could do a similar thing with Google Docs - some sort of a “publish to the CMS” button, or an automated job, or something. The challenge would be two-way sync, if people are also editing in Drupal.
(Modern?) Rich editors on the web use browser APIs to provide custom implementations of copy; it’s very unlikely that when you copy from Google Docs you’re just getting the browser’s default behavior.
The previous iteration of Docs isn’t even using ContentEditable - they draw the cursor with a div & CSS animation already.
CKEditor for instance used to take the HTML produced by the browser’s contentEditable implementation, parse it, attempt to normalise it a bit into some kind of vaguely comprehensible HTML and then serialise the HTML. I assume it still does?
I’m curious how much of this is perhaps driven to derail screen scraping.
I’m scratching my head here. Do people actually screen-scrape Google Docs?
Even if they did, why would Google want to disable this? Are there docs out there being accessed by thousands of bots at the same time?
Answer is: probably
Or adblocking.
I am wondering if it is to get decent performance on low-spec Chromebooks.
As someone who works on rich editors for the web (https://notion.so), this move makes complete sense for both performance and reliability. With Canvas/WebGL & a custom framework, Docs has much complete control over rendering, and render latency. They have much lower exposure to user agent differences. And, as a megacorp with infinite engineers, they can bear the much higher cost of building everything themselves.