Full Width [alt+shift+f] Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]
39

Smoothly scroll to an element without a jQuery plugin

from A Beautiful Site [alt+shift+b] in programming

You know that special effect where you click on a link and your browser smoothly scrolls down to the appropriate section of the page? Pretty slick, right? Here are a couple snippets so you can do the same thing on your own website. Scroll to a specific element # Here's how to programmatically scroll to any element on the page. If you're using jQuery, you don't need a plugin. It's very simple: $('html, body').animate({ scrollTop: $("#target-element").offset().top }, 1000); This will scroll the page down to #target-element over a period of one second (1,000 milliseconds = 1 second). Scroll to the selected anchor # You can take things a bit further and animate scrolling for all anchors on your page. The following snippet will watch for clicks on any link that points to an anchor and smoothly scroll down to it: $('a[href^="#"]').on('click', function(event) { var target = $(this.getAttribute('href')); if (target.length) { event.preventDefault(); $('html, body').stop().animate({ scrollTop: target.offset().top }, 1000); } }); See it in action # See the Pen cybdG by Cory LaViska (@claviska) on CodePen.
22nd Jan 2010

Stay updated

Get a weekly newsletter with the top 5 articles worth reading every week.

More from A Beautiful Site

Most Software Was Already Slop

As software engineers, we take pride in hand-written code and knowing how everything we build works in detail. While there are many developers out there who build good software, there are many, many more who don’t. Yet we balk at the idea of vibe coding, even when it yields decent results. You don’t need a scientific study to realize the mean quality of human-authored software leaned towards slop even before AI was around. How many times have you been frustrated by an app or website that just didn’t work right? (This is especially true for software produced by big companies.) The quality of software humans can build is absolutely incredible. But the quality of software humans actually do build is usually not. So no, AI can’t build perfect software. Maybe that will improve in the future, or maybe it will remain just as messy as the human-authored code LLMs have been trained on. I don’t think any of that matters, because if AI can build software that’s at least as good as the mediocre code that came before it, that will be acceptable for most industries. Customers don’t care about the craft, they care about the result. And if the result is faster, cheaper, and good enough…well, that’s a better combination than anything they’ve ever had before. Why wouldn't they choose it?

4th Sep 2026 • 2 votes
I'm pulling ColorCopy from the macOS App Store

I launched ColorCopy on May 18. It was my second macOS app, but the first one I launched on the Mac App Store. Today, I decided to pull it. The app isn't a new idea, but it bakes four color tools into a single menu bar app: an eyedropper, a color picker, a palette manager, and a contrast checker, each one a hotkey away. I made it available for free, with a one-time in-app purchase to unlock unlimited use. No subscription, no recurring fees. It's simple, stable software with the lowest possible barrier to entry…exactly the kind of utility the App Store seems made for. I wasn't sure what to expect, so I ran an experiment to answer some questions: Is there any real benefit to having your Mac app on the App Store? Is the Apple tax worth it? Will customers just come flooding in? For ColorCopy's release, I did zero marketing. No Product Hunt launch. No Hacker News post. The only things I published were this blog post and a tweet. If the App Store delivers on its promise of discoverability, that should be enough to see some kind of traffic…right? You be the judge. In nearly three months on the App Store, ColorCopy got a little over 1,000 impressions, 149 product page views, 85 first-time downloads, three in-app purchases, and $21 in proceeds. Not per day. In total. Broken down over 81 days, that averages out to: 13 impressions per day 1.8 product page views per day 1 download per day 0.04 in-app purchases per day (about one per month) $0.26 in proceeds per day Extrapolated to 12 months, ColorCopy would have earned about $95…not even enough to cover Apple's $99 annual developer fee. If discoverability isn't a part of the App Store deal, what exactly is the benefit? Why limit your Mac app to the sandbox?* Why spend hours in App Store Connect filling out metadata, screenshots, and localization information? Why wait an arbitrary number of days for someone to review your app with the consistency of a coin flip? It doesn't seem worth it for Mac developers. Adios, App Store 👋 As of today, ColorCopy is self-distributed and sold through Polar (the new Stripe, which I highly recommend). This is the same way I sell TongueType, which makes pretty much everything easier on my end: one dashboard, real customer relationships, no finicky review process, and updates ship the moment they're ready. The move required swapping out in-app purchases from StoreKit to Polar, and updates now ship through Sparkle instead of the App Store's built-in update mechanism. Both are tried and true solutions for self-distributed Mac apps. To be fair, you can't really do this on iOS. Most users aren't jailbroken…walled garden and all. But on Mac, where self-distribution is still a first-class option, there seems to be zero incentive to be in the App Store, especially if you're counting on discoverability. In three months, the App Store sent me barely a trickle of customers. Had I marketed the app myself, the traffic would have flowed the other way. I would've been sending my customers to Apple and paying a tax for the privilege.** Self-distribution gives me the freedom and control over my apps that the App Store's sandbox never will. If it's on me to drum up all of my own traffic, I'm going to send it to my own website. *I originally used a third-party library for the eye dropper because NSColorSampler is meh, but the sandbox forbids it so I was forced to remove it. Yes, I had to make my app shittier in order to put it on the App Store. **I fully acknowledge this may not be the case for every app, but it was my experience and worth sharing. Your mileage may vary. Aside: ColorCopy was available in 10 languages on the App Store. For some reason, the listing always showed FR as its primary language (it wasn't). The app is available in many languages, including English.

7th Aug 2026 • 1 votes
I Mostly Stopped Typing

I built the dictation app I wanted. It's called TongueType, and my daughter did the voice over for the video. (Family business.) It hasn't gotten much traction yet, and I think I know why: dictation has been bad for so long that most people stopped paying attention. I don't blame them. But I don't think most people realize how good local models have gotten. The thing that was flaky and frustrating five years ago is genuinely good now, and it runs entirely on your Mac. Downloads are low. But the conversion rate is great. The people who actually try it tend to stick around, which tells me the problem isn't the app, it's getting someone to give dictation one more honest chance. The real hurdle is the habit The hard part isn't accuracy. It's that talking instead of typing is a new habit, and new habits are awkward before they're automatic. For the first week it feels strange. You catch yourself reaching for the keyboard out of muscle memory. Then one day it clicks, and you realize how slow typing was making you for certain things. I still write code by hand. That's thinking, not transcribing, and I want my fingers on it (plus saying HTML tags and attributes out loud seems counterintuitive 😂). But for almost everything else, I talk. I prompt LLMs I send emails I reply on Slack I write commit messages I do most other text with my voice The common thread is that the thinking is already done and the only thing left is getting the words out. That turns out to be a surprising amount of my day. My desk setup On the go, the MacBook's built-in mic works just fine. You don't need fancy hardware to get good results. But when I'm at my desk, my laptop is docked, so I pair TongueType with a Tula mic. It's small, portable, sounds great, and looks the part! (Kuru Toga mechanical pencil positioned for size comparison.) One tip: use a wired mic if you can. Bluetooth adds latency, and latency is the enemy of a tool you reach for dozens of times a day. A wired connection makes the whole thing feel instant. Honest caveat: it's probably not a great look in a co-working space. 😂 "Why is this better than macOS dictation?" More accurate. Less flaky. More customizable. More fun. I could list the features, but the honest answer is the same one I'd give for most things: just try it and you'll feel the difference immediately. It's free to start. What's your experience been with dictation? If you wrote it off years ago, I'd genuinely love for you to give TongueType a shot and tell me what you think.

25th Jun 2026 • 1 votes
Introducing TongueType

I just launched my first macOS app called TongueType. It's voice dictation that runs entirely on your Mac. Hold a key, speak, release, and your words appear wherever your cursor happens to be. I build small, simple, stable software. TongueType fits that description, and it scratches an itch I've had for a while. Why I made it I type fast, but I often think faster than I type. When an idea is fully formed in my head, the bottleneck is my fingers. macOS has had built-in dictation forever, but I never liked relying on it. Accuracy aside, I didn't love the idea of my voice taking a trip to a server and back just to write a sentence. There are many dictation apps in the wild, but I want one that's privacy focused, doesn't send data to the cloud, doesn't charge a monthly subscription, and gets out of the way. TongueType uses OpenAI's Whisper model running locally on Apple Silicon. Nothing is uploaded. Nothing is logged. There's no account to create. Zero telemetry. Your voice never leaves your Mac. How it works The whole interaction is one key. By default it's the Right Option key, because it's sitting right there and your thumb isn't doing anything important. Hold it, talk, let go. The transcribed text is inserted at your cursor…in your editor, your email, a chat box, a search field, anywhere text goes. You can also drop in an audio or video file — WAV, MP3, MP4, MOV — and get a transcript back. Handy for meeting recordings and voice memos. A few things I sweated the details on: A grace period so a quick accidental tap doesn't start recording. Double-tap to latch for when you want to keep talking without holding the key down. Cancel phrases — say "scratch that" at the end and the whole thing gets discarded. You will use this more than you expect. Spoken symbols — say "new line" or "question mark" and you get the symbol, not the words. Post-processing — for common terms that seldom get dictated properly. TongueType speaks twelve languages and includes automatic detection, so you don't have to tell it which one you're using. How I actually use it Building the app was one thing. Using it every day turned out to be another. A couple months in, it's quietly worked its way into most of what I do at the keyboard: Prompting LLMs. Talking to an AI assistant is conversational by nature, and typing out a long, detailed prompt is tedious. Speaking it isn't. I get more context into a prompt because I'm not rationing my words to save my fingers. Email. Replies that used to sit in my drafts now get spoken out in a single pass. I still read them before sending, but the blank-page friction is gone. Code comments and commit messages. The parts of coding that are just writing. It's faster to explain why a change exists out loud than to stop and type it. Direct messages. Quick replies in chat without breaking flow. Hold the key, say it, done. The common thread: TongueType is best wherever the thinking is already done and the only thing left is getting words out. That's a surprising amount of my work day. A fun personality TongueType is minimal and fun. It lives in the menu bar. The recording overlay is small and out of the way, and you can configure its position on screen. There are twenty accent colors including Rainbow Mode. None of these extras were necessary, but all of it was fun to build. Accessibility I want to call this out specifically. Voice dictation isn't only a convenience. For some people it's the difference between using a computer comfortably or not. If typing is painful or difficult for you, TongueType is built to be a genuine alternate input method, not an afterthought. That mattered to me, and it shaped a lot of the decisions above. Pricing TongueType is free to try, and the free tier includes every feature. You get 30 minutes of live dictation each month and short file transcriptions. If you want unlimited, TongueType Pro is a one-time $19.99 purchase that covers up to five Macs and unlocks unlimited dictation and full-length file transcription. No subscription. Buy it once, keep it forever. Requirements TongueType needs macOS 14 or later on an Apple Silicon Mac (M1 or newer). The local model is the whole point, and that's what makes it run so well. If any of this sounds useful, give it a try at TongueType.app. It's free to start, and I'd genuinely like to hear what you think.

14th May 2026 • 1 votes
My Stance on AI in Software Development

I believe artificial intelligence is a powerful and valuable tool that can significantly improve how we create, solve problems, and bring ideas to life. I didn't always feel this way.. But these days, I use AI regularly in my work and I expect that to continue. We may not have chosen this reality, but it's the reality we're in. The tools and their benefits — costs be damned — can no longer be ignored. That said, when people ask "was this made with AI?" the honest answer is rarely simple. AI can speed up many parts of the process, but it doesn’t replace human judgment, creativity, or responsibility. What appears effortless on the surface rests on deliberate human direction, critical thinking, and careful review. Getting good results from AI requires active guidance and oversight. The nuances of context, ethics, user needs, and real-world application are simply too varied given the current technology. Moreover, AI doesn’t generate meaningful ideas or elegant solutions on its own. Strong human vision, architecture, and decision-making are still essential. There is no prompt, model, or service that can deliver finished, trustworthy work without substantial human input. My commitment to you is this: everything I create will be driven by human ideas, architecture, verification, and final review. I will use AI as an assistant to do what I would have done anyway, but more efficiently. I will not let AI replace my intelligence, but I will use it to turn my intelligence into code faster. — Cory LaViska

20th Apr 2026 • 1 votes

More in programming

AO3 hacked, down

Internet's premier fan fiction site got hacked, is offline for a couple of weeks while they figure it out

38 minutes ago • 1 votes
Auzoux' anatomical models

19th century anatomist made creepy paper mache models of human figures

52 minutes ago • 1 votes
Museum of Natural History of Venice

Photos of a bizarre collection of natural history objects, some fantastical

58 minutes ago • 1 votes
Factorio compiler

Factorio's 2.1 decider combinators are full state machines, so someone wrote a compiler for a C-like language to the game.

an hour ago • 1 votes
Self-reinforcing quality / adopting verification pattern

After implementing the small-change pattern, Imprint Engineering’s next focus in improving our development loop has been implementing a verification loop for our software development. This is an increasingly common pattern, particularly popularized by poteto’s pstack, but you’ll find similar ideas emerging in other places as well, e.g. Niko Matsakis’ post on the correctness ratchet, among others. This captures some of the confusion I’ve seen in our initial rollout, and the particulars of how we are implementing the approach. What verification pattern is, and what it isn’t The verification pattern suffers from confusing naming: when you tell a team that you’re planning to roll it out, they’ll often ask you what mechanism you’re using to verify the codebase, don’t we already have tests, linters and so on? However, the verification pattern itself is more similar to the chain-of-thought pattern, which aims to steer the harness towards your desired outcome in a clear way. For example, we require that each pull request generate a verifications/{pr_num}.md file that describes each step the harness took to verify the changes, and also what it was unable to verify. You can argue that your harness was already performing these steps, but it’s actually hard to say whether it was or wasn’t. My sense is that it often wasn’t happening: I’ve seen too many pull requests go to CICD that had failed basic lints that could have been run locally to believe the harness was always running them. Now the harness has to explicitly document that it’s done those steps, or acknowledge it hasn’t. This allows the harness to self-drive more effectively. Equally importantly, this generates a renewing source of data about where your harness is struggling to verify its work. That list is your roadmap for improving the ability of your harness to self-drive work more reliably over time. Our verification loop The core of our verification loop is five steps: Implement something that you’ve identified or that has been identified by an automated system to resolve. Let’s say addressing a new error that’s shown up in the logs. Create a pull request containing that work after your harness has verified it locally. Pull requests cannot be moved from draft to ready until they have a verifications/{pr}.md verification file available Provide feedback on the pull request, at minimum from our ai-code-review tool that automatically reviews all pull requests, but potentially also from humans Incorporate and reject feedback on the pull request. For low quality feedback, we explicitly dismiss it using a /dismiss {reason} syntax in the pull request comment responses Maintain our systems on a daily basis by pulling in the above steps to improve our software: Use pstack’s /maintain-verification-skill skill to update the feature maps and tools used based on what has changed and where verifications have run into issues. Automatically generate a pull request with these changes for review Review all verification files to identify where they struggled to verify, and generate issues for review that would reduce those gaps Review which feedback from ai-code-review was incorporated and which was rejected, tightening up its guidance This is working pretty well for us so far, typically each of our major code areas (frontend, backend, data, and native) wakes up with 4-6 pull requests to review as output of this process, improving our codebase’s correctness while we sleep. feedback tool The above feedback loop still misses meta-issues in our CICD and testing patterns. To address that, we’ve implemented the feedback tool pattern described by Teddy Riker in Designing for Agents, which has worked very well for us with respect to addressing places where CICD and harnesses themselves are failing above the level of verifying a specific pull request. feedback and verifications are complementary, not competing, techniques. For example, if the container’s runner crashed before completing, the feedback tool would often report on this issue, whereas the verification file wouldn’t even get generated. Explore (raise ceiling) vs exploit (raise floor) One of the fundamental tradeoffs in how organizations approach AI adoption comes down to an explore vs exploit tradeoff. When you explore by having the full team do its own thing, you explore for ideas which can raise the ceiling, but when you centralize you raise the floor by ensuring everyone gets better PR review and better tooling. The other related–and extremely open–question is whether exploration tends to over-optimize for the particulars of a given individual or team’s preferences, which often reduces cohesion across a codebase. At this point, I think of misaligned guidance as “context poison”, and am pushing hard to eliminate duplicate guidance on any topic, to ensure we have consistent, cohesive direction. So far, our approach is running this as a centralized process for our repositories, building a single, continually improving, corpus for each area using the self-reinforcing loop built around the verification pattern. I think it’s working well for us, although certainly I’ll admit that there’s some skepticism about how far we go towards centralizing, and I think that skepticism is warranted: we do want to continue exploring, even if we are primarily exploiting. The best techniques for AI-enhanced development in 2027 will be ideas that are mostly unknown today.

4 hours ago • 1 votes
📚 BoredReading

You seem to be enjoying this.

Join free to unlock everything.

Create free account

Already have an account? Sign in