NAGS: A few suggestions [changed from improvement to discussion]

[braoult]

Disclaimer: This is not a request for development (the improvement idea was not a request, I really do not need myself), but just some ideas for possible improvements in NAG display.

Currently, with the moves 1. e4 $1 $10 $13 e5 $44, the HTML becomes (I added newlines for readability):

<span id="boardMoves0" class="move white">
  <a style="">e4!=∞</a>
</span>
<span id="boardMoves1" class="move">
  <a style="">e5=∞</a>
</span>

And displayed as 1. e4!=∞ e5=∞.

There are many issues :

1. For obscure NAGs, the user will have no idea of what it can mean.
   One solution could be to separate the nags in separate elements, and offer a tooltip
2. Even if this example is not good, and may look stupid (like "equal" and "unclear" together), this is what the annotator wanted to write, and two different annotations ($10+$13) & ($44) become the same, but they are not.

My suggestion would be to have HTML designed as following :

<span id="boardMoves0" class="move white goodMove">
  <a style="">e4<span class="nag move">!</nag></a>
  <span class="nag position">=</span>
  <span class="nag position">∞</span>
</span>
<span id="boardMoves1" class="move">
  <a style="">e5</a>
  <span class="nag position">=∞</span>
</span>

And I think the display should be: 1. e4! = ∞ e5 =∞.
Doing this will give many advantages:

1. Associating a class for the move appreciation (goodMove in the example), that are NAGs 1-9, we could display them differently (Lichess does that for example), this is useful to see where a game changes orientation.
2. Visually separating non move-related NAGs allows easier reading
3. Giving classes to NAGs allows many things, such as decoration (colors), tooltips, etc...

What do you think about it ?

[braoult]

Another possible improvement : For unknown NAGs, display an explicative string when NAG has no symbol defined.

I just noticed french translation is incomplete, I take this job (no deadline, sorry !).

[mliebelt]

So I have a different approach / sight here:

• What is the problem at hand? If I don't have a problem, I don't have to change anything.
• What are the "requirements" that could come up in the future?
• Do I like the change?

To the last point: I would like to have something that looks more like

<moves>
<move>
  <index>1</index>
  <san>e4</san>
  <nags><nag>!!</nag><nags>
  <comment>...
</move>
</moves>

Then I would see a big improvement here:

• clear structure, easy to understand
• much easier to style, no accidental styles applied
• more possibilities to style, change, adapt, wrap, ... any element

so I understand your proposal, but I don't see (yet) which problems are solved we have at the moment, and I don't think that it will be the final solution then. Therefore I would like to postpone that as long as I don't know how the structure of HTML elements should look like.

Custom elements of web components are here a relative simple approach, and I would like to use that (trying it out myself) first.

So in my opinion, we should define:

• the structure of the DOM (that should be kept then in all cases)
• the name of the used elements
• possible classes, with the reason to add those classes
• implement that in a backward-compatible way (no changes in style and behavior first)

See the page New proposed HTML structure just created

[braoult]

We can go this way (custom elements), but in this case will it break XHTML compatibility (that we have today) ?
If yes, it means sites that backward-compatibility will not be preserved : Sites that use PgnViewer in XHTML pages (I do) will have to be rewritten in HTML.
Also, according to MDN, Safari and Opera only support "autonomous custom elements" (I don't know what it means at all, and if the proposal is concerned).

[mliebelt]

I don't think so. What I have read is, that custom HTML elements are supported since 7 years, and I don't think that Lichess is not usable in Safari (I have no access any more to any Safari browser) or Opera (tried that). So I think that Lichess uses only / mostly "autonomous custom elements" (which are just new tags), that work in any browser. And that is what my goal is. I did not find any hint that XHTML will not work, and by the way, this is pretty old, nowadays everyone uses HTML5.

[braoult]

I did not find any hint that XHTML will not work, and by the way, this is pretty old, nowadays everyone uses HTML5.

I don't know anything about custom HTML within XHTML. I just have the feeling it could break.

Saying that XHTML is not as popular as HTML is an evidence (around 8% web sites), I just wanted to point out that one requirements is "backward compatibility". I don't mind switching my own chess page, it would not be the first one, but if it breaks XHTML, it means that possibly other sites using PgnViewer could have to do the same.

I hope you are right, that nothing breaks (i.e. that w3c validator will be happy with these custom HTML within XHTML pages).

[mliebelt]

I did a first implementation (only move and subs), and it looks promising. Here are some screen shots.

By having split figure, san, and nags, I am now able to add more information to individual elements (like the title to nag), and the font of the figure may be different to the font of the san (as used for Lichess). I think I will just continue with it, and change only what is necessary.

Shall I do a "preview" in copying the created library to the docs directory, so @braoult could be able to copy that to your local installation, and checking if there are problems with XHTML?

[braoult]

That would be nice, thanks !

[mliebelt]

I deployed the current version to docs, so you are able to see the effects here: https://mliebelt.github.io/PgnViewerJS/config/config.html

The following figurine fonts are currently possible: alpha (default), merida, berlin, noto (== lichess)

I will do today a new release (with everything included), but if that delays, the current version may help check possible problems.

[braoult]

I just made a test, it displays correctly within XHTML, and, the good news is that it validates as XHTML 1.1 on w3c validator.

I was really too pessimistic (!!), and I have learned something about (X)HTML today :-)

very good job !

[braoult]

In fact, the Wikipedia page on NAGs is incorrect in a few ways for me :

1. It gives symbols, without clearly indicating sources. But the Wikipedia Chess Annotation Symbols page seems to indicate source could be Chess Informant and the ECO. But some are different in the two pages: ↻ (CLOCKWISE OPEN CIRCLE ARROW) vs ⟳ (CLOCKWISE GAPPED CIRCLE ARROW) for example. And we may find a few more Informant symbols too, like ○ for space advantage. It indicates also when different symbols can be used (↻ or ↑↑ are equivalent).
2. It does not give the symbols used by different "authorities"/software (Chess Informant - partially done -, ChessBase, etc...).
   As there is no "official" NAG UTF-8 characters (the way it has been done on Wikipedia is probably have a look on the characters on the Chess Informant, and finding something similar in UTF-8). This simply means that Wikipedia UTF-8 symbols look-like the Informant ones, but are not the same.

Notes: I added this morning the ○ for space advantage on Wikipedia NAG page.
And by looking at the page history, I noticed a "bug fix" last Dec: The symbols for $36/$37 and $40/$41 were wrongly switched before.

The question raised in this post is: Is sticking to Wikipedia NAG page the best choice ? We could as well stick to any "reasonable" more accurate source, like the NAGs commonly used by common chess DB software (they all decided to go for something instead of nothing).
The reason ? I think they are the "authority for NAGs" nowadays, nobody else wanting to take any responsibility on defining characters for NAGs, the Informant using only a few, Chessbase/Scid/others software maybe already make usage of common characters that will never appear on Wikipedia NAGs page - which will stick to something similar to -old- Informant icons only, totally unrelated to PGN's NAGs.

All this is just my thoughts about the current messy situation about PGN -especially NAGs- in the world, all chess software devs asking the same desperate question and ending-up creating something new :-)

Note: Example of full Scid's NAGs - please force Unicode encoding in browser to view it. I was unable so far to find Chessbase's ones, I will try to ask in some places such as Reddit/Stackoverflow/IRC...

Does anything makes sense, or should we just forget about it ?

[mliebelt]

Excellent research, thank you a lot. I will try to collect some facts to my Research about NAGs with the idea that the facts are collected, and some decision can be taken. See the corresponding ticket what I would like to do over time. The specification is crap, but there will not be any replacement any time soon. So the best chance is:

• Check the available sources (some tools, mostly online chess sites)
• Propose some "solution"
• Ensure that this solution works for as many people as possible.