#bf4040 — Public Fediverse posts

So I'm looking at extracting page colors that @cassidyjames was experimenting with at one point.

There are unexpected things.

So, apparently there are 3 layers to this in WebKit:

1. https://developer.apple.com/documentation/webkit/wkwebview/3794258-themecolor this property, It's straightforward to expose it in WebKitGTK and it works for e.g. GitLab (#292961) and GitHub (#1E2327)

2. However, that doesn't work for e.g. webkit.org

So then there's https://developer.apple.com/documentation/webkit/wkwebview/3850574-underpagebackgroundcolor

The main purpose of that property is for rubberbanding background.

There's also a deprecated variant of it called extendedBackgroundColor, which is same except read-only. Yep, underPageBackgroundColor is in fact RW. I'm not sure why it is, but it is.

And so webkit.org works: #00253D. Meanwhile on GitLab and GitHub it's just white, except GitHub main page: #0D1117.

3. ...and it's also white on gnome.org. And yet Safari handles it. How?

So, there's a third mechanism - sampled page top color. Apparently it actually measures the colors at the top of the page. However, the catch is that it's private. I'm not sure why exactly that is - maybe they don't want to commit to a hack, maybe they want Safari to have an advantage over competitors, maybe something else.

So anyway, private API. Well, let's expose that color too, we're experimenting anyway.

Now it needs 2 values: min height (the height of the rectangle we're measuring, presumably in px) and max difference - no idea what the unit or the range of values is on that one.

What are the good values? Err, who knows. But there's a test for this thing and it has values that seem to work well: 5 and 100.

And so, with that one:

gnome.org: #4A86CF
webkit.org: nothing on the main page, #00253D on others with solid headers
webkitgtk.org: alternates between nothing and #8B9BAB?..
GitLab: #BF4040
Apple docs: #F5F5F7

So - it works. The fact it's hidden _and_ opt-in makes me wonder if there's large enough overhead though…

Then again -they use it in Safari. So it can't be _that_ bad?

So I'm looking at extracting page colors that @cassidyjames was experimenting with at one point.

There are unexpected things.

So, apparently there are 3 layers to this in WebKit:

1. https://developer.apple.com/documentation/webkit/wkwebview/3794258-themecolor this property, It's straightforward to expose it in WebKitGTK and it works for e.g. GitLab (#292961) and GitHub (#1E2327)

2. However, that doesn't work for e.g. webkit.org

So then there's https://developer.apple.com/documentation/webkit/wkwebview/3850574-underpagebackgroundcolor

The main purpose of that property is for rubberbanding background.

There's also a deprecated variant of it called extendedBackgroundColor, which is same except read-only. Yep, underPageBackgroundColor is in fact RW. I'm not sure why it is, but it is.

And so webkit.org works: #00253D. Meanwhile on GitLab and GitHub it's just white, except GitHub main page: #0D1117.

3. ...and it's also white on gnome.org. And yet Safari handles it. How?

So, there's a third mechanism - sampled page top color. Apparently it actually measures the colors at the top of the page. However, the catch is that it's private. I'm not sure why exactly that is - maybe they don't want to commit to a hack, maybe they want Safari to have an advantage over competitors, maybe something else.

So anyway, private API. Well, let's expose that color too, we're experimenting anyway.

Now it needs 2 values: min height (the height of the rectangle we're measuring, presumably in px) and max difference - no idea what the unit or the range of values is on that one.

What are the good values? Err, who knows. But there's a test for this thing and it has values that seem to work well: 5 and 100.

And so, with that one:

gnome.org: #4A86CF
webkit.org: nothing on the main page, #00253D on others with solid headers
webkitgtk.org: alternates between nothing and #8B9BAB?..
GitLab: #BF4040
Apple docs: #F5F5F7

So - it works. The fact it's hidden _and_ opt-in makes me wonder if there's large enough overhead though…

Then again -they use it in Safari. So it can't be _that_ bad?