overview for MrOtherGuy

*Permanently Deleted* in c/[email protected]

[–] MrOtherGuy 1 points 2 months ago* (last edited 2 months ago)

Yeah, !important doesn't affect inheritance in any way. It only means that this particular rule is to be used if there are multiple rules that would set that particular property for the element in question (unless there's some other more specific rule with !important tag as well). MDN lists property inheritance in the formal definition section. You can totally make background-color inherited though - like *{ background-color: inherit } (and then set the property to something else on the root element from which you would want to inherit from) but it would then either not apply if website set it to anything else for an element or override any other set value if you used !important tag.

One other thing worth noting is that I would not recommend the rules mentioned for userChrome.css to be used as is - at least on Windows they completely break Firefox startup - it fails to display any window if you do that. Instead you should add a [sessionrestored] selector to wait a bit before those rules are applied to main-window:

#main-window[sessionrestored], #tabbrowser-tabpanels{ background: transparent !important; }

*Permanently Deleted* in c/[email protected]

[–] MrOtherGuy 1 points 2 months ago (2 children)

Right, background-color is not an inherited property (compared to for example color (color of text) which is). But even if it were, inheritance is not "enforced" so if website css sets a backround-color specifically for that element then the inherited value would be lost anyway.

But the way you now describe it doesn't seem possible. There is not syntax to apply style rule to "just the innermost element". I think the closest would be to have everything else have fully transparent background, but the html root element have only partial transparency:

*{
  background: transparent !important;
}
html:root{
  background: #00000080 !important;
}

However, you will still face a problem; many websites draw graphics or images as a background-image so if you use the background shorthand property then those graphics will be effectively removed. On the other hand, if you instead set just background-color then parts might get opaque again because a website could be drawing even opaque backgrounds as background-image instead of background-color.

*Permanently Deleted* in c/[email protected]

[–] MrOtherGuy 1 points 2 months ago (4 children)

I think the answer depends on which elements exactly you want to make transparent. The page is a layered structure. The html root element is behind them all. Then body element is on top of that, the rest of the elements on top of body, etc.

So if you intend to have transparency all the way down, then you need to make sure that all the elements in that stack are transparent. If any single item in a stack has an opaque background then the transparency effect stops at that.

As an example, if you set background:transparent to just body but not the document root element, then body will indeed be transparent, but it does not matter because the root will still be opaque. Likewise, if root is made transparent, but there is any opaque layer on top of that, then only the parts of the root element that are not covered by that opaque layer will show up as transparent. If you have a glass table and put a sheet of paper on top of it, then you don't see through the part covered by the paper even though the table itself is transparent.

*Permanently Deleted* in c/[email protected]

[–] MrOtherGuy 2 points 2 months ago (6 children)

Yeah, I just figured the safest option would be to only set the actual document root element transparent - in practice I think it's possibly more likely that the <body> element has background set by the page - although the page might as well set both. So yes, it depends on the website.

*Permanently Deleted* in c/[email protected]

[–] MrOtherGuy 2 points 2 months ago (8 children)

I don't think I understand exactly what parts you want to make transparent, but this does work:

set browser.tabs.allow_transparent_browser to true
in userChrome.css add #main-window, #tabbrowser-tabpanels{ background: transparent !important; }
in userContent.css add html:root{ background-color: transparent !important; }

The above would make window background, and the are behind web-content transparent as well as background of html documents - otherwise the background of browser area wouldn't show up anyway. Toolbars that have their own specified colors would still be colored - which might be opaque or not depending what theme you have selected.

Popup colours on about:addons in c/[email protected]

[–] MrOtherGuy 1 points 2 months ago (2 children)

The options button menus (I guess those are the ones you mean) just are not using the variables you have listed. Probably the most easy solution would be to modify values of the varibles that that those menus are using - just add these two there with your other rules:

    --background-color-box: var(--in-content-page-background) !important;
    --text-color: var(--in-content-text-color) !important;

Although, I don't know how other internal pages might respond to that since the rule set you have applies to pretty much all internal pages, not just about:addons.

Help with z-index in hamburger menu and new Firefox Sidebar in c/[email protected]

[–] MrOtherGuy 1 points 2 months ago (1 children)

I can't check right now, but I'm pretty sure that is because navigator-toolbox has lower z-index than sidebar. So because the panelui button is inside navigator-toolbox it ends up getting covered by sidebar no matter what zindex it has.

Is anybody else experiencing issues with the urlbar on Nightly changing its height/margins? in c/firefoxcss

[–] MrOtherGuy 1 points 2 months ago

With prefs or CSS no, but there's been quite lot of other changes related to that, and I think there's a non-zero chance that some other change could get introduced that could be used to fix custom styling for urlbar.

Is anybody else experiencing issues with the urlbar on Nightly changing its height/margins? in c/firefoxcss

[–] MrOtherGuy 2 points 2 months ago (2 children)

You are almost certainly experiencing changed behavior from this bug

*Permanently Deleted* in c/[email protected]

[–] MrOtherGuy 3 points 2 months ago

Would be pretty idiotic to not close it, otherwise opening a bookmark would always require a second click to close the popup.

Anyways, you can go to about:config and set browser.bookmarks.openInTabClosesMenu to false - afterwards you can hold Ctrl (or just click the middle mouse button) while clicking a bookmark from such popup and the popup should stay open.

Please explain recent 'fix' in Commit e73c60e by adding ' > slot' to selector? in c/[email protected]

[–] MrOtherGuy 2 points 3 months ago (1 children)

Bug 1913322. That style requires the slot element to not have it's own box - previously that was already the case since <slot>s have display: contents by default, but with that style that specific slot was given display: flex and thus have its own box. Thus, we remove it.

Which reminds me, by making it have display: contents the tabs cannot overflow to scrollable box anymore. Instead they just overflow invisibly, which is no bueno.

Please Don’t Make Me Download Another App | Our phones are being overrun in c/technology

[–] MrOtherGuy 12 points 3 months ago

Doesn't really sound like a company that I would want to do any business with then.