Hi all,
since a long time I noticed that the text in the header at
https://sourceforge.net/ is hardly readable. SM shows black text on the
dark brown background. The same with the drop down menus there. F.i.
FF85 shows the same text in white.

Similar the second line - orange background and dark brown text while
with f.i. FF85 the text is white.

Long time I thought this is only a problem with our SM2.42xx OS/2 port.
But today I tried SM2.53.16 on Win10 and there's the same problem with
sourceforge.net.

No clue if I can attach a picture here. Have to test.

Any clues?

Regards,
Andi

On Thu, 22 Feb 2024 17:11:31 +0100, Andi B. wrote:

> Hi all,
> since a long time I noticed that the text in the header at
> https://sourceforge.net/ is hardly readable. SM shows black text on the
> dark brown background. The same with the drop down menus there. F.i.
> FF85 shows the same text in white.
>
> Similar the second line - orange background and dark brown text while
> with f.i. FF85 the text is white.
>
> Long time I thought this is only a problem with our SM2.42xx OS/2 port.
> But today I tried SM2.53.16 on Win10 and there's the same problem with
> sourceforge.net.

It looks fine here in SeaMonkey 2.53.18.1, the same as in Firefox 123.0:

Screen-shot of SM: <http://img4.imagetitan.com/img.php?image=27_ur7rnj_1__sourceforge_in_seamonkey_2-53-18-1.png>
Screen-shot of FF: <http://img4.imagetitan.com/img.php?image=27_ur7rnj_2__sourceforge_in_in_firefox_123-0.png>

> No clue if I can attach a picture here. Have to test.

You can upload a picture to someplace like <https://imgur.com/> or
<http://www.imagetitan.com/>, and post the link here.

> Any clues?
>
> Regards,
> Andi

--
Kind regards
Ralph Fox
🦊

There is some reason the belly should have no ears, because words will not fill it.

Ralph Fox wrote:
> On Thu, 22 Feb 2024 17:11:31 +0100, Andi B. wrote:
>
>> Hi all,
>> since a long time I noticed that the text in the header at
>> https://sourceforge.net/ is hardly readable. SM shows black text on the
>> dark brown background. The same with the drop down menus there. F.i.
>> FF85 shows the same text in white.
>>
>> Similar the second line - orange background and dark brown text while
>> with f.i. FF85 the text is white.
>>
>> Long time I thought this is only a problem with our SM2.42xx OS/2 port.
>> But today I tried SM2.53.16 on Win10 and there's the same problem with
>> sourceforge.net.
> It looks fine here in SeaMonkey 2.53.18.1, the same as in Firefox 123.0:
>
> Screen-shot of SM: <http://img4.imagetitan.com/img.php?image=27_ur7rnj_1__sourceforge_in_seamonkey_2-53-18-1.png>

And my OS/2 2.42.9 looks almost identical to the above screen shot.
Was it a new profile on Win10? Test on OS/2 with a new profile
Dave

On 2024-02-22, Ralph Fox <-rf-nz-@-.invalid> wrote:

> On Thu, 22 Feb 2024 17:11:31 +0100, Andi B. wrote:
>
>> Hi all,
>> since a long time I noticed that the text in the header at
>> https://sourceforge.net/ is hardly readable. SM shows black text on the
>> dark brown background. The same with the drop down menus there. F.i.
>> FF85 shows the same text in white.
>>
>> Similar the second line - orange background and dark brown text while
>> with f.i. FF85 the text is white.
>>
>> Long time I thought this is only a problem with our SM2.42xx OS/2 port.
>> But today I tried SM2.53.16 on Win10 and there's the same problem with
>> sourceforge.net.
>
> It looks fine here in SeaMonkey 2.53.18.1, the same as in Firefox 123.0:
>
> Screen-shot of SM: <http://img4.imagetitan.com/img.php?image=27_ur7rnj_1__sourceforge_in_seamonkey_2-53-18-1.png>
> Screen-shot of FF: <http://img4.imagetitan.com/img.php?image=27_ur7rnj_2__sourceforge_in_in_firefox_123-0.png>

I haven't visited that web site, so I can't speak on this particular
problem. However, I did notice that a few problems I was having have
either disappeared or diminished when I upgraded to 2.53.18.1. It's
worth doing the upgrade.

It still shows a blank screen on the Dropbox site (https://www.dropbox.com),
though - I have to fall back to Firefox for that.

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

Ralph Fox wrote on 23/2/24 2:01 am:
> On Thu, 22 Feb 2024 17:11:31 +0100, Andi B. wrote:
>
>> Hi all,
>> since a long time I noticed that the text in the header at
>> https://sourceforge.net/ is hardly readable. SM shows black text on the
>> dark brown background. The same with the drop down menus there. F.i.
>> FF85 shows the same text in white.
>>
>> Similar the second line - orange background and dark brown text while
>> with f.i. FF85 the text is white.
>>
>> Long time I thought this is only a problem with our SM2.42xx OS/2 port.
>> But today I tried SM2.53.16 on Win10 and there's the same problem with
>> sourceforge.net.
>
> It looks fine here in SeaMonkey 2.53.18.1, the same as in Firefox 123.0:
>
> Screen-shot of SM: <http://img4.imagetitan.com/img.php?image=27_ur7rnj_1__sourceforge_in_seamonkey_2-53-18-1.png>
> Screen-shot of FF: <http://img4.imagetitan.com/img.php?image=27_ur7rnj_2__sourceforge_in_in_firefox_123-0.png>
>
Um, the OP is correct!
Definitely not the same visible rendering in the two examples above!
Sourceforge title bar =
No visible header buttons
no visible "login" button (far right)
Text underneath is white in Firefox and Chromium, not black.

If you move your mouse over the title bar, the buttons will become
visible, but are otherwise invisible.
The buttons are all are visible in both Firefox and Chromium.
HTH Barry
>
>> No clue if I can attach a picture here. Have to test.
>
> You can upload a picture to someplace like <https://imgur.com/> or
> <http://www.imagetitan.com/>, and post the link here.
>
>
>> Any clues?
>>
>> Regards,
>> Andi
>
>

On Thu, 22 Feb 2024 17:11:31 +0100, Andi B. wrote:
>
> since a long time I noticed that the text in the header at
> https://sourceforge.net/ is hardly readable. SM shows black text on the
> dark brown background. The same with the drop down menus there. F.i.
> FF85 shows the same text in white.
> ...

If there's any "dark brown", there is a colour problem somewhere between
the browser code and OP's colour vision. The backgrounds are black,
orange and transparent, unless a pseudo-button is hovered.

The text style of a pseudo-button is that of an <a> element (anchor)
which page CSS defines to have color: rgb(0, 153, 204), a slightly
greenish blue (overriding the default; it also removes the link
text-decoration, the tell-tale underline).

In the top bar, when not hovered, the pseudo-button text colour is set
to that of the parent element (color: inherit), which is white; when
hovered, the text colour becomes color: rgb(51, 51, 51), which appears
black, against a background: rgb(0, 204, 255), a paler greenish blue.

In FF 115esr, that all works. In SM 2.53.18, and doubtless earlier
versions, the text doesn't inherit the parent colour as expected. The
inherited colour (white) comes from a <section> element but that isn't
shown as a possible parent in the SM CSS devtools. If you set the colour
on some other parent instead, it behaves like FF, eg

.l-header-nav > * > .row {
color: white;
}

Maybe there is a manifest list of known tags that can be styled
somewhere in the code where "section" hasn't been added. Maybe some
other HTML5 tags are missing. Or maybe there's some obscure part of the
CSS specification that's being interpreted "differently".

/df

--
London
UK

Ralph Fox wrote on 2/22/24 11:01 AM:
> On Thu, 22 Feb 2024 17:11:31 +0100, Andi B. wrote:
>
>> Hi all,
>> since a long time I noticed that the text in the header at
>> https://sourceforge.net/ is hardly readable. SM shows black text on the
>> dark brown background. The same with the drop down menus there. F.i.
>> FF85 shows the same text in white.
>>
>> Similar the second line - orange background and dark brown text while
>> with f.i. FF85 the text is white.
>>
>> Long time I thought this is only a problem with our SM2.42xx OS/2 port.
>> But today I tried SM2.53.16 on Win10 and there's the same problem with
>> sourceforge.net.
>
> It looks fine here in SeaMonkey 2.53.18.1, the same as in Firefox 123.0:
>
> Screen-shot of SM: <http://img4.imagetitan.com/img.php?image=27_ur7rnj_1__sourceforge_in_seamonkey_2-53-18-1.png>
> Screen-shot of FF: <http://img4.imagetitan.com/img.php?image=27_ur7rnj_2__sourceforge_in_in_firefox_123-0.png>
>
>
>> No clue if I can attach a picture here. Have to test.
>
> You can upload a picture to someplace like <https://imgur.com/> or
> <http://www.imagetitan.com/>, and post the link here.
>
>
>> Any clues?
>>
>> Regards,
>> Andi
>
>
The items in SeaMonkey 2.53.18 indicate the same as the op for the title bar.
- the title bar is the bar with the SourceForge name.
=> In SM, horizontally scroll the mouse on the title bar to the right
side of the envelope(subscribe) icon and 5 items will appear as the mouse
passes over each area - For Vendors, Help, Create, Join, and Login. Each
item appears(on this Win11 device) with black/dark grey text on top of a
light blue background.
- that same location in FF, Chrome, and Edge(all current
version/build) shows those options as visible with white text on a light
blue background.

The orange bar in SM shows three items - black text on the orange
background. Each item when selected switches to black text with a white
background. In FF, Chrome, and Edge text those same items show on the
organge bar as white text on an orange background, when selected they
become(the same as SM) black text with a white background.

--
....w¡ñ§±¤ñ

Dirk Fieldhouse schrieb:
> On Thu, 22 Feb 2024 17:11:31 +0100, Andi B. wrote:
>>
>> since a long time I noticed that the text in the header at
>> https://sourceforge.net/ is hardly readable. SM shows black text on the
>> dark brown background. The same with the drop down menus there. F.i.
>> FF85 shows the same text in white.
>> ...
>
> If there's any "dark brown", there is a colour problem somewhere between
> the browser code and OP's colour vision. The backgrounds are black,
> orange and transparent, unless a pseudo-button is hovered.
>
> The text style of a pseudo-button is that of an <a> element (anchor)
> which page CSS defines to have color: rgb(0, 153, 204), a slightly
> greenish blue (overriding the default; it also removes the link
> text-decoration, the tell-tale underline).
>
> In the top bar, when not hovered, the pseudo-button text colour is set
> to that of the parent element (color: inherit), which is white; when
> hovered, the text colour becomes color: rgb(51, 51, 51), which appears
> black, against a background: rgb(0, 204, 255), a paler greenish blue.
>
> In FF 115esr, that all works. In SM 2.53.18, and doubtless earlier
> versions, the text doesn't inherit the parent colour as expected. The
> inherited colour (white) comes from a <section> element but that isn't
> shown as a possible parent in the SM CSS devtools. If you set the colour
> on some other parent instead, it behaves like FF, eg
>
> .l-header-nav > * > .row {
> color: white;
> }
>
> Maybe there is a manifest list of known tags that can be styled
> somewhere in the code where "section" hasn't been added. Maybe some
> other HTML5 tags are missing. Or maybe there's some obscure part of the
> CSS specification that's being interpreted "differently".
>
> /df
>
Thanks for confirming the difference and detailed description although I
don't understand all of it.

Question, as an end user can I do anything against that nearly
unreadable text/buttons? Except hoovering over with the mouse which
triggers changing text color?

Thanks. Andi.

Charlie Gibbs wrote on 23/2/24 6:46 am:

<Snip>

> I haven't visited that web site, so I can't speak on this particular
> problem. However, I did notice that a few problems I was having have
> either disappeared or diminished when I upgraded to 2.53.18.1. It's
> worth doing the upgrade.
>
> It still shows a blank screen on the Dropbox site (https://www.dropbox.com),
> though - I have to fall back to Firefox for that.
>
"Join over 700 million registered users who trust Dropbox"

Dropbox WFM!!

--
Daniel

Barryedwin1 wrote on 23/2/24 9:50 am:
> Ralph Fox wrote on 23/2/24 2:01 am:
>> On Thu, 22 Feb 2024 17:11:31 +0100, Andi B. wrote:
>>
>>> Hi all, since a long time I noticed that the text in the header
>>> at https://sourceforge.net/ is hardly readable. SM shows black
>>> text on the dark brown background. The same with the drop down
>>> menus there. F.i. FF85 shows the same text in white.
>>>
>>> Similar the second line - orange background and dark brown text
>>> while with f.i. FF85 the text is white.
>>>
>>> Long time I thought this is only a problem with our SM2.42xx
>>> OS/2 port. But today I tried SM2.53.16 on Win10 and there's the
>>> same problem with sourceforge.net.
>>
>> It looks fine here in SeaMonkey 2.53.18.1, the same as in Firefox
>> 123.0:
>>
>> Screen-shot of SM:
>> <http://img4.imagetitan.com/img.php?image=27_ur7rnj_1__sourceforge_in_seamonkey_2-53-18-1.png>
>>
>> Screen-shot of FF:
>> <http://img4.imagetitan.com/img.php?image=27_ur7rnj_2__sourceforge_in_in_firefox_123-0.png>
>>
> Um, the OP is correct! Definitely not the same visible rendering in
> the two examples above! Sourceforge title bar = No visible header
> buttons no visible "login" button (far right) Text underneath is
> white in Firefox and Chromium, not black.
>
> If you move your mouse over the title bar, the buttons will become
> visible, but are otherwise invisible. The buttons are all are
> visible in both Firefox and Chromium. HTH Barry

O.K., in my Linux SM 2.53.18.1, when I 'Mouse-over' the right hand end
of the Top (black) row, the various buttons (5 of them) do show up ....
until I get to the already visible 'Subscribe to Our newsletter' button
at centre-screen.
--
Daniel

On 2024-02-23, Dirk Fieldhouse wrote:

> On Thu, 22 Feb 2024 17:11:31 +0100, Andi B. wrote:
>>
>> since a long time I noticed that the text in the header at
>> https://sourceforge.net/ is hardly readable. SM shows black text on the
>> dark brown background. The same with the drop down menus there. F.i.
>> FF85 shows the same text in white.
>> ...
>
> If there's any "dark brown", there is a colour problem somewhere between
> the browser code and OP's colour vision. The backgrounds are black,
> orange and transparent, unless a pseudo-button is hovered.
>
> The text style of a pseudo-button is that of an <a> element (anchor)
> which page CSS defines to have color: rgb(0, 153, 204), a slightly
> greenish blue (overriding the default; it also removes the link
> text-decoration, the tell-tale underline).
>
> In the top bar, when not hovered, the pseudo-button text colour is set
> to that of the parent element (color: inherit), which is white; when
> hovered, the text colour becomes color: rgb(51, 51, 51), which appears
> black, against a background: rgb(0, 204, 255), a paler greenish blue.
>
> In FF 115esr, that all works. In SM 2.53.18, and doubtless earlier
> versions, the text doesn't inherit the parent colour as expected. The
> inherited colour (white) comes from a <section> element but that isn't
> shown as a possible parent in the SM CSS devtools. If you set the colour
> on some other parent instead, it behaves like FF, eg
>
> .l-header-nav > * > .row {
> color: white;
> }
>
> Maybe there is a manifest list of known tags that can be styled
> somewhere in the code where "section" hasn't been added. Maybe some
> other HTML5 tags are missing. Or maybe there's some obscure part of the
> CSS specification that's being interpreted "differently".
>
> /df

From quick testing, this (the computation of the header link text color
at sourceforge.net) seems to have changed between Firefox 83.0 and
Firefox 84.0.

--
Nuno Silva

On 23/02/2024 08:33, Andi B. wrote:
> ...>
> Question, as an end user can I do anything against that nearly
> unreadable text/buttons? Except hoovering over with the mouse which
> triggers changing text color?

Anything that allows you customise the page style per-site will do.

The old SM that you have may not support the StyleM extension (works in
recent SM, linked from pages below) that makes it easy to do that,
though an old version of its predecessors Stylish/Stylus might work. I
used StyleM to test the CSS fragment that I posted.

Alternatively, you can add a style to a CSS file named
chrome/userContent.css in your profile directory. See
<http://forums.mozillazine.org/viewtopic.php?f=40&t=3106815> and the
linked page <http://kb.mozillazine.org/UserContent.css> and the example
files <http://franklion.co.uk/GEN-LINKS/chrome.zip> indirectly linked
from it.

In SM 2.53.18 there's a preference (Appearance>Colours>When a web page
....) to disable the page backgrounds and colours (of whichever
spelling). My default setting ignores the page setting only with a High
Contrast theme. The "Use my chosen colours ..." setting instantly makes
the page, and many others, readable. Since web page "design" is
generally a low form of idiocy, this setting is normally a great
improvement; however sometimes sites will try to present important
information using the overridden settings, such as an image site
displaying the image as a background instead of in an <img> tag; so it
can't be recommended as a default.

/df

--
London
UK

On 2024-02-23, Nuno Silva wrote:

> On 2024-02-23, Dirk Fieldhouse wrote:
>
>> On Thu, 22 Feb 2024 17:11:31 +0100, Andi B. wrote:
>>>
>>> since a long time I noticed that the text in the header at
>>> https://sourceforge.net/ is hardly readable. SM shows black text on the
>>> dark brown background. The same with the drop down menus there. F.i.
>>> FF85 shows the same text in white.
>>> ...
>>
>> If there's any "dark brown", there is a colour problem somewhere between
>> the browser code and OP's colour vision. The backgrounds are black,
>> orange and transparent, unless a pseudo-button is hovered.
>>
>> The text style of a pseudo-button is that of an <a> element (anchor)
>> which page CSS defines to have color: rgb(0, 153, 204), a slightly
>> greenish blue (overriding the default; it also removes the link
>> text-decoration, the tell-tale underline).
>>
>> In the top bar, when not hovered, the pseudo-button text colour is set
>> to that of the parent element (color: inherit), which is white; when
>> hovered, the text colour becomes color: rgb(51, 51, 51), which appears
>> black, against a background: rgb(0, 204, 255), a paler greenish blue.
>>
>> In FF 115esr, that all works. In SM 2.53.18, and doubtless earlier
>> versions, the text doesn't inherit the parent colour as expected. The
>> inherited colour (white) comes from a <section> element but that isn't
>> shown as a possible parent in the SM CSS devtools. If you set the colour
>> on some other parent instead, it behaves like FF, eg
>>
>> .l-header-nav > * > .row {
>> color: white;
>> }
>>
>> Maybe there is a manifest list of known tags that can be styled
>> somewhere in the code where "section" hasn't been added. Maybe some
>> other HTML5 tags are missing. Or maybe there's some obscure part of the
>> CSS specification that's being interpreted "differently".
>>
>> /df
>
> From quick testing, this (the computation of the header link text color
> at sourceforge.net) seems to have changed between Firefox 83.0 and
> Firefox 84.0.

Probably "complex" .not() (with more than one comma-separated argument,
in this case); the devtools inspector in Firefox 84.0 shows that the
color comes from such a CSS rule. Removing the .not() from the selector
(using the devtools inspector in SeaMonkey) makes the rule apply and the
header text color changes to white.

Thus probably https://bugzilla.mozilla.org/show_bug.cgi?id=933562

--
Nuno Silva

On 2024-02-23, Daniel65 <daniel47@nomail.afraid.org> wrote:

> Charlie Gibbs wrote on 23/2/24 6:46 am:
>
> <Snip>
>
>> I haven't visited that web site, so I can't speak on this particular
>> problem. However, I did notice that a few problems I was having have
>> either disappeared or diminished when I upgraded to 2.53.18.1. It's
>> worth doing the upgrade.
>>
>> It still shows a blank screen on the Dropbox site (https://www.dropbox.com),
>> though - I have to fall back to Firefox for that.
>
> "Join over 700 million registered users who trust Dropbox"
>
> Dropbox WFM!!

Yup. And I can avoid using similar products from Google
or Microsoft, both of which I boycott at every opportunity.
(Although Dropbox does pressure you to log in via Google...)

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On Fri, 23 Feb 2024 06:50:02 +0800, Barryedwin1 wrote:
> Ralph Fox wrote on 23/2/24 2:01 am:
>> On Thu, 22 Feb 2024 17:11:31 +0100, Andi B. wrote:
>>
>>> Hi all,
>>> since a long time I noticed that the text in the header at
>>> https://sourceforge.net/ is hardly readable. SM shows black text on the
>>> dark brown background. The same with the drop down menus there. F.i.
>>> FF85 shows the same text in white.
>>>
>>> Similar the second line - orange background and dark brown text while
>>> with f.i. FF85 the text is white.
>>>
>>> Long time I thought this is only a problem with our SM2.42xx OS/2 port.
>>> But today I tried SM2.53.16 on Win10 and there's the same problem with
>>> sourceforge.net.
>>
>> It looks fine here in SeaMonkey 2.53.18.1, the same as in Firefox 123.0:
>>
>> Screen-shot of SM: <http://img4.imagetitan.com/img.php?image=27_ur7rnj_1__sourceforge_in_seamonkey_2-53-18-1.png>
>> Screen-shot of FF: <http://img4.imagetitan.com/img.php?image=27_ur7rnj_2__sourceforge_in_in_firefox_123-0.png>
>>
> Um, the OP is correct!
> Definitely not the same visible rendering in the two examples above!
> Sourceforge title bar =
> No visible header buttons
> no visible "login" button (far right)
> Text underneath is white in Firefox and Chromium, not black.
>
> If you move your mouse over the title bar, the buttons will become
> visible, but are otherwise invisible.
> The buttons are all are visible in both Firefox and Chromium.
> HTH Barry

You are correct.

The problem appears to be with the level of CSS support in
SeaMonkey vs. Firefox.

The problem is with this CSS rule in CSS stylesheet sandiego.css,
which *should* set the 'header button' text colour to white:

    .sandiego .project-masthead .browse_code nav a,.project-body #top_nav_admin ul.dropdown>li ul a,.project-body #top_nav_admin>div>div>.react-drag ul a,.sandiego .header-nav-menulist li,footer.sandiego,.sandiego.l-header-nav-top,.sandiego.l-header-nav-bottom,.sandiego .project-masthead .button:not(.btn-masthead-claim,.commercial-admin),.full-width-masthead .breadcrumbs li:last-child:before,.sandiego .project-masthead .breadcrumbs li:last-child:before{color:#fff}

However, the same CSS rule also contains a :not() CSS pseudo-class
which Firefox 84 and later support, but which it appears SeaMonkey
does not understand. This causes SeaMonkey to throw the entire
rule away.

Below is a minimal test case to show the difference between FF
and SM. If you change the second CSS rule below from this:
    .sandiego.l-header-nav-top,.sandiego .project-masthead .button:not(.btn-masthead-claim,.commercial-admin) {color:#fff}
to this:
    .sandiego.l-header-nav-top {color:#fff}
then this minimal test case will also work in SM.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=us-ascii" />
<title>Test of CSS in Firefox vs SeaMonkey</title>
<style type="text/css">
body { color: #333; }
.sandiego.l-header-nav-top,.sandiego .project-masthead .button:not(.btn-masthead-claim,.commercial-admin) {color:#fff}
.sandiego.l-header-nav-top .links a{color:inherit}
.sandiego.l-header-nav-top{background:#333}
.sandiego.l-header-nav-top .links a:hover{background:#0cf;color:#333 !important;}
.sandiego.l-header-nav-top .links a{display:inline-block;padding:1ex 2em;}
</style>
</head>
<body>
<div class="sandiego">
<section class="sandiego l-header-nav-top">
<nav class="links">
<a href="https://www.mozilla.org/en-GB/firefox/" title="Firefox">Firefox</a>
<a href="https://www.seamonkey-project.org/" title="SeaMonkey">SeaMonkey</a>
<a href="https://developer.mozilla.org/en-US/docs/Web/CSS/:not#browser_compatibility" title="Browser Compatibility">Browser Compatibility</a>
</nav>
</section>
</div>
</body>
</html>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
Kind regards
Ralph Fox
🦊

Fair feathers make fair fowls.

On 23/02/2024 11:48, Nuno Silva wrote:
> On 2024-02-23, Nuno Silva wrote:
>
>>,,,
>> From quick testing, this (the computation of the header link text color
>> at sourceforge.net) seems to have changed between Firefox 83.0 and
>> Firefox 84.0.
>
> Probably "complex" .not() (with more than one comma-separated argument,
> in this case); the devtools inspector in Firefox 84.0 shows that the
> color comes from such a CSS rule. Removing the .not() from the selector
> (using the devtools inspector in SeaMonkey) makes the rule apply and the
> header text color changes to white.
>
> Thus probably https://bugzilla.mozilla.org/show_bug.cgi?id=933562
Exactly, thanks, and Ralph Fox
<lc3jti573s22f4ls2vohu2j7p7b0su0c1u@4ax.com> has provided a test-case.

SF could write :not(sel1):not(sel2) instead of :not(sel1,sel2). Also, a
Palefill hack or similar could make that transformation. Or it could
just be lived with.

/df

--
London
UK