dansalvato

I was a teenager at the time and would watch all of Apple's keynotes. I remember them making a big deal for a while about H.264 support. It's very cool to get a glimpse of the context where engineers like yourself were likely proud of your work, and I'm glad that it was shown through the way that Apple talked about it.

I had always thought that table sorting seems like the perfect job for HTML, given its data-driven nature, and the possibility of implementing sort information into the attributes of table cell elements.

But thinking about it: Is there a precedent for HTML to be able to include information that instructs the device to present the DOM out of order? Maybe it's out of scope for HTML to have information about presentation order, when the order is supposed to be implied strictly by the DOM hierarchy itself.

Of course, CSS can visually reorder stuff (e.g. `order` on flex/grid items), but MDN has accessibility warnings regarding the use of `order` and visually presenting the data in an order not reflected by the DOM. So, maybe sorting is best done by reordering the DOM after all.

Wow, what a delightful surprise! I'm a huge NetHack fan and have been waiting a long time for the official 3.7 release before switching over to it. I've been a 3.6 holdout, haha.

AFAIK, the backend has moved a lot of map generation logic (and exposure of other data) to a Lua API, which is quite exciting as something for people to play with in tooling, forks, mods, etc.

Minor spoilers below:

I heard about some great balance adjustments that help to mitigate over-reliance on a single kit, such as making certain extrinsic resistances (e.g. wearing rings) stronger than their intrinsic counterparts, which adds to the decision-making in choosing what to equip. Another change I'm really excited for is the unicorn horn no longer being usable for "restore ability", so ability-draining effects (of which there are many) are a more significant threat (they were effectively zero threat until now).

Also very cool to hear the quest is now possible to do early (despite being a Bad Idea) as that has great implications for speedrunning or "fewest turns" runs.

Can't wait to dive in!

I wrote that L-cancel training code! Funny to see it come up out of nowhere. I too have always adored the Wii and its moddability. It'd be my go-to choice if I someday ever get the itch to write console homebrew software of my own.

I see CarPlay (and CarPlay Ultra) as being for auto makers who don't want to put in all the effort to design and drive a good proprietary UI (CarPlay is a godsend in cars with crappy UI, i.e. most of them).

Rivian is a luxury vehicle brand with a first-class UI/UX. I imagine going with their own first-class UI and CarPlay Ultra would be a mess; two separate interfaces for the same controls, but laid out differently. Makes a lot more sense they'd be working with Apple to integrate more Apple features into their own UI, rather than having to maintain two separate first-class UIs that are bound to have discrepancies.

And there's the more obvious answer that they want the entire driving experience to feel like a Rivian experience, given how important that's been for luxury EVs on the software side. Supporting a canned OS would make the vehicle "feel" the same as every other car that also supports it.

From the last interview question in the article (pertaining to Arm):

> We don’t really try to steer the market one direction or another; we just want to make sure that good options are always supported.

Sounds like their priority is to support Steam on the hardware consumers are currently using. Given that, it makes sense they'd go Arm in the Steam Frame, because Fex alone is already a massive undertaking, and Snapdragon is a leading mobile chipset for performance and power efficiency.

I can't believe these "smooth scrolling" scripts are still a thing. I was wondering why I was having a hard time scrolling the page on my phone, when I got to my PC and felt the reason.

It's incredible to think how many employees of this world-leading Web technology company must have visited this site before launch, yet felt nothing wrong with its basic behavior.

This article inspired me to check if Google has something similar for Google Workspace, which also just increased its price due to a bunch of Gemini integration I have absolutely no need for.

As it turns out, they do—but it's hidden from the "Plans and Upgrade" page, which only shows the Standard plan and above. After some digging, I finally found an inconspicuous dropdown on my plan's billing page that had an option to downgrade my plan. Upon clicking it, I was taken back to the earlier "Plans and Upgrade" page, but this time, the Starter plan was made visible on the page.

It's exactly half the price of the Standard plan, just with less storage, no Gemini, and some restrictions on other enterprise features I've never even heard of. Pretty bizarre and upsetting that they completely hide the existence of the Starter plan like that.

I'm hoping I can eventually bring my reliance on Google services down to zero, whenever I can afford the effort it takes to migrate to something better.

The CRT effect is immediately what stood out to me as well. It's the first time I've ever looked at a "CRT filter" that really gave my eyes the sensation of looking at a real CRT, specifically Amiga. It's so good that I would compel the author to share it with Amiga emulator developers to see if there's any chance of it being implemented. Maybe except for the line that occasionally travels from bottom to top, that's more reminiscent to me of a camera artifact and not something I experience with my eyes on Amiga monitors.

Let's be real, Commodore has no one to blame but themselves for squandering their 5-year lead in hardware and OS. They were carried hard by the passion of their engineers, but irredeemably greedy and soulless at the top. At Microsoft and Apple, engineers were the lifeblood from the very beginning. At Commodore, they were a spreadsheet column.

I think some of this stuff isn't the responsibility of HTML. If HTML already has a full autocomplete spec, isn't it the fault of browsers/extensions/OS if the implementation is broken? Or are you saying the spec is too ambiguous?

A lot of stuff becomes redundant under the framing that HTML is designed to provide semantics, not a user interface. How is a toggle button different from a checkbox? How are tabs different from <details>, where you can give multiple <details> tags the same name to ensure only one can be expanded at a time?

Image manipulation is totally out of scope for HTML. <input type="file"> has an attribute to limit the available choices by MIME type. Should there be special attributes for the "image" MIME type to enforce a specific resolution/aspect ratio? Can we expect every user agent to help you resize/crop to the restrictions? Surely, some of them will simply forbid the user from selecting the file. So of course, devs would favor the better user experience of accepting any image, and then providing a crop tool after the fact.

Data grid does seem like a weak spot for HTML, because there are no attributes to tell the user agent if a <table> should be possible to sort, filter, paginate, etc. It's definitely feasible for a user agent to support those operations without having to modify the DOM. (And yes, I think those attributes are the job of HTML, because not every table makes sense to sort/filter, such as tables where the context of the data is dependent on it being displayed in order.)

Generalized rant below:

Yes, there are pain points based on the user interfaces people want to build. But if we remember that a) HTML is a semantic language, not a UI language; and b) not every user agent is a visual Web browser with point-and-click controls, then the solution to some of these headaches becomes a lot less obvious. HTML is not built for the common denominator of UI; it's built to make the Web possible to navigate with nothing but a screen reader, a next/previous button, and a select/confirm button. If the baseline spec for the Web deviates from that goal, then we no longer have a Web that's as free and open as we like to think it is.

That may be incredibly obvious to the many Web devs (who are much more qualified than me) reading this, but it's not something any end user understands, unless they're forced to understand it through their use of assistive technology. But how about aspiring Web devs? Do they learn these important principles when looking up React tutorials to build some application? Probably not—they're going to hate "dealing with" HTML because it's not streamlined for their specific purpose. I'm not saying the commenter I'm replying to is part of that group (again, they're probably way more experienced than me), but it reminded me that I want to make these points to those who aren't educated on the subject matter.

> There's also BTST #0,xx but it wastefully needs an extra 16 bits say which bit to test (even though the bit can only be from 0-31)

That reminds me, it's theoretically fastest to do `and d1,d0` e.g. in a loop if d1 is pre-loaded with the value (4 cycles and 1 read). `btst d1,d0` is 6 cycles and 1 read.

> the blitter is active and you set BLTPRI

I thought BLTPRI enabled meant the blitter takes every even DMA cycle it needs, and when disabled it gives the CPU 1 in every 4 even DMA cycles. But yes, I'm splitting hairs a bit when it comes to DMA performance because I code game/demo stuff targeting stock A500, meaning one of those cases (blitter running or 5+ bitplanes enabled) is very likely to be true.