Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@custom-media browser "detection" in props.supports #278

Closed
WebMechanic opened this issue Sep 15, 2022 · 4 comments
Closed

@custom-media browser "detection" in props.supports #278

WebMechanic opened this issue Sep 15, 2022 · 4 comments

Comments

@WebMechanic
Copy link
Contributor

Hello,

the three @supports rule variables in props.supports are unfortunately not very reliable.

We needed a js-free, solid Safari only detection, not accidently catching some Chromiums, and Safaris not seeing styles intended for Google Chrome -- which is what happens now.

The --firefoxONLY is the only one that works as advertised thanks to the -moz- prefix and Mozilla using their own enginge, Gecko [^1]

The --safariONLY also catches Chromium browsers (Linux) and "unbranded" WebKits (they're rare but used in e2e and headless browser test systems [^2]. This could make testing a bit more guesswork.)
It also catches older Google Chrome releases (no biggie thanks to its evergreenness).

The --chromeONLY also works for Safari.
I guess Chromium is ok as it's a tad closer to Google Chrome than "plain" WebKit.

Safer Alternatives

A safe --safariONLY would be -apple-pay-button-style: inherit which goes several versions back, and like -moz- for Mozilla, --apple- is an (old) Apple OS == Safari exclusive.

A safe --chromeONLY would be (-webkit-app-region: inherit). No false positive for Safari.
This a Chromium window element property.

So to eventually even get --webkitONLY or --chromiumONLY effectivly combine them with a not.

Check with https://noscriptfingerprint.com/ where I found both alternatives.

Enjoy.


For those who don't know: WebKit, Blink, Chromium, Chrome, Edge, and Safari share a lot of their code through the WebKit project. Some of these names are so called browser engines, some are browser apps people use on their devices.
Most notably: they are never on par with each other in terms of CSS features.
We usually want to test for the browser app people use, 'cos vendors add and remove features at will from the (shared) engines they use for all sorts of reasons.

[^1] based on Gecko does not mean it's a (recent) Firefox though. There's also Seamonkey, K-Meleon, Pale Moon, and Fennec for Android.
[^2] Playwright on Windows.

@argyleink
Copy link
Owner

nice, thank you, another great detail noticed. i remember testing these, but i'm surprised when reviewing that this was the chrome only option.

i'll make a test page and a PR (unless you're interested at a contribution? test page can be a super simple codepen and the pr is a small source change that is a sidecar file 😃

@WebMechanic
Copy link
Contributor Author

unless you're interested at a contribution?

ha ha, just realised I already forked this a while ago ... 🙄

I'll give it a go and try to cook sth up by tomorrow and the test page on codepen. I pick stuff from our current safari test page which goes back to SF13.
Should I try and add a --chromiumONLY? I can only make manual tests though, no browserstack et al.

a small source change that is a sidecar file

I don't see a .js for props.supports.css, so it'd be just the .css then, right?

we litteraly use copies of only a couple of src/props.*.css in our repo and I honestly never bothered looking at your build chain😇

@argyleink
Copy link
Owner

I'll give it a go and try to cook sth up by tomorrow

rad no rush! lookin forward to it tho

Should I try and add a --chromiumONLY?

that'd be great. renaming it to chromium is a great mvp change too.

so it'd be just the .css then, right?

yep, this file is a bit of an exception and isn't part of the main build chain. edit it directly 👍🏻

@WebMechanic
Copy link
Contributor Author

Test page and explainer https://codepen.io/WebMechanic/pen/poVexYp (see CSS comments)

The gist of updated and new rules. If you think some are too hacky, I'll drop them for the PR.

@custom-media --firefoxONLY  (-moz-appearance: inherit);
@custom-media --firefoxMacONLY  (-moz-osx-font-smoothing: inherit);
@custom-media --safariONLY   (-apple-pay-button-style: inherit);
@custom-media --chromeONLY   (-webkit-app-region: inherit) and (not (container-type: none));
@custom-media --chromiumONLY (-webkit-app-region: inherit) and (container-type: none);
@custom-media --webkitONLY   (alt: inherit) and (not (-apple-pay-button-style: inherit))

For Chromium (Linux 103) there's also an alternative not (selector(::highlight(fubar))) but this might not work being a selector() and could easily fail when ::highlight() is eventually implemented.

Styles from --chromeONLY bleed into --chromiumONLY (orange marker in test page) but not the other way around. Given they're virtually identical it probably won't matter anyway and one can always tweak the other one.

I added Firefox Mac 'cos font rendering differs from Safari and Chrome, esp. faux bold and italics.

container-type: none is a non-standard value, ignored in Chrome, read/parsed in Chromium.

Enjoy!


I presume Chrome, Edge, Opera, Vivaldi, Brave and alike will pick the same rules within a few weeks/months apart. Although Edge more often than not has a higher CSS test score than Chrome (🤷‍♂️ who'd had thunked?) I didn't bother to find an --edgeONLY. Regular feature testing should do for any of them.

I'm optimistic that each browser is on par with their other OS twins, despite Chrome for Windows was unable to perform any hyphenation until last year or so.

WebMechanic added a commit to WebMechanic/open-props that referenced this issue Sep 18, 2022
kelvindecosta pushed a commit to kelvindecosta/open-props that referenced this issue Nov 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants