lichess.org
Donate

Surgical lobby module(s) obliteration

Would it be possible to allow some modules to not be shown upon entry. Those thing one never looks at.

I can use the inspector and hide this selector, but I find the fine grain style controls to do the same not that friendly.

I could keep researching and learning about CSS properties... Or maybe you know what to put in overrides once I know the selector div label (or whatever the official name).

But I thought of LT already being able to work on the local front. I have almost half the front page I could do without, and have some focus. Not asking for redesign.. but either LT, could try to got there, or maybe the method for overrrides is easy to hide whole selector (div) node.

But it might also be a suggestion, for giving back to users some customization power, in spite of the web standard or server-centric economy principles, it would not harm anything across the web pipes. if not mistaken.

Would it be possible to allow some modules to not be shown upon entry. Those thing one never looks at. I can use the inspector and hide this selector, but I find the fine grain style controls to do the same not that friendly. I could keep researching and learning about CSS properties... Or maybe you know what to put in overrides once I know the selector div label (or whatever the official name). But I thought of LT already being able to work on the local front. I have almost half the front page I could do without, and have some focus. Not asking for redesign.. but either LT, could try to got there, or maybe the method for overrrides is easy to hide whole selector (div) node. But it might also be a suggestion, for giving back to users some customization power, in spite of the web standard or server-centric economy principles, it would not harm anything across the web pipes. if not mistaken.

The problem with UI changes is that they increase maintenance exponentially. For each item you could hide/show you have two states, but for two you have four, for three you have 8. I would rather not do that except maybe for static CSS styles that can be introduced as themes.

Don't forget that whatever I change has to make sense for low resolutions like mobile devices.

CSS is really easy. Nothing complex:
element
.class
#id
[attribute]
[attribute="some value"]
[attribute^="starts with"]
[attribute*="contains"]
[attribute$="ends with"]

And then you have > and + modifiers

And then you have
:hover
:has(selector)
:not(selector)

and you can chain them
parent descendant

But the first three things are 90% of it.

The problem with UI changes is that they increase maintenance exponentially. For each item you could hide/show you have two states, but for two you have four, for three you have 8. I would rather not do that except maybe for static CSS styles that can be introduced as themes. Don't forget that whatever I change has to make sense for low resolutions like mobile devices. CSS is really easy. Nothing complex: element .class #id [attribute] [attribute="some value"] [attribute^="starts with"] [attribute*="contains"] [attribute$="ends with"] And then you have > and + modifiers And then you have :hover :has(selector) :not(selector) and you can chain them parent descendant But the first three things are 90% of it.

Thanks for the explanation of the mechanisms. And the CSS elements to look for. And the vertical flow of priority.

I actually have already tweaked around already. It is more about simple way to act on node appearance. Just commenting out does not seem equivalent to the "hide" the node context menu. So I could tweak things like Flex. or change some colors, or play with one element width, and feel the interactions at whole page design level. I basically worked with knocking off things.

overflow, flex, and colors. if memory serves.. I would have good sense of the selector syntax. ...

Sub-question (I understand not wanting to put finger in some chain of interdependent cascading cogs).

So what CSS modification would be equivalent to the hide in Devtools inpector context menu, when pointing at the div of the superfluous visual object in question (target).

The hide succeeds, but is not persistent, like CSS overriding would until next lichess UI updating my local bundle).
I don't mind that the space be taken, I just don't need the visual distraction. Commenting out. or is there a hide CSS word that can control or hide all previous same selector visuals.. as last lines.. (if last has precedence).

Thanks for the explanation of the mechanisms. And the CSS elements to look for. And the vertical flow of priority. I actually have already tweaked around already. It is more about simple way to act on node appearance. Just commenting out does not seem equivalent to the "hide" the node context menu. So I could tweak things like Flex. or change some colors, or play with one element width, and feel the interactions at whole page design level. I basically worked with knocking off things. overflow, flex, and colors. if memory serves.. I would have good sense of the selector syntax. ... Sub-question (I understand not wanting to put finger in some chain of interdependent cascading cogs). So what CSS modification would be equivalent to the hide in Devtools inpector context menu, when pointing at the div of the superfluous visual object in question (target). The hide succeeds, but is not persistent, like CSS overriding would until next lichess UI updating my local bundle). I don't mind that the space be taken, I just don't need the visual distraction. Commenting out. or is there a hide CSS word that can control or hide all previous same selector visuals.. as last lines.. (if last has precedence).

display:none; - this hides something

there is such thing as CSS specificity. If you have two rules like "div.parent div.child" and one "div.child" changing the same property, the first one will override the second because it's more specific. If you want to avoid that, add an "!important" at the end of the rule:

div.child {
display:none !important'
}

display:none; - this hides something there is such thing as CSS specificity. If you have two rules like "div.parent div.child" and one "div.child" changing the same property, the first one will override the second because it's more specific. If you want to avoid that, add an "!important" at the end of the rule: div.child { display:none !important' }

i remember that !important. thanks for this... I have a tendency to remember there is a logic flow, but can easily invert polarity, in memory... usually, have to bug in one direction through light testing, and figure out, I might have been looking upside down.

Even with electric circuits.. remembering the battery orientation. Conventional polarities. I did enjoy that selector "logic". It can be learned very well interactively with a web page and the mouse through Devtools inspector. Visual support of its logic. mutate or probe here, and look there.. induce mechanical behavior (or syntax "logic").

reverse engineering fun. or learning.. or modelling.. But got tired at min.js obscure layer.

i remember that !important. thanks for this... I have a tendency to remember there is a logic flow, but can easily invert polarity, in memory... usually, have to bug in one direction through light testing, and figure out, I might have been looking upside down. Even with electric circuits.. remembering the battery orientation. Conventional polarities. I did enjoy that selector "logic". It can be learned very well interactively with a web page and the mouse through Devtools inspector. Visual support of its logic. mutate or probe here, and look there.. induce mechanical behavior (or syntax "logic"). reverse engineering fun. or learning.. or modelling.. But got tired at min.js obscure layer.

This topic has been archived and can no longer be replied to.