Manually lint, and fix typos and grammar, in index.html

[TallTed]

• Does something about (incompletely) normalizing line breaks to ease editing (If there's a linter that's going to be run "someday", setting a base would be better sooner than later)
• Fixes some typos
• Fixes some grammar and punctuation

---

Preview | Diff

[afs]

Yes, to would be good to reformat.

We can try running it through HTML tidy. It needs experimentation and preparation. (Some <pre> get broken, and links are crudely split across lines. But links are all going to change anyway.)

[afs]

Next time, could you separate reformatting from content change please? It is hard to review when they are mixed.

(One way would be separate commits with indicative commit messages).

If the PR title could say what sort of updates are included, that would be helpful because it shows in people list of noitifcations.

[TallTed]

[@afs] Next time, could you separate reformatting from content change please? It is hard to review when they are mixed.

(One way would be separate commits with indicative commit messages).

Yes, sorry, I hate when others do as I did... I didn't plan to do the line-breaks, but they made it easier to do the other fixes.

[@afs] If the PR title could say what sort of updates are included, that would be helpful because it shows in people list of notifications.

Updated. Hopefully satisfactorily.

[pchampin]

could this be tagged as spec:editorial?

[TallTed]

I've merged the outstanding changes to this PR. I think it's ready to merge to the main branch.

[afs]

If there's a linter

That's the idea. We need to get down to zero PRs across the SPARQL docs then run html tidy.

htmltidy is not an ideal linter/formatter - are there better ones?

htmltidy does wrap lines, through puts breaks inside e.,g. <a href. It may damage <pre> blocks; script inserted CDATA may help.

[TallTed]

I don't know why htmltidy would mess with <pre> blocks which are supposed to retain their whitespace formatting when browser-rendered... I can't imagine any need or reason to wrap such lines differently. But if it does, then obviously, some special post-linter-processing care will need to be taken.

Linebreaks and other whitespace insertions within <a ...> are not harmful, so far as I've seen anywhere. They may break from some humans' preference of source indents, etc., but that's just another reason to lint sooner (as editors' preferences can be made clearer, sooner, by what linter changes they leave in place).

Generally and historically, I've found it easier to work with pre-linted docs. I'm gathering you prefer otherwise. That may mean my autopilot makes more inline changes along the way, which is unfortunately likely to frustrate us both ... but I'll do my best to minimize that.

[afs]

@TallTed -

I ran htmltidy on every single SPARQL document just to get the spec/index we are working on. I repaired the many HTML problems. The docs are now already lightly linted. It is still hard to edit the structure.

reason to lint sooner

That's the idea. We need to merge open PRs to do that.

[afs]

Added the editors as reviewers.

[afs]

I didn't see a way to fix the conflicts on this PR so I've tried to fix up the conflicts with https://github.com/w3c/sparql-results-csv-tsv/pull/19. This the @TallTed's branch, rebased with current main, and then fixed up.

Please check.

[TallTed]

@afs — I'm not sure what conflicts you're speaking of... I see "This branch has no conflicts with the base branch" here.

[afs]

Prior to your latest commits, the "rebase and merge" was not green and the statement above it was about conflicts. The "resolve conflicts" link did show conflicts but they were not easy/possible to fix up in the GH interface.

The 4 commits all now have recent dates so that seems to have cleared up up, which is good.