Support our independent tech coverage. Chrome Unboxed is written by real people, for real people—not search algorithms. Join Chrome Unboxed Plus for just $2 a month to get an ad-free experience, access to our private Discord, and more. Learn more about membership here.
START FREE TRIAL (MONTHLY)START FREE TRIAL (ANNUAL)
One of the things I love about both Chrome and Chrome OS is the open-source development the platforms utilize to bring us updates. Part of that update and development process includes multiple installable, usable development channels that general users can mess around with if the mood hits them right.
We’ve been known to spend long periods of time in any given channel at any given time. The ability to freely move between them and see new features before they become official is such a fun part of being a Chrome OS user. While not for everyone, There are many of you out there that would really benefit from giving the Beta or Dev Channels a try from time to time. Other than a bit of local data loss as you move back towards a more stable build, there’s really no risk involved.
Shop Chromebook Deals at Chrome Shop
Dinsan Francis of Chrome Story is a guy who likes to live in the Canary Channel and I can’t recommend that for most users. It is highly unstable (as Gabriel will be quick to point out after he spends weeks with his devices in that state) and not good for daily work, but you also get to see all sorts of cutting-edge features that may or may not ever make it to the Stable Channel. Dinsan has spotted one of those features and, once implemented, I think it will go a long way to making web apps and PWAs behave and feel much more native on our devices.
Raw Clipboard Access
A flag for Raw Clipboard Access (chrome://flags/#raw-clipboard) has shown up in the Canary channel of Chrome and Chrome OS and it does basically what you would expect: it exposes all the bits and pieces of a website or app to be copied and pasted across the platform. Here’s language from a public development git about the feature:
Powerful web applications would like to exchange data with native applications via the OS clipboard (copy-paste). The existing Web Platform has a high-level API that supports the most popular standardized data types (text, image, rich text) across all platforms. However, this API does not scale to the long tail of specialized formats. In particular, non-web-standard formats like TIFF (a large image format), and proprietary formats like .docx (a document format), are not supported by the current Web Platform.
Raw Clipboard Access aims to provide a low-level API solution to this problem, by implementing copying and pasting of data with any arbitrary Clipboard type, without encoding and decoding.
OK, so some of you got that. Some of you didn’t, and that’s OK. All this means is, in general, the way that copy/paste works in existing web platforms is pretty basic. You can grab text, images, and some rich text queues (think bold, italic, etc.), but the deeper and more integrated stuff simply won’t come along for the ride when you go to paste it somewhere.
SUBSCRIBE TO UPSTREAM
Get Chrome Unboxed delivered straight to your inbox
Upstream is our flagship, curated newsletter with the top stories, most click-worthy deals, giveaways, and trending articles from Chrome Unboxed sent directly to your inbox a few times a week. Join 31,000+ subscribers.
This new setup would have standard web content stick with the current setup and allow developers to grant deeper access to their web apps for copy/paste purposes. A big part of this is the need to share deeper info in the copy/paste function with other platform-level, native applications. They list a few examples of where this would be handy and maybe even necessary in the git:
- Online editors like Google Docs or Microsoft Office 365, copy/paste OpenOffice or Microsoft Word documents/spreadsheets/presentations (proprietary formats).
- Figma or Photopea, to copy/paste PhotoShop/GIMP, GIFs, or RAW images, or already-supported formats with not-supported metadata (long tail of metadata).
- Web Apps supporting “niche” types, like LaTeX, .ogg, etc (long tail of formats).
All that data coming along for the entirety of the copy/paste process will make some pretty complex operations possible when grabbing content from a web app and moving it to a more standard app. Imagine using a web-based vector editor, highlighting your entire workspace, and then copying that into something like Adobe Illustrator with no loss of data, layouts, or meta data. I don’t know why you’d do that exact example, but you get the point. Complex moves like this could be possible in the future and only extend the functionality of web-based applications that much further.
Part of why I use a Chromebook and Chrome OS is my love for the open web. I love the democracy of it. I love the open-sourced nature of it. I love seeing tech develop in a place without bounds and borders. Is it messy? Sure. Is it a bit slower? Yeah. But the limits of what people can build, distribute, and create when open web-based technologies advance are so far reaching that I will always champion the web over closed, native applications. There’s still work to be done, but we are inching ever closer to the dream of the web as a full-blown app delivery service that knows no OS, no device, and no boundaries. I’m excited for that future.
