https://codeberg.org/lig/todo-md/issues/4

I didn’t create one because I won’t be using the project, but suggested it here for your consideration. :)

Outside of work-in-progress or exploration branches, I don’t commit or merge TODOs. Typically, I consider them merge/land blockers. Because most of the time, they’re never resolved. And in that case, I much prefer documentation and statements; reasoning of why it is the way it is, or opportunities.

Maybe you want to scan for FIXME: too?

What’s the nature of the temporary system?

I would consider; remote/temporary systems are not necessarily mine, or setup is not worth it given my concerns on it; There’s different options to install or configure existing shells, I could take my config with me; if it’s a temporary system maybe it’s based on a template that could be adjusted, or auto-setup scripts could be adjusted

It would depend on how much I use it, how much I miss my setup, or how irritated I get because of missing stuff, and considerations of whether it’s worth it (to me).

I’m someone who adjusts their environment to their needs and wants, moreso than other colleagues I see. Many people seem to simply accept existing environments and (to me) annoyances.

When I remote into servers, it’s not typically where I would use much Nushell functionality. Bash and vim is good enough for those things, with just a little bit of configuration. I don’t plan on installing it on work servers, but have recently thought I may install it on my own server for convenience.

Doesn’t help that it’s a multi-page document…

Persistent domain entity, Proto-persistent domain entity, View model, ,

What the heck… Yeah, I wouldn’t want to use that either. While it may be a formalization, it seems like it would significantly increase complexity and overhead. That can’t be worth it unless it’s a huge enterprise system that has to work with generalized object types across teams or something.

I hadn’t heard of Restful Objects before.

I didn’t quite follow.

They’re using htmx, make errors, and learning something new about using it?

That’s like using any new tech though, right? Or - depending on the devs - happens even with established tech.

I’ve never seen htmx in production. I find it interesting though and want to explore using it. That won’t be at work though. :)

I found the dropping of actions quite surprising as well. I would suspect we could return the links with a disabled attribute? If they should be displayed but not accessible/triggerable.

We could have called them HTTP APIs.

No, it doesn’t mean only humans can interact with it.

The key point [of classical REST] is that responses are self-contained self-describing. Requesting a resource response tells you what actions you can take on it. There is no need for application domain knowledge, implicitly or separately-explicitly shared knowledge.

Some HTTP web apis offer links in their JSON responses for example. Like previous and next page/ref on paging/sectioning/cursor. Or links to other resources. I don’t think I’ve ever seen possible resource actions/operations be included though. Which is what the original REST would demand.

That’s how I understood it anyway.

Their suggestion of using HTML rather than JSON is mainly driven by their htmx approach, which the project and website is about. Throughout this article though, they always leave open which data form is actually used. In your quoted text they say “for example”. In a later example, they show how JSON with hyperlinks could look like. (But then you need knowledge about that generalized meta structure.)

I’ve used it at work. But the manual management/maintenance of a commit list makes it practically infeasible. I’ve use it for bit cleanup commits, but not since. When blaming, the previous revision is just one click away anyway. The maintenance doesn’t seem worth the effort.

I guess a commit message tag and script that generates it automatically could make it viable. But I’ve not found the need to yet.

Installable alternative: https://zealdocs.org/

Given that it is high level, I assume you did not want to include this. I’ll mention it here in a comment either way. Text form in the commit message.

I really like using conventional commit messages and introduced it in my projects. We defined a few types, and more leniently choose optional scopes. It’s very useful for categorizing and skimming through commit lists, and for generating changelogs/release notes. `fix(account): Use correct hasing xy"

Consistent imperative form is important to me too. The commit message examples talks about “Summary of changes”, which has no verb, and so, may mislead to a different undesirable form of summarizing changes. (“Change xy” instead of “changed xy” or “[now] does xy [at runtime]” or “did z”.)

I didn’t fully read it, only skimmed, so excuse me if I missed mentions of the commit message text form. It seems very elaborate otherwise.

My browser has a default font size of 18 set. The site overrides that with a default base font size of 12px, then increases it to 13px for content text. That’s way too small for me on my screen. At least to read it comfortably. Or for people who need more accessible text/font.

each function has its own independent metal toggle switch

one steering wheel to steer left, and one to steer to the right

they want to push a lot of buttons on those controls

LOL

Even with a lot of buttons available, good videogame controls are simple and narrow. Natural combinations add depth without overcomplicating things.

Damn, that’s a long list. Looks like a lot of work to collect and prepare.

I was looking for more of an overview of it and selected them from the headlines:

1. 2014: Completely broken IndexedDB implementation
2. 2015: 100vh (100% viewport height) means a different thing in mobile Safari to everywhere else
3. 2016: <body /> with overflow:hidden CSS is scrollable on iOS
4. 2017: Safari incorrectly blocks localhost as mixed content when accessed from an HTTPS page
5. 2018: OS 11.2.2 broke WebAssembly
6. 2018: Safari 11.1 broke MessageChannels
7. 2019: Audio stops playing when standalone web app is no longer in foreground
8. 2019: PWA in iOS uses old assets after publishing new servicerWorker/assets
9. 2020: Add Fullscreen API to iOS (& display fullscreen)
10. 2021: Safari shipped blob.stream(), crashes with a NULL pointer exception
11. 2021: Appending an element to the shadow DOM in many cases hard crashes the browser process
12. 2021: LocalStorage is broken when a page is open in more than one tab
13. 2021: IndexedDB APIs hangs indefinitely on initial page load
14. 2021: Fetch request streaming is implemented just enough to pass feature detection, but it doesn’t actually work
15. 2021: IndexedDB API information leaks
16. 2023: Notifications API: support for the badge, icon, image and tag options
17. 2024: On-screen keyboard does not show up for installed web apps (PWAs) when focusing a text input of any kind
18. 2008: Focus events for non-input elements behave differently in Safari to every other browser
19. 2012: Using border-image with border-style: none is rendered completely wrong
20. 2014: WebKit doesn’t calculate padding-top/-bottom: n% correctly
21. 2014: Pointer events should allow for device-pixel accuracy
22. 2017: Support for 120Hz requestAnimationFrame
23. 2018: Some Fetch requests incorrectly completely skip the service worker
24. 2020: Safari 14 shipped a broken replaceChildren() method, which caused glitches in Construct.
25. 2020: When leaving current scope of PWA, back button incorrectly reads “Untitled”
26. 2020: Safe-area-inset-bottom still set when keyboard appears
27. 2020: Support for background-attachment: local has suddenly completely disappeared
28. 2021: IntersectionObserver and ResizeObserver fire in incorrect order
29. 2021: Mousemove events fire when modifier keys are pressed, even if the mouse isn’t moved
30. 2021: Scrolling in home screen apps incorrectly latches to document
31. 2022: WebM Opus support is inconsistent in Safari
32. 2022: Installed web app with viewport-fit cover causes overscroll issues, breaks position fixed and -webkit-fill-available
33. 2023: iPadOS: Viewport doesn’t correctly restore after dismissing software keyboard for installed web apps
34. 2023: iPadOS: window loses focus when dismissing the keyboard, breaks Page Lifecycle API
35. 2024: Svh and lvh are incorrect on iOS in third party browsers

let a = ''
for (let x of document.querySelectorAll('h3 a[title]')) a += x.title + "\n"
a

deleted by creator

libsass.so: cannot open shared object file: No such file or directory (LoadError)

You’re missing the SASS library

If Markdown formatting is enough for you, I would look into using a static site generator, like Hugo or Jekyll.

If you want to keep your existing content as static files but same website skeleton and layout instead of copying and editing files you’ll copy one and create the layout template. Then content and new posts and pages can be generated from Markdown files. If you set up CI they won’t need to run Hugo or what you’re using, only push the Markdown files to your Git repository.

Whatever you want to do primarily depends on: Your formatting, styling, functionality, and interfacing needs for the editor, and what you’re willing to use or invest for setup.

Hugo runs from a single binary. The source layout is reasonable. With a single layout the folder structure doesn’t have to be complex.

I’m not very familiar with alternative [Markdown] static site generators.

You’re good to keep your skepticism. If you trust them, the ones creating the tutorial to have vetted to a degree, or that a very popular package like that is vetted to a reasonable degree, you’ll just go ahead with it. (Like most people do without questioning it.)

You’ll need considerable experience and insight to do good, reasonable risk assessment. Without that, you can either trust and hope in others, or skip the ecosystem and look for alternative technologies.

It’s also worth noting that your potential impact is considerable lower if you’re only doing local test and development work, not publishing or publicly serving anything. I’m not personally familiar if or to what degree running arbitrary local commands has been limited in the npm ecosystem by now.

I let them ripe for 10 years so I can then concentrate on older bugs.