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!

[browserstrangeness]

The display also needed to show navigator.userAgent.match instead of ua.match (fixed all that in the displayed text now.)

[browserstrangeness]

I tested both earlier so the source does work properly (it highlights in red as it is supposed to.)

[WebMechanic]

Yes, the code itself was correct.

The original function starts with some shortcuts including:

let body  = document.body, ua = navigator.userAgent, 
    edge  = ('msHyphenateLimitChars' in body.style), 
    CSSOM = ('CSS' in window);

There are other simple flags that are then combined with some cherry-picked tests based on CSSOM.supports(), ('someProp' in SomeInterface) or ('SomeInterface' in window):

flex   = CSSOM && CSS.supports("display", "flex");
msflex = CSSOM && CSS.supports("display", "-ms-flexbox");
gecko  = ff && ("originalTarget" in Event.prototype);

(it's actually all wrapped inside an object, not single variables) This is neither bullet proof nor do these checks cover the whole range of browsers, but the features I am interested at for a particular project.

So (edge && msflex) would likely be Edge 12-15, although that "detail" is irrelevant. Also edge by itself would be true for IE11-, but not if combined like (!!window.chrome && edge).

Like Modernizr I then add class names and data attributes based on the findings. Later in the CSS I can do stuff like this:

main {display:flex}
.msflex main {display:-ms-flex}

[WebMechanic]

I managed to compile a collection of various feature tests into this gist

• https://gist.github.com/WebMechanic/6f05fbc688d055c89bd1b0d0db32ff15 It's a simplified approach to Modernizr and definitely much smaller.

I usually use a stripped down version of this with the features I need.

The supplemental flags for "Old Edge on iOS and Android" are hypothetical: I never saw any of them and I never met a single person using them either. And for Edge 12 and 14 there's a comment on how to detect them. I don't bother so there's no active test or property for them.

You might want to check this bit in real Safari. It needs the DOM to write the class names.

Enjoy.