We went out and used our editor against our and customer's documents. The Open part of OOXML makes as much sense as the Open in OpenAI. Microsoft made OOXML available to fend off an antitrust lawsuit, there is no incentive for them to make it actually easy to build competing editors off their specification.
FWIW the bug I found is that your comment parser assumes the w:date attribute represents a useful timestamp of when comments are made. It does not - a bug in Word causes it to save it as ISO8601 local time but _without timezone_, rendering it useless if more than one user across different timezone edits the document. Instead, you need to cross reference the comment with a newer comment part and find a dateUtc attribute. The above is, of course, completely undocumented.
Ah these poor fools. Having built this exact product (OOXML compatible editor in React) before, it took all of two minutes to find a bug. The issue is that the OOXML spec is not in fact definitive - Word is, and trying to implement it from the spec will produce something that works maybe 80% of the time then fall over completely when you hit one of hundreds of minor, undocumented edge cases. Assuming of course that CC did not just hallucinate something. And then there's the more fundamental problem that HTML/CSS has unresolvable incompatibilities with OOXML. This is why Google Docs for instance use canvas for rendering.
Another fun fact - lodash/fp doesn't deduplicate with lodash when bundled. For a couple of months I was wondering why our app had bundled two copies of lodash. I dismissed it as a measurement artifact at first. It took so long to realize there was actually two copies of lodash and it was because one developer on our team had a preference for fp syntax.
It's not random, setting the query string to a new value on every fetch is a cache busting technique - it's trying to prevent the browser from caching the page, presumably to increase bandwidth usage.
Pretty sure that blog is hosted on Wordpress.com infrastructure so it's not like the blog owner would even notice unless it generates so much traffic that WP itself notices.
That said I don't think there's many non-malicious explanation for this, I would suggest writing to HN and see about blocking submissions from the domain [email protected]
Yeah, supporting iOS 12 in 2025 is odd. I was investigating browser support levels just recently for a library and also settled on iOS 16 as a reasonable level.
For reference, iOS 12.x and below are used 0.33% globally https://browsersl.ist/#q=safari+%3C+13+or+ios+%3C+13. Selecting iOS 16 would still exclude less than 1% globally https://browsersl.ist/#q=safari+%3C+16+or+ios+%3C+16. In both cases the vast majority would be older iOS which is unfortunate because I assume they're on older devices with no upgrade path, but you have to decide on the transpile/polyfill cutoff at some point and browser support has an extremely long tail.
For anyone confused by why the text says the performance is improving between each graph but the lines don't seem to show that - the color for each key and the scale changes between graphs.
It's because the website is using cufon, a very early attempt at supporting custom fonts on the web using HTML canvas - basically every word you see is rendered as an image rather than text. The end result does not look good on hi-dpi screens like modern Macbook displays, probably they did not exist back then. The site mentions Google Font has a hosted version of it now and you can look at how it is meant to be rendered https://fonts.google.com/specimen/Averia+Libre
> On September 23, 2025, Grijalva was elected to the U.S. House of Representatives in a special election to succeed her father, defeating Republican nominee Daniel Butierez.
Since the article doesn't mention this, the intended use for this property is to act as a hint to the browser about what characters are supported by the font, and if the page doesn't have those characters then the browser can choose to not download the font. https://developer.mozilla.org/en-US/docs/Web/CSS/%40font-fac...
This also mean you don't technically even need this property to achieve this, you can also recompile a font with limited glyphs, this property just makes it easier to do this with an existing font file, though of course the user would be downloading a lot of unused glyphs.
The news cycle is moving fast enough that shockingly enough this news is already pushed off the frontpage of these news sites, but the article is there if you dig a little.
> The main concern about the numbers is that they are probably a massive undercount. Every hospital in Gaza has been bombed by the IDF, and the healthcare system is barely functioning at all any more. Beyond that, there is rubble everywhere, and nobody knows how many people lie dead underneath it.
Just to back this up - this study published in the Lancet estimates a 41% undercount for deaths up to June 30, 2024.
The new docs are very good, they address common questions most devs have, up to fairly complex cases. The "book" unsurprisingly reads like a expert beginner's take, and there are a decent number of poor or missing explanations and code that's not really best practice. It's also really verbose for things that React's own docs do a better job of explaining.
The other part that's disconcerting is the person who did all this has decided to put his name on the public record in an interview with journalists. After reading through the article I had the feeling this would, in a few years, show up in software / AI ethics courses in university. Is this a form of atonement, whistleblower, or extremely misplaced pride?
FWIW the bug I found is that your comment parser assumes the w:date attribute represents a useful timestamp of when comments are made. It does not - a bug in Word causes it to save it as ISO8601 local time but _without timezone_, rendering it useless if more than one user across different timezone edits the document. Instead, you need to cross reference the comment with a newer comment part and find a dateUtc attribute. The above is, of course, completely undocumented.