Hacker News Reader

Comment by burlesona | Hacker News Reader

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.

View on HN

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.

Once the trail has been blazed by pioneers, expect a gold rush.

What would a good API look like, I wonder?

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.

Isn't Electron rendering to an embedded Chromium and therefore the DOM as well?

Yes

I'd agree. I think the DOM is fantastic, *unless* you are doing advanced document manipulation, in which case it is trash (for that use case only). This is what I'm assuming the author meant.

I spent many years working on that sort of thing, a decade 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?

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...

Btw for NASA css is shorthand for Control Stick Steering, which is something you did at later stages of landing with a space shuttle.

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

Just send LibreOffice files as attachments via your personal email server, what’s the problem?

Well, to be fair Libre Office online exists[0]. However, I believe EtherCalc[1] is faster.

[0] https://www.libreoffice.org/download/libreoffice-online/

[1] https://ethercalc.net/

Yes? Most of the web really ought to be shut down. It's just providing negative utility to society.

Alternatively: return to monke.

People are trying to make DOM be a WYSWIG text editor. You're point is dead on.

The response is to write an opaque, vendor-specific "DOM". Which is the complete opposite of what HTML was supposed to be. But the browser is now a platform and not a browser, so the metaphors are horribly mixed to the point where I'm not even sure what a DOM is supposed to be anymore.

The DOM was always a WYSIWYG editor – albeit, for HTML, not text. Though, back in the day, HTML was a subset of text with image and table support; none of this fancy `line-height: 1.5em;`…

I wish the web had evolved in a more documenty way.

Hmmm... maybe I should have chosen a different acronym.

What you expected to see isn't alwasy what you got.

WYETSIAWYG

Rendering across browsers and operating systems was a trainwreck until maybe 5 years ago (over a decade of polyfill is finally gone). And even with an ecosystem like ElectronJS + Bootstrap, Win10 MacOS and Linux all look slightly different.

So yes and no to "DOM was always...", but more "No."

That's the entire point. DOM is meant for structured web pages, not web apps. If you want to build complex web apps it is better to use your own renderer..which is exactly what Google is doing with Docs.

We should just port wine to webassembly and be done with it

http://www.boxedwine.org/

The problem is that the escape hatch from document to application is completely broken. The DOM is fine for documents, but it's completely awful for applications. Admittedly, some things on the web that should be documents insist on being applications instead, but many things on the web aren't documents.

For these things, using the DOM is painful. When the pain becomes great enough, the biggest available escape hatch is pure native 2D rendering (canvas), which is a nightmare for accessibility and affordance to end-users. It would be awesome to have something else to escape to.

> 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.

About a decade ago I had the start of a Eureka moment on how to do this (back then — https://medium.com/space-net/spacenet-51aca95d49a2, nowadays https://treenotation.org/). It seems to me we've missed a sort of fundamental universal notation of the universe, which you can think of as "two-dimensional binary". I predict we will soon see a Cambrian Explosion of new formats and languages that are simpler and more interoperable with each other, and some will have the opportunity to build new great languages for rendering stacks.

Wow that tree notation looks super interesting!

Bookmarked for a later in-depth read but my interest is piqued!

How is this not just S-expressions with indentation instead of parentheses? What makes it different from say Sweet Expressions?

Common question. You cannot do column and matrix operations natively against S-Expressions (You need to parse the whole thing). This turns out to be very important and useful. S-Expressions need to be transversed in 1-D linear order.

When you two-dimensionalize S-Expressions and remove the parens, you get Tree Notation.

Hey, nice! I have a notes file experimenting with a similar tree-style minimalist data notation; it's definitely an area that needs more exploration.

I like what you've done with it, I'll need to take a closer look.

While I was thinking about it, I also decided to take a look into prior art, which took me all the way back to Landin's "The Next 700 Programming Languages" from 1966 which introduced the hypothetical language ISWIM, which was the first to introduce indentation based syntax and inspired the ML and Haskell family of languages (https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf)

It wasn't exactly what I was looking for, but it's fascinating to see how long we've been thinking about these kinds of issues.

Yes, and surprisingly there are not too many that use any indentation based syntax (about 1 in 50). However, of the ones that do (abc, aldor, boo, buddyscript, cobra, coffeescript, csl, curry, elixir, f-sharp, genie, haml, haskell, inform, iswim, literate-coffeescript, livescript, madcap-vi, madcap, makefile, markdown, miranda, nemerle, net-format, nim, occam, org, promal, python, restructuredtext, sass, scss, spin, stylus, xl-programming-language, yaml) there are some real gems.

Some more interesting read's in this space:

2003 - Egil Möller's I-expressions - https://srfi.schemers.org/srfi-49/srfi-49.html

1984 - Alan Kay's 3-D spreadsheet - http://worrydream.com/refs/Kay%20-%20Computer%20Software%20-...

1972 - Mark Wells' A Review of Two-Dimensional Programming Languages - http://sci-hub.cc/10.1145/942576.807009

Cool! Thanks for some more reading and inspiration.

Here's what I have in my notes buffer; I hadn't gotten much further than this.

  Ssn: /([0-9]{9})|([0-9]{3})-([0-9]{2})-([0-9]{4})/\1\2\3/
  People: Table
      first: String
      last: String
      dob: Date
      ssn: SSN

  Csv
      headings: True
      load people.csv
          as: People
      select first last dob
      filter dob.age > 21

Well, I had some discussion, alternate forms of the syntax, links to prior art, etc, but not much else worth sharing.

Will have to add your TreeNotation and Ohayo to that list, as well as these other links you've shared.

Very nice! The nice thing about these kinds of notations is that they last. Simplicity is timeless. I can immediately grok exactly what you are doing here. :)

Do you have a more formal documentation for treenotation? The idea is intriguing but I couldn’t find the actual rules specified on the site.

The rules for the basic notation are really simple. It's just basically a grid (visualize a spreadsheet), where each line is a row and each word is a cell. Indent a line to indicate a child node/row.

An updated spec: https://faq.treenotation.org/spec/

Thanks - that’s what I was looking for! Looks like a potential improvement on s-expressions to me in terms of a readable syntactic kernel.

For what it’s worth, I have been interested in the concept of 2d languages for quite some time, and I’m not sure what your definition is.

To me this seems to have a 1d topology - I.e. it’s still left to right top to bottom, and there are no loops or semantics that require reading in other directions.

I contrast this with something like a circuit diagram or labview program.

I may be missing something though.

This is a dark pattern. Webassembly is binaries with no source. There is nothing to deny that. It closes the web and it isn't free software. It is moving back to proprietary. For reasons that all the googlers or other webasm devs here can't admit.

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.

> 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 ;-)

This would be more funny if it was less prescient.

> 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.

> 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-inte...

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

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.

To me this is like saying that because we are no longer able to make good bicycles people should walk everywhere.

Shouldn’t software serve people rather than the other way around?

This comes across as a ‘you’re holding it wrong’ type argument.

> 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.

You assume the developers of Google Docs are the developers of Chrome and WHATWG

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.

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.

Reply on news.ycombinator.com