5·
1 day agothey 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.
- 0 Posts
- 39 Comments
Joined 1 year ago
Cake day: June 11th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
4·1 month agoDamn, 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:
- 2014: Completely broken IndexedDB implementation
- 2015: 100vh (100% viewport height) means a different thing in mobile Safari to everywhere else
- 2016: <body /> with overflow:hidden CSS is scrollable on iOS
- 2017: Safari incorrectly blocks localhost as mixed content when accessed from an HTTPS page
- 2018: OS 11.2.2 broke WebAssembly
- 2018: Safari 11.1 broke MessageChannels
- 2019: Audio stops playing when standalone web app is no longer in foreground
- 2019: PWA in iOS uses old assets after publishing new servicerWorker/assets
- 2020: Add Fullscreen API to iOS (& display fullscreen)
- 2021: Safari shipped blob.stream(), crashes with a NULL pointer exception
- 2021: Appending an element to the shadow DOM in many cases hard crashes the browser process
- 2021: LocalStorage is broken when a page is open in more than one tab
- 2021: IndexedDB APIs hangs indefinitely on initial page load
- 2021: Fetch request streaming is implemented just enough to pass feature detection, but it doesn’t actually work
- 2021: IndexedDB API information leaks
- 2023: Notifications API: support for the badge, icon, image and tag options
- 2024: On-screen keyboard does not show up for installed web apps (PWAs) when focusing a text input of any kind
- 2008: Focus events for non-input elements behave differently in Safari to every other browser
- 2012: Using border-image with border-style: none is rendered completely wrong
- 2014: WebKit doesn’t calculate padding-top/-bottom: n% correctly
- 2014: Pointer events should allow for device-pixel accuracy
- 2017: Support for 120Hz requestAnimationFrame
- 2018: Some Fetch requests incorrectly completely skip the service worker
- 2020: Safari 14 shipped a broken replaceChildren() method, which caused glitches in Construct.
- 2020: When leaving current scope of PWA, back button incorrectly reads “Untitled”
- 2020: Safe-area-inset-bottom still set when keyboard appears
- 2020: Support for background-attachment: local has suddenly completely disappeared
- 2021: IntersectionObserver and ResizeObserver fire in incorrect order
- 2021: Mousemove events fire when modifier keys are pressed, even if the mouse isn’t moved
- 2021: Scrolling in home screen apps incorrectly latches to document
- 2022: WebM Opus support is inconsistent in Safari
- 2022: Installed web app with viewport-fit cover causes overscroll issues, breaks position fixed and -webkit-fill-available
- 2023: iPadOS: Viewport doesn’t correctly restore after dismissing software keyboard for installed web apps
- 2023: iPadOS: window loses focus when dismissing the keyboard, breaks Page Lifecycle API
- 2024: Svh and lvh are incorrect on iOS in third party browsers
DOM query
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.
2·3 months agoThey wrote they’re using
.as placeholder commit messages.I use
ffor such [f]ollowup/[f]ixup commits, andafor [a]dditional code/components/changesets. Both keys are trivial to enter. When cleaning it up after,fcommits are typically squashed into previous ones, andacommits get a description and/or serve as a base for squashing.I can see
.working well as well, but having a more obvious character (with vertical height/substance) seems preferable.
You don’t see the point of making use of shortcuts?
It’s just them with shortcuts, they didn’t see the point of m
😏
How did it change how I think about version control? Not much? The goals are still the same. It only does many things better than previous centralized tools.
When DVCS came up and became popular, I used Git and Bzr.
At work, we used subversion. In one project, we had one SVN repository in our office and the customer had one in their office. A colleage had created a sync util. We regularly synced all history into an external hard drive, drove to the customer, and merged it there. Required a thorough and checklist process, potentially conflict resolution, and changelog generating for the big merge commit. Then drive back to the office, and merge back there.
Of course sometimes you used remote desktop to hotfix changes in their code base. Meaning you’d now have the change in two places as different commits.
Anyway, I’ve never found Git difficult. I used it, learned and understood it, and it’s consistent. I know enough “internals”/technical details to understand and use it well and without confusion.
Quite elaborate but also very interesting read on git and version control history.
I don’t get the title. Why is it “A Git story: Not so fun this time”? What is not so fun time referring to?
If working around it is an option, you could switch from https to ssh protocol.
I think the fundamental difference is that Git is a CLI tool. But that’s not how or where people use and want to use it. So obviously various interfaces are being created. It’s not alternative CLI that are created. It’s UIs and GUI interfaces. For a lack of a [more-than-barebone] official one.
Shells remain CLI. Distros are also technically/technologically driven.
Maybe the better analogy is that with vim and nano, we see many text editors and IDEs with GUIs.
There is no other CLI tool like Git. But
Shell or Bash has various alternative shells.
Vim has numerous plugins and alternatives/extensions.
Linux distributions are wide and varied, forking out.
I’m glad I was able to establish a very mindful and structured approach to Git history in my team and project.
deleted by creator
I’m not sure I understand what issue Linus et al. are trying to solve. If the full hash is used whenever a commit reference is saved somewhere, then why does it matter how core.abbrev is configured?
What are you referring to?
The article is about abbreviated forms, not full hashes. The Linus quote is specifically about abbreviation.
[Linus] He recommends kernel developers use 12 characters
For a large code base you can expect to further grow continuously for a long time, it makes sense to already use more than a minimum abbreviation so that you references remain unique, even if a decades time.
Configuring a wider and explicit abbreviation width that will remain constant is preferable because the displayed references are what you will copy and reference. It doesn’t make sense to work with shorter abbreviations locally, but wider abbreviations when communicating with others. It’d be a hassle to translate and risky to miss doing.
one steering wheel to steer left, and one to steer to the right