On Sat, 16 Oct 2021 at 23:28:50, Mayayana <mayayana@invalid.nospam>
wrote (my responses usually follow points raised):
[]
>but it's still Rube Goldberg code. The following would achieve

(For UK readers: read Heath Robinson.)

>the desired result with no complications and without breaking
>in any browser. It will even look fine in IE5. It just wouldn't
>show the round corners.

Oh what a disaster, no round corners )-:.
>
><A STYLE="background-color: #5319E7; color: #FFFFFF; font-family:
>sans-serif; font-size: 12px; padding: 5 20 5 20; border-radius: 20px;"> open
>for vote</A>
[]
> We could say their method is valid CSS but it's actually
>sloppy and overly complicated. And it doesn't work in all

Much machine-generated HTML is theoretically valid, but _vastly_ overly
complicated: it inevitably includes far too many DIVs, and not
infrequently TABLEs within tables to three or four levels. Makes the
source code, in effect, illegible.

>browsers. Technical accuracy is not of much value if
>it produces brittle code. It wasn't so long ago that the

Hear hear.

>general idea was to make a page render as accurately as
>possible in as many browsers as possible. To say some
>browsers are not sufficiently modern is no excuse.
>
If anything, sometimes one gets the impression that it is deliberately
written to exclude older browsers (and make older hardware very slow -
even a page of just text can take a long time to load); certainly, any
_caring_ about them is mostly long gone.
>
</rant> (-:
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

I'm not a great fan of new technology. I don't change my phone every time the
bell rings - Sir David Attenborough, RT 2016/1/23-29

On Sat, 16 Oct 2021 23:28:50 -0400, Mayayana wrote:

> "Ralph Fox" <-rf-nz-@-.invalid> wrote
>
> | The 'span' element has inherited 'color' from the parent 'a' element.
> | This is standard HTML/CSS behaviour.
>
> Thanks for that detailing. But there's no reason for the
> span element.

Most sites today are not hand-coded in raw HTML code.
See John's reply about machine generated code.

> Even setting that issue aside, the color spec
> seems to make no sense.
>
> It should be <A CLASS="A1"> text here </A> The A tag
> can accommodate all style specs by itself. SPAN is superfluous.
> I didn't try to calculate all of that math for the color value,
> but it's still Rube Goldberg code. The following would achieve
> the desired result with no complications and without breaking
> in any browser. It will even look fine in IE5. It just wouldn't
> show the round corners.
>
> <A STYLE="background-color: #5319E7; color: #FFFFFF; font-family:
> sans-serif; font-size: 12px; padding: 5 20 5 20; border-radius: 20px;"> open
> for vote</A>

The code looks to be the way it is so that users can change a theme and
have the page update immediately, locally, without the delay of a post
back to the web server. Your colour #hex codes above would require a
post back to the web server and the web server to dynamically generate
new HTML with different colour #hex codes to return to the browser.

Today's interactive web2.0 is different to the old web, and interactive
responsiveness is important today.

> As it's been specced, the color has to be grayscale
> because hue and saturation are both 0. So while the
> perceived lightness seems to be calculating an off-white
> hue based on the purple, it can only be grayscale, no matter
> what that calculation produces. Somewhere along the way, some
> browsers are calculating a medium gray instead of white.
>
> We could say their method is valid CSS but it's actually
> sloppy and overly complicated. And it doesn't work in all
> browsers. Technical accuracy is not of much value if
> it produces brittle code.

Major web sites only try to support the most recent 3 versions
of major browsers. Old browsers do not fully support the
interactive responsiveness expected in today's web. There is
a difference between not supporting older browsers and being
brittle.

> It wasn't so long ago that the
> general idea was to make a page render as accurately as
> possible in as many browsers as possible. To say some
> browsers are not sufficiently modern is no excuse.

You will find few web sites today work properly in
CERN WorldWideWeb/Nexus or in NCSA Mosaic. 😀

--
Kind regards
Ralph
🦊

"Ralph Fox" <-rf-nz-@-.invalid> wrote

| The code looks to be the way it is so that users can change a theme and
| have the page update immediately, locally, without the delay of a post
| back to the web server. Your colour #hex codes above would require a
| post back to the web server and the web server to dynamically generate
| new HTML with different colour #hex codes to return to the browser.

I find it odd that you feel a need to defend these
techniques with any farfetched theory at hand. The
code specs the colors. RGB or hex makes no difference.
The code is speccing a button. No one's changing colors.
There's nothing "responsive". To the contrary. They
haven't even bothered to give it a responsive hover
action.

If they wanted to do design it so that any "Tom, Dick or
Harry", at the drop of a hat, could for unknown reasons
change the button color, then that's exactly what CSS is
for. The button should have a class name and the class
CSS would then be specced in a CSS file that could easily be
updated. That was the whole point of creating CSS.
Instead, in this case, the color is in the HTML as a
convoluted mess of inline CSS gibberish. It's not defensible.
It's not responsive. It's not easy to update. It's just plain crap.

On Sat, 23 Oct 2021 21:40:02 -0400, Mayayana wrote:
> "Ralph Fox" <-rf-nz-@-.invalid> wrote
>
> | The code looks to be the way it is so that users can change a theme and
> | have the page update immediately, locally, without the delay of a post
> | back to the web server. Your colour #hex codes above would require a
> | post back to the web server and the web server to dynamically generate
> | new HTML with different colour #hex codes to return to the browser.
>
> I find it odd that you feel a need to defend these
> techniques with any farfetched theory at hand.

Far from being a "farfetched theory", github.com pages are designed to
switch instantly between a "day" theme and a "night" theme. If you
are not signed in to github.com, you are switched between the default
light and dark themes. If you have a github.com account and are
signed in you have a choice of themes for each.

> The
> code specs the colors. RGB or hex makes no difference.
> The code is speccing a button. No one's changing colors.
> There's nothing "responsive". To the contrary. They
> haven't even bothered to give it a responsive hover
> action.

Hover action is not the only place to be responsive, and hover action
for the *labels* "enhancement" and "open for vote" is not what they
are trying to do.

FWIW the "New issue" *button* at the top right does have a hover action.

--
Kind regards
Ralph

"Ralph Fox" <-rf-nz-@-.invalid> wrote

| Far from being a "farfetched theory", github.com pages are designed to
| switch instantly between a "day" theme and a "night" theme. If you
| are not signed in to github.com, you are switched between the default
| light and dark themes. If you have a github.com account and are
| signed in you have a choice of themes for each.
|

Ah. Interesting. Thanks for that info. It does seem to
explain why the font is meant to be a degree of brightness
relative to the button color. I never would have imagined
such a thing. I think I'd rather not know how they guess
whether it's dark or not... Idiocy knows no bounds.

|
| > The
| > code specs the colors. RGB or hex makes no difference.
| > The code is speccing a button. No one's changing colors.
| > There's nothing "responsive". To the contrary. They
| > haven't even bothered to give it a responsive hover
| > action.
| |
| Hover action is not the only place to be responsive, and hover action
| for the *labels* "enhancement" and "open for vote" is not what they
| are trying to do.
| | FWIW the "New issue" *button* at the top right does have a hover action.
| |
| --
| Kind regards
| Ralph

Mayayana <mayayana@invalid.nospam> wrote:

> "Ralph Fox" <-rf-nz-@-.invalid> wrote
>
>| Far from being a "farfetched theory", github.com pages are designed to
>| switch instantly between a "day" theme and a "night" theme. If you
>| are not signed in to github.com, you are switched between the default
>| light and dark themes. If you have a github.com account and are
>| signed in you have a choice of themes for each.
>
> Ah. Interesting. Thanks for that info. It does seem to
> explain why the font is meant to be a degree of brightness
> relative to the button color. I never would have imagined
> such a thing. I think I'd rather not know how they guess
> whether it's dark or not... Idiocy knows no bounds.

Especially when the vast majority of visitors are using their computer
in a lit room. The only folks I know that sit in a dark room using
their computers are gamers.

"VanguardLH" <V@nguard.LH> wrote

| Especially when the vast majority of visitors are using their computer
| in a lit room. The only folks I know that sit in a dark room using
| their computers are gamers.

I suppose you could be outside, vs a dimly lit room.
What if you move between rooms? Is your camera measuring
light intensity? What if you don't have a camera? This
whole thing is so ridiculous that I can't even imagine a
way it might work.

And the cost, in addition to qwidespread broswer
incompatibility, is a bloated pile of gibberish code, requiring
browser calculations, for every button on the page! They didn't
spec CSS for a class. It's inline, for every button. The only thing
I can guess is that github is run mainly by a bunch of college
students who challenge each other. One make text color
vary by ambient light level. The next has to outdo him: "Kewlllll.
But check this out. If you hover over this link it turns into the
face of Jesus, compsed entirely of ASCII characters! Whoa!
(But be sure you're using Chrome v. 96)"

We seem to be reverting to the days of "This site best viewed
in Internet Explorer 5.01.426.72, at 800x600, with Flash 2.374."
Then if we have all of that then we get to see their fluorescent
green, dripping text on a black background.

[Mayayana, Sat, 30 Oct 2021 08:17:32 -0400]

> I think I'd rather not know how they guess
> whether it's dark or not...

[VanguardLH, Sat, 30 Oct 2021 08:52:36 -0500]

> Especially when the vast majority of visitors are using their computer
> in a lit room. The only folks I know that sit in a dark room using
> their computers are gamers.

[Mayayana, Sat, 30 Oct 2021 10:02:57 -0400]

> I suppose you could be outside, vs a dimly lit room.
> What if you move between rooms? Is your camera measuring
> light intensity? What if you don't have a camera? This
> whole thing is so ridiculous that I can't even imagine a
> way it might work.

Better to RTFM that this wild speculation about using your camera (which
you may not have).

MacOS: <https://support.apple.com/en-gb/guide/mac-help/mchl52e1c2d2/mac>
* MacOS Auto switching: built in, see the link above.
Win10: <https://www.tenforums.com/tutorials/24038-change-default-app-windows-mode-light-dark-theme-windows-10-a.html>
* Win10 Auto switching: <https://www.windowscentral.com/auto-dark-mode-app-microsoft-needs-build-windows-11>
Linux: <https://www.howtogeek.com/669755/how-to-enable-dark-mode-on-ubuntu-20.04-lts/>
* Linux Auto switching: <https://extensions.gnome.org/extension/2236/night-theme-switcher/>

How the web page knows which mode your OS is using.
<https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme>

--
Kind regards
Ralph