This does not sort the checkboxes in the order they're found in the search. This can be added, but I figured I'd make the minimal changes to address the issue.

The last test does not pass BTW, but it doesn't pass on the current PubMed Central.js either -- complains that doc is null but scaffold does not give line numbers.

@dstillman could you clarify what you preference on merging multi-commit PRs is?

Github does have, of course, the option to just squash on merge via GUI. Should I generally do this, or is the preferences to have the submitter squash into sensible commits (e.g. one for the code fix, one for the linting-related fixes), or something else?

The last test does not pass BTW, but it doesn't pass on the current PubMed Central.js either -- complains that doc is null but scaffold does not give line numbers.

Yes, I think all tests on PDF pages currently fail. Not sure if that's fixable in the test-suite? Import into Zotero works fine.

@dstillman previously explicitly requested the lint-fix commit and the functionality commit be kept separate when submitting a PR.

Absolutely, I want them separate for review, too. But it makes things easier to squash everything into one commit from the online GUI when merging.

Yes, I do think it's a good idea to keep lint commits separate post-merge — that way if we have to review the commit history later we can focus on what actually changed.

For most multi-commit PRs, squashing is fine, since there's no need to keep a permanent history of every tweak that was made in response to feedback while the PR was under review. But for things that will have meaning later, I think it's worth asking the submitter to rebase at the end into logical commits. (And as shown above, git commit --fixup also makes it easy to push reviewable changes that can be automatically squashed later. I suspect GitHub's PR rebase function doesn't use autosquash, but that'd make things even easier.)