some "(to 79)" hacks still apply to Chrome/84

[WebMechanic]

Several "(to 79)" hacks apparently still apply in Chrome/84 Canary (Win10).

• Chrome 49+ (to 79)" : [browser="C49UP" i]
• Chrome 32+ (to 79) : _:not(*:root), _:unresolved, .selector
• Chrome 34+ (to 79) : _::-webkit-seamless-document, _:unresolved, :root .selector
• Chrome 45 (and Opera 32) : @supports (-webkit-tap-highlight-color:currentcolor) and (not (motion-path:path('M0,0'))) and (not (-ms-accelerator:true))
  probably Chrome 45+, Opera 32+

[browserstrangeness]

interesting, the ones i wrote 'to 79' aren't on version 80 (currently) on my machine...
I wish to see how the 'preview' releases end up when they are final. Sometimes they change (Some leave and come back later for example.)

[WebMechanic]

the ones i wrote 'to 79' aren't on version 80 (currently) on my machine...

oh, crap!!
I always have "Experimental features" enabled in Canary! I always forget about this.
I'll check without this and on Chrome/80 and come back.

[browserstrangeness]

ahh! that makes a lot of sense now :)

[WebMechanic]

maybe not so. Experiments are off, but:
The 79ers are red if I load the css_hack from disk, file://
They're gray if I load it via http://

[WebMechanic]

I don't have the whole repo on disk, so some of your basic css files fail to load.

[browserstrangeness]

Interesting note - these I will target with a web server only since that is what people use on web sites, but a difference is always good to be aware of.

[browserstrangeness]

Web sites would have SSL enabled - personal viewer may not, other differences would not be a surprise as well.

[WebMechanic]

I only had the html file as a sort of "reference" to scan. Anything that does a reset in an external file was missing.
But I found a bunch of "Chrome Only" styles that also apply to EdgeHTML.
Checked with the current version ... and via webserver :)

[WebMechanic]

I don't have SSL on my local Apache, so some of the Firefox bugs obviously don't apply.

[browserstrangeness]

Some of the newer browsers often pick up webkit additions, so it is always important to check where they changed. Sometimes a patch can be added to keep the diversity.

[WebMechanic]

Yep, glad they stopped doing that a while ago and resorted to config flags for their new stuff.

That -webkit- nonsense of Firefox was bugging me just recently (-webkit-appearance) and I picked up a hack from your list to split Chrome, EdgeHTML, and Firefox styles and eventually used two nested support rules.

---

If you do a console dump of i.e. document.body.style you can see their supported -webkit- properties, and in Edge[HTML] the (old) -ms- prefixed props. That's what I did/do at times to find a pair for @supports.
That's also my way of a quick browser-sniff in JS and dump some classes to the html or body elements.

msie = (ua.match("Trident/(\\d+)", "g")) && (body.style instanceof MSStyleCSSProperties);
edge = !!(window.chrome.app) && ('msHyphenateLimitChars' in document.body.style);

[browserstrangeness]

Nice tip, if anyone ever reads these other than just you and me that will help people get started.

[browserstrangeness]

Just for fun I did these for your javascripts...

https://browserstrangeness.bitbucket.io/msie_class_detector.html (MS Internet Explorer 9-11)

https://browserstrangeness.bitbucket.io/edge_class_detector.html (MS EdgeHTML, Not Chromium)

I love live tests :)

[WebMechanic]

Nice :) You're all over the place with this, aren't you?

The displayed code for MSIE lacks the document part and wouldn't work if copied.

The two lines were ripped and derived from a larger function that prepares a few vars and does more tests for all sort of brands and engines.
I'll prepare a Gist with the whole bit.

[browserstrangeness]

Ah you are right, the source works, I didn't realize I hadn't updated what is shown afterwards. Thanks!