Better HTML

[domel]

This PR addresses several HTML structure and semantic issues to improve accessibility, maintainability, and adherence to best practices. The following corrections were implemented:

• Tables used in a non-semantic way: Replaced tables that were previously used solely for layout purposes with CSS styling. This change ensures that tables are used strictly for tabular data, enhancing semantic integrity and improving screen reader compatibility.
• Missing essential HTML elements: Added essential structural elements.
• Redundant HTML tags: Removed any duplicate or unnecessary HTML tags, streamlining the HTML structure. This cleanup reduces code complexity and improves performance by minimizing DOM size.
• Small fixes.

See #51

---

Preview | Diff

[TallTed]

This is very difficult to review. So many changes, touching most if not every line! It would be somewhat easier to review if each bullet point were its own commit ... but still not easily done.

[domel]

The changes are not that big, it's just that diff can't show it.

[pfps]

As far as I can tell the changes are very big. Perhaps part of the changes are changing whitespace. But there is also the movement of

markup to separate lines, which doesn't seem to be mentioned in the summary of the change. In my opinion it would have been better to not have the formatting changes.

[domel]

Yes, most of these changes are extra spaces or deleted spaces. To properly understand and improve the document, I first had to clean up the indentation. My editor does this automatically.

[domel]

It's a bit of a stretch to say the changes are big when nothing has changed in terms of content.

[niklasl]

I found it easier to view the changes by using the "Hide whitespace" checkbox (then "Apply and reload"). (Finding it may be harder; click the "gear" button under the "Files changed" tab.)

[TallTed]

Including whitespace, GitHub indicates 3,864 lines were changed.

Excluding whitespace, GitHub indicates 1,940 lines were changed. (I do note that GitHub doesn't treat linefeed addition/deletion as whitespace changes.)

Even if only one character was changed on each of those lines, and even if those changes were only to markup (e.g., fixing an </a> that should have been </p>), I certainly consider the net effect of this PR to be a large change.

[domel]

@TallTed These single-character changes most often involve changing a single letter, e.g. the graph G, to <em>G</em>. There are a lot of such letters, so there are a lot of edits.

[TallTed]

There are a lot of such letters, so there are a lot of edits.

Yes. And they are hard to review, all at once, all of a piece.

They would be easier to review if there were many commits contained within this PR, e.g., "change all graph G to graph <em>G</em>".

Reviewing commit-by-commit would be FAR easier than reviewing all-at-once, which is the only current option.

[gkellogg]

The nature of source formatting changes is that it can change a lot of lines. But, looking at it with the "ignore whitespace" option, and in the HTML Diff, it's clear that the changes are limited to formatting.

Note that this will collide with other open pull requests. We should probably merge those first, rebase this PR on that, and then merge this.

[domel]

Well, it could have been devided, but I treated everything that is not semantic as one PR. On the other hand, I don't fully understand what the difference is in checking time 5*20% and 100%. Yes, it's a big PR because the current specification document is/was in a terrible state.

[gkellogg]

The build error may indicate some underling issue, but a ReSpec problem prevents it from being displayed; or, it may just be a ReSpec issue itself.

[TallTed]

GitHub fails to highlight my suggested changes. Please use your preferred diff tool.

Suggested change

	<p>If <em>E</em> is a ground RDF graph, then <em>I(E) = false</em> if <em>I(E')</em> =
	false for some triple <em>E'</em> in <em>E</em>, otherwise <em>I(E) = true</em>.
	<p>If <em>E</em> is a ground RDF graph and <em>I(E') = false</em>
	for some triple <em>E'</em> in <em>E</em>, then
	<em>I(E) = false</em>; otherwise, <em>I(E) = true</em>.

[domel]

@TallTed Thanks for pointing out a few <em>s. I found some more. Also, I actually forgot about <code> vs. <pre>. That's fixed too. You can take a look again.

[gkellogg]

ReSpec Build error reported: speced/respec#4825.

[domel]

@gkellogg Is this a ReSpec issue, or has something in the structure been accidentally changed that is inconsistent with ReSpec recommendations?

[gkellogg]

@gkellogg Is this a ReSpec issue, or has something in the structure been accidentally changed that is inconsistent with ReSpec recommendations?

I believe the ReSpec issue is in reporting the underlying error. It does not error in the same way on the main branch. But, it could still be entirely a ReSpec internal thing. I'm hoping they can address/fix this one quickly.

[pfps]

Closing, finally, as will not be done

[domel]

@pfps?

[domel]

@pfps why did you close this PR?

[pfps]

Sorry, I thought this was the one for better display on mobile devices.

[pfps]

The Semantic Conditions for Ground Graphs have been subtly changed so that they no longer are correct.. This happens in a large change block where it is unclear just what the substantive change is.

This and any other substantive changes need to be removed from the PR. It is unacceptable as is.

[pfps]

This PR shows the pitfalls of using a mechanical style. The list of terminology was very much easier to see in the source when each item was one line. With each item taking up multiple lines is is much harder to get a notion from the source of what terminology is being used.