Opening names visibility

Study Chapter specific CSS selector syntax, detail:
lichess.org/forum/team-css-javascript-coding-on-lichess/opening-names-visibility#6
The CSS selector chapter suffix hash does not also include the study hash.

Study Chapter specific CSS selector syntax, Quirk:
Data:
The live selector chapter-only hash does not show when following the style panel elements corresponding to the node selected

Could this apparent CSS selector suffix could only be a new Devtools UI feature for the live DOM tree display?

Hypothesis:
Answer no to the above and the live html page being rendered does have that selector, but I wonder then where in the code sent by lichess back-end is that information: somewhere in the CSS code or JS, or whatever html code that exist before the JS or CSS dependent rendering (live DOM tree being the result).

Newbie question (mine):
Is all the DOM tree live html constructed from JS or is lichess also sending some basic html root code? Then how to use Devtools to obtain the non scripted basic html? I ask, because from the DOM tree display editing the node as html does give code that includes the hash. I wonder what this suffix brings, or whether the specificity of CSS styling effect does include word ordering within DIV class string of the node.

Devtools Override Experiments Q&D results:
(excerpt from other thread to show code without hash in selector, that prompted previous post questioning).
From DOM tree to source CSS selector code line, via style panel:

Live html (as copied from Devtools "edit as html" context menu):
- div class="analyse__tools tlI3UIQh"

Devtools selector (context menu):
- #main-wrap > main > div.analyse__tools.tlI3UIQh

To CSS source file (with today's UI front-end hash version: _jnfaaO):
lichess1 . org / assets / _jnfaaO / css / analyse.study.dark.min.css

Just one of the selectors (statement without chapter hash)

.analyse__tools {
/* max-height:100vh; */
}

See other thread for the full results, as basis to develop scripting solution of the full information rendering problem, solving this topic as consequence, but not only that.

lichess.org/forum/team-css-javascript-coding-on-lichess/scroll-independent-full-information-rendering-for-all-analysis-type-pages.

For only Opening name visibility without modifying anything else, the opening explorer module needs to be inspected for the CSS selectors corresponding to the previous script solutions, mentioned in this thread:

lichess.org/forum/team-css-javascript-coding-on-lichess/opening-names-visible-at-all-times-in-analysis-board

If this demotion is only temporary, then this would have been an inspection and coding exercise. It could serve in case of relapse of the condition.

More involved project but probably rewarding reverse learning wise:

There is also the possible question of trying to patch the current JS or CSS locally (script, or JS Devtools console experiments) to move or copy (CSS level possible? or JS required?) back-end opening names that is shown in opening explorer module, to the now hidden hearer object of the move list container.

Has this header been removed or just hidden, and where is the JS code that was producing it before the change?

I have history of minified code, but given that debug break is not accessible anymore, we may need to go Git-hub pre-compile source-code (and find some source map, or ways to go back and forth between concept code and minified code).

The relationship between present minified JS and Typescript concept code from source could give landmarks for finding the old minified code that could be modified for use in tampermonkey JS scripts.

lichess.org/forum/lichess-feedback/make-opening-name-always-visible-while-analyzing#7

I forgot, that I already had some snippet for a script for making the opening explorer title stick when scrolling. That does not fix the relocation problem, though. but give the previous UI CSS selector for the title of that opening explorer box, which now contains also the opening name. Has that changed? next post, when somebody gets to it (me?).

BEFORE: relocation (or demotion) to opening explorer box of opening name. From that link:

.analyse__tools .sub-box .title {
position: sticky;
top: 0;}

NOW:
The parent selector (also node) of the whole opening explorer box:
JS: "#main-wrap > main > div.analyse__tools > section"
html:
<section class="explorer-box sub-box">
--- <div class="overlay"></div>
--- <div class="data">
------ <div class="title">
---------<span title="C30 King's Gambit">
------------<strong>C30</strong> King's Gambit</span>

- well it seems that the new code does not need a script modification for following top of box when scrolling.
it is exactly as above now. Was the opening name just "opening explorer" title of the box? I don't recall.

- anyways, the selector and CSS properties above will affect the stat table column names as well (nodes not displayed, as not likely to be needed for solving relocation or mirroring on move list box header).

Knowing this container structure is important for any possible styling interactions with the above move list container, both being same level siblings. Inheritance and relative values will refer to parent container geometry.

parent:
<div class="analyse__tools">
2 siblings:
move list box:
--- <div class="analyse__moves areplay">
opening explorer box:
--- <section class="explorer-box sub-box"> (as above).

JS issue? possible solution direction:

It appears that there is no node at all for a header of the move list box. We should check what happens when engine turn on, what kind of header. It may be a JS issue, providing for the string of the opening name, and having not created any header where we want. While replacing the string for the top line of opening box header. Some present code debug.break, might show the JS action on the DOM tree when turn engine on, and when changing the opening by exploring first moves.

1 Break point should be at the move list node, for node creationg (subtree modification, engine header), the JS there could be what a JS script in tampermonkey should mimic.

2nd break point should be not at same level, but at the "span title" node for attribute modification. When exploriing from move zero, the first opening name updating call should create a pause point to the minified JS code line that want to change the opening name string. The injecting script should use whatever varialble being updated there and changing the DOM tree element attribute, into the mimicked element creation from first bread.
Any JS experienced coder reading this: feedback welcome as whether this is likely to work.

lichess.org/forum/lichess-feedback/opening-title-position-changed?page=3#21

style issues with opening name #6221
github.com/ornicar/lila/issues/6221#issue-588241100

opening title position changed? #6243
github.com/ornicar/lila/issues/6243#issue-589754779

Quote from developer there confirming that it is not temporary, but by design.
"Yes, it has been moved to the explorer on the analysis board and is no longer available in puzzles. The opening name query is now handled by the explorer, so it is simply not available if the explorer is closed. "
"That's why it moved in the UI, so users make that mental connection."

I admit not to fully to understand the last statement, but it does seem like a user experience design choice. not a load saving measure.

By that statement, though I get some clue about about which source code is responsible for which displayed module, and the data contained. That previously the opening names were not part of the UI, hinting that the move list header or the move list are not considered UI (probably referring to the content, the move tree instance, and its header content).

lichess.org/source
Frontend modules (TypeScript, Sass)
github.com/ornicar/lila/tree/master/ui
github.com/niklasf/lila-openingexplorer