Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Google IT Technology

Google Says Docs Will Now Use Canvas Based Rendering, Warns Impact on Some Chrome Extensions (googleblog.com) 91

Google, making the announcement in a blog post: We're updating the way Google Docs renders documents. Over the course of the next several months, we'll be migrating the underlying technical implementation of Docs from the current HTML-based rendering approach to a canvas-based approach to improve performance and improve consistency in how content appears across different platforms. We don't expect this change to impact the functionality of the features in Docs. However, this may impact some Chrome extensions, where they may no longer work as intended.

Some Chrome extensions rely on the way the backend of a Google Doc is structured or specific bits of HTML to function properly. By moving away from HTML-based rendering to a canvas-based rendering, some Chrome extensions may not function as intended on docs.google.com and may need to be updated. Admins should review the current extensions deployed in their organization. [...] If you are building your own integrations with Google Docs, we recommend using Google Workspace Add-ons framework, which uses the supported Workspace APIs and integration points. This will help ensure there will be less work in the future to support periodic UI implementation changes to Docs.

This discussion has been archived. No new comments can be posted.

Google Says Docs Will Now Use Canvas Based Rendering, Warns Impact on Some Chrome Extensions

Comments Filter:
  • Using dark mode is better for sleep hygiene... I hope they'll implement some native dark mode as this will break compatibility with extensions like Dark Reader.
    • by Tablizer ( 95088 )

      Just have a negative option. So what if people have green radioactive faces.

      • by Tablizer ( 95088 )

        Actually thinking about it further, if the images can be isolated (identified), they don't have to be reversed. Only things like text, borders, and buttons need to be reversed. Sure, there are a few grey areas (no pun intended), but not enough to sink the idea.

    • Just the most recent thing I could find that disputes the sleep hygiene claim and there are others disputing the eye strain claims as well.

      https://news.byu.edu/intellect... [byu.edu]

      BTW this is not saying that blue light isn't bad for sleep hygiene, just that things that try to mitigate blue light exposure don't actually work. The solution is simply don't use devices close to bedtime.

  • by Dracos ( 107777 ) on Wednesday May 12, 2021 @11:46AM (#61377174)

    We've gone from "don't use tables for layout" to "let's use pictures for everything."

    Meanwhile, Google is still trying to kill the open web.

    • Well, your browser usuall renders it to pictures anyway.
      The core problem is that the semantic interface below it is missing.
      The parse tree, so to speak.

      If that would still exist, but simply not be HTML, it'd still be fine.
      TeX, PS, SQL, (Linux's) VFS, 9P, ... would all be acceptable interfaces.

    • by Tablizer ( 95088 ) on Wednesday May 12, 2021 @12:37PM (#61377444) Journal

      Semantic has overcomplicated things. Maybe there's a right way to do semantics, but JS/DOM/CSS did it the wrong way, or at least a way that is a poor fit for too many needs.

      Things like Bootstrap dragged GUI's down to a lowest common denominator, making for C- mobile and C- desktops. Business-oriented GUI's need real GUI idioms to be productive, and faking it with JS/DOM/CSS is an ugly time drain that only a UI specialist's paycheck can love.

      We can keep DOM's semantics, but give us a decent WYSIWYG alternative for the times where DOM requires rocket science to do common GUI shit.

    • Isn't Google the Internet? Years ago, IE and/or AOL was considered 'The Internet'. These days and for better or worse, is it Google.
      It is long past time that Google was broken up into a gazillion little bits.

    • Meanwhile, Google is still trying to kill the open web.

      By using open web standards first supported by Firefox?

  • They will effectively murdeded the openness of the web, and turned it into closed source with proprietary formats.

    • by Cmdln Daco ( 1183119 ) on Wednesday May 12, 2021 @12:26PM (#61377404)

      Netscape's whole scheme was to give out a free browser, but havr propritary tweaks to make it connect to their proprietaty server tech. Miscrosoft interpreted it as a threat to their desktop and attacked.

      There was no 'good side' in the Netscape vs. Microsoft battle in the early period. After Netscape poached the NCSA Mosaic team it was a battle of propritary schemes.

      Only later after Microsoft 'won' was the Mozilla codebase open-sourced.

      • by Scoth ( 879800 )

        People forget that there was an early "Boycott Netscape!" initiative in the 1.x/2.x days because of it using proprietary tags that people felt endangered the open web. Internet Explorer 1.0 and 2.0 were initially praised for following standards closely while being an improvement over existing options. Of course, we saw what happened with IE 5, 5.5, and 6 where the tables were turned entirely and Netscape/Mozilla became the darling of the open source standards compliant world, but that's not how it was at fi

  • by rsilvergun ( 571051 ) on Wednesday May 12, 2021 @11:53AM (#61377228)
    It means they've got a proprietary API for their app UI similar to Win32, doesn't it? That makes it completely opaque to the extension author. Or am I missing something? I haven't looked in ages but isn't the canvas just a place to draw bitmaps and vectors?
  • by UnknownSoldier ( 67820 ) on Wednesday May 12, 2021 @12:01PM (#61377274)

    Does using a canvas screw over people reliant on Text-to-Speech?

    • by Rob Y. ( 110975 )

      interesting angle. I suppose Google could 'render' docs as speech rather than as a canvas for people who need that. Or, they could download the docs and render them in a local app independent of the browser. Do Chromebooks have text-to-speech capability? If not, they're probably not very useful for sight-impared users - who would continue to need a traditional desktop system for that...

    • by Tablizer ( 95088 )

      WYSIWYG and ADA (sight impaired) support are not mutually exclusive. It's quite possible to tag a given content item with both display and semantic info, they don't have to conflict. Whether they do in practice is mostly an implementation and standards definition issue.

      The "for" attribute in LABEL html tags is an example. It associates the label with a given input box semantically. It still works if the label and the box are far apart in the HTML and/or the screen. It's orthogonal to markup or screen positi

    • by _xeno_ ( 155264 ) on Wednesday May 12, 2021 @01:36PM (#61377688) Homepage Journal

      Short answer: yes, long answer: they thought of that.

      If you look at their sample document and then throw up the Accessibility Inspector, you'll find two pieces of actual content: a section that says "To enable screen reader support, press Ctrl+Alt+Z To learn about keyboard shortcuts, press Ctrl+slash", and a link that says "Turn on screen reader support".

      Pressing Ctrl+Alt+Z lets me discover that some other piece of software uses that as a global shortcut. But what it does with "screen reader support" enabled is "render" individual text elements as offscreen elements only the screen reader can see. You otherwise navigate through the document using keyboard commands, but only the part of the document that's "visible" is actually present.

      So yes, switching to canvas screws over people using screen readers, but you can turn on screen reader support. In their example at least it looks like you have to do that every single time.

  • by Tablizer ( 95088 ) on Wednesday May 12, 2021 @12:27PM (#61377410) Journal

    I've ranted many times that we need a state-ful GUI markup language standard that directly supports the common GUI idioms for "productivity" applications. It should have a coordinate vector mode (WYSIWYG) even if it also includes a client-side auto-flow engine. This will allow one to optionally pick a server-side layout engine of choice rather than be stuck with the DOM as one-size-fits-all. It doesn't. It's why PDF still lives: DOM butchers text positions per different browser brands, versions, and OS DPI settings.

    HTML Canvas was not meant for rich GUI's and interactive charts (like flow-charts and ERD's). Thus, many GUI idioms still have to be reinvented via JS libraries.

    Rather than start from scratch, perhaps the Qt or Tk GUI engines can be used to build a GUI browser and/or GUI browser pluggin. And please don't compare it to Java Applets and Flash, for they tried to be an entire OS and bit off more than they could chew. Focus just on state-ful GUI's and only state-ful GUI's, shifting most of the burden to the server, leaving less crap to break and hack.

    You'd need much less JS, if any, because most GUI idioms would be built into the standard. For example, having a button open (or set focus to) a window should be a declarative "on-click" action such that scripting isn't needed. It's part of the markup. Using JS/DOM to re-re-re-invent rich GUI's has been a Great Mistake, wasting billions of hours of labor and grey hair. It's good job security for UI/UX "experts", but a wallet sucker for everyone else. MGUIGA! Have the web unfuck GUI's this time around. The vast majority of real work gets done via mice, not fingers. You wanna finger?!

    • XUL? Qt's web target?

      • by Tablizer ( 95088 )

        I personally didn't like XUL, it seemed verbose for common GUI/CRUD use. And it may not solve the consistent text positioning problem. But it died anyhow.

        • Well that's kind of the nature of XML [fandom.com] regardless of how it's being used, explaining the popularity of JSON. The core idea was sound though.

          • by Tablizer ( 95088 )

            I'd be okay with a JSON-based GUI markup standard. It's better than the status quo of DOM-only. XML vs. JSON is a secondary issue, and they are more or less interchangeable.

    • Focus just on state-ful GUI's and only state-ful GUI's, shifting most of the burden to the server

      That'd break the Service Worker-driven tolerance of Internet connection interruption that some developers in the progressive web app community have been pushing. See "Say Hello to Offline First" [hood.ie].

      • by Tablizer ( 95088 )

        For clarity I'm mostly thinking of business applications, especially intranet. Things like ecommerce and social networks don't really need highly-tuned and compact GUI's.

        I'm not asking to get rid of HTML and DOM, only supplement it with a GUI-centric standard. It's not either/or.

      • It also seems to be the approach Atlassian take with jira, and it is absolutely horrible to use.

  • Question: (Score:5, Interesting)

    by ElizabethGreene ( 1185405 ) on Wednesday May 12, 2021 @12:39PM (#61377450)

    Is my intuition correct that this will make text images so that you can't copy rendered text without going through an API call to populate the clipboard?

    (Forgive me if this is a dumb question; I'm asking from a position of ignorance.)

    • by lsllll ( 830002 )
      Your intuition would appear to be correct. I can't see it working any other way. In a way, Google appears to be reigning the control of Docs in and away from anyone else who could access it. I can see the upside of this: having to go through their API to access the data would make things more secure. However, I don't trust Google as the gatekeeper. This may be a ploy by Google to tell everyone else "Hands off our contribution to office productivity, unless x, y, and z."
    • by gweihir ( 88907 )

      Pretty much.

  • Currently, users can download G Docs documents in .odt, .docx, .html, .pdf, etc. formats. Is the current menu of choices likely to change? Specifically, will .html downloads likely be discontinued? And, does this increase the likelihood that .tex downloads will become available?
  • Because that is known to be a really nice way to track computers and hence users. If people generally reactivate canvas grab, that would allow Google to not only track (when users are not in Docs), but also identify (when users are in Docs). Hence they whole thing may yet be another part of the efforts by Google to replace tracking cookies with something even worse.

    Yes, I am paranoid with regards to the evil of Google. But I am pretty sure they really are out to get everybody.

    • "Canvas grab" What is that? Do you mean the technique of using a canvas element to fingerprint you for tracking purposes?

      Are you talking about the visibilitychange event?

      You can override that event and trick a site to think their site is always viewed by the user. I override it all the time because some link sites stop the countdown if you switch over to another site to wait for the countdown to reach zero. It's a very easy userscript to write.

      The visibilitychange event was meant to inform the site to stop/

      • Should mention google and other browsers know about the canvas fingerprinting and some browsers have implemented measures to prevent those methods. Canvas isn't the only way to fingerprint. It's one of many ways. For instance the way you move your mouse cursor when interacting or moving the cursor over a site can be used to fingerprint you, at least localize you to a smaller group which can be useful for tracking.

        The way you type, the delay between key presses, how you for formulate your sentences, etc can

  • Oh please! They're only using performance as an excuse to do this. They've done it many of times with the Chrome extension API when extensions have popped up that google didn't like. So they deprecated and replaced old APIs with new ones because they "preforms better". Here's the real reason: I'll just say it when no other comment have. Moving to canvas and forcing extension developers to use google's API is a move that will give google total control over what you can do to Docs. I wonder what Docs extensio

Some people claim that the UNIX learning curve is steep, but at least you only have to climb it once.

Working...