SVG supports SMIL animation — no JavaScript or CSS

SVG can use SMIL animation elements such as <animate> and <set> to create declarative animation/interactivity. This allows you to dynamically change attributes like position, opacity, fill and CSS class. These features seem very widely used, but would be handy for a self-contained diagram, for example a tabbed interface based on opacity.

The following demo uses the <set> element to change fill colours base on click and mouseover events, showing that events can target other elements by id.

<svg width="415" height="100" xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<rect fill="#ff660099" x="0" y="0" width="200" height="100">
    <set attributeName="fill" to="#ff009999" begin="click" dur="1s" />
    <set attributeName="opacity" to="0.1" begin="rect2.mouseover" dur="1s" />
</rect>
<text x="20" y="55" fill="#333">Click/tap to change colour</text>
<rect id="rect2" fill="#ff660099" x="215" y="0" width="200" height="100">
</rect>
<text x="225" y="55" fill="#333">Hover targets other rectangle</text>
</svg>

Inkscape can also edit such SVGs without destroying overwriting the animation elements.

GitHub commit squashing — no need to rebase

I still occasionally get well-meaning advice from GitHub bystanders to rebase and squash my commits in pull requests. Ignore those folks — it's not necessary. Way back in 2016, GitHub introduced a pull request squash feature to give maintainers the discretion to squash a contribution into a single commit. Besides, overly-enthusiastic rebasing can cause problems for others following along with your work.

Pelican maintainer Justin Mayer wrote this in response to a piece of such advice:

(Bystander) As a general note, I would expect all the commits to be squashed into a single one, the upstream doesn't need your development history I think.

(Meyer) I'm not sure I agree. When formulated with thought and care, multiple commits can indeed be quite useful. Also, during feedback-and-change iterations, it can be useful to see what has changed in a PR over time, in which case cleaning up the commits can be done at the very end, right before merging.

(Me) I don't use GitHub a lot for collaboration myself, but I believe there's been a "merge and squash" button available to maintainers for a few years now for use at their discretion.

(Meyer) That is correct. If the commits aren't valuable on their own (e.g., if there are "fix-up" commits that add no value as separate commits), the maintainer can squash the commits if the contributor hasn't already done said clean-up.

GitLab, which I use a lot more day-to-day, has had a similar feature available for many years too. I don't use it regularly as I prefer to retain the full development history.

Reordering commits during git rebase

Reordering git commits during a git rebase --interactive is as simple as reordering the lines of text in the commit list that pops up in your editor. Although I tend not to rebase aggressively, this reordering is handy to group related changes together for easier review.