← Back to context

Comment by bonesss

8 days ago

> As an experiment

The threshold for caring about experiments is exponentially higher in 2026 thanks to half baked vibe slop.

Non-functioning software and demoware comes fast and cheap, regardless of author.

> we gave Claude Code the OOXML spec

Having used the former a lot and read the latter in detail, uhhh…

Trim down the claims here, clarify the editor subset you plan to be supporting, and map the “last 90%”’s to honestly reflect the product you are pushing.

If “tables” and “images” aren’t there I’m quite skeptical about content controls and other key OOXML constructs being addressed meaningfully. The full OOXML footprint chokes OpenOffice out of procurements, rich OOXML documents choke half-way-there implementations (which was the whole point of the format).

As is pointed out elsewhere in the thread - there are fundamental constraints that have kept Google, Apple, and others from pursuing this route. Relatively simple docs are one thing, but OOXML is full of dragons and parity with Word has eluded more than a few tech giants.

I agree with everything in this comment - FWIW, I was on the standards bodies in my country in 2008/2009 to establish a national standard for word processing documents.

We debated the OOXML spec in as much detail as time allowed, but we still didn't get through the entire behemoth of a thing.

ISTR that Microsoft representatives were also on the same subcommittee, and, but the MS rep was pushing very hard indeed to standardise on OOXML.

Too bad the OOXML format, itself, has MS-proprietary binary blobs built into the specification as part of the format.

ISTR we submitted a recommendation of standardising on ODF.