Blink, EdgeHTML, Gecko, Presto, WebKit

[WebMechanic]

I propose to include an introductory section to "index.html" that includes an overview of rendering engines and what browser is/was using them on the various platforms. Wikipedia has an article about render engines to find further information.

Such a list would also clarify that hacks and filters would also apply to a whole bunch of other (more or less) common/current browsers i.e.

• Opera (Blink), previously Presto
• Opera Mini (varies on OS, WebView or WebKit; rendering server side)
• Vivaldi (Blink) [the former Opera crew started with something of their own but also gave in]
• Samsung Internet (Blink), WebView on Android 4.x maybe longer
• Android WebView (WebKit)
• iOS WebView (WebKit)
• Firefox (Gecko, WebKit on iOS)
• Edge (EdgeHTML on Windows, WebView on Android, WebKit on iOS)
• Edgium (Blink)
• Chrome (Blink), previously WebKit
• Explorer (Trident 3-7)

In order to distinguish old Edge 12-18 on Windows(!) from whatever Edge became today, I'd suggest to clarify that those hacks only apply to what was once known as "EdgeHTML". And also include a note that previous Edge on Android or iOS was not using EdgeHTML at all = none of the hacks and filters would apply.

Nokia and Blackberry phone used to run Windows = mostly Trident, now it's Android and WebView. Several Adobe apps pre CS6 used Presto as a rendering engine, despite the company was/is working on the WebKit team.

IIRC "WebView" is some lagging-behind WebKit derivative used inside Android apps to display any sorts of web content, so all those apps are affected by WebKit CSS hacks - and who knows what WebView version is used on which version of Android.... This includes the "old Edge" running on Android (EdgA).

Likewise everything that wants to render web content on iOS must use Safari's WebKit engine, incl. Firefox on iOS and old Edge (EdgiOS) + a few proprietary tweaks.

Google and Firefox constantly "unship" and "unprefix" some of the previously supported -webkit- properties - which is probably the primary reason why some hacks no longer work in later versions and not because something was "fixed".

Like Mozilla, Microsoft also added some -webkit- aliases into MSIE11 for features they supported.

Google Chrome no longer uses WebKit but Blink and LayoutNG. -webkit- props and values still work for BC reasons. More recent -webkit- stuff now only applies to Safari. All browsers moved to some sort of "enable experimental features" instead and Firefox uses a buttload but more granular set of layout.css.' settings via about:config.

Edge is no longer "the" Edge on Windows when it was built on Trident's successor EdgeHTML (12-18) but virtually became the same as Chrome (79+r). So any hack and filter that aims to target or exclude "Chrome" will inadvertently (or not) also target Edge/79+ aka "Edgium" and the whole gang listed above. Microsoft will likely introduce some Windows specific extensions to Chromium and Blink, that might first appear in Edgium and then selectively come to other Blink browsers for Windows incl. Chrome, Opera and Vivaldi. Unfortunately this is not necessarily true for all features, because vendors can still choose (and have chosen not to) to include a new CSS or JS feature into their builds, i.e. those invented by Google to support their business.

Maybe in the future Blink will split again into discrete engines like WebKit once did, when it became dominated by Apple's agenda.

[browserstrangeness]

Guessing you didn't see it yet, but I already did change my browsertrangeness site to reference EdgeHTML on that section a few days ago. I made a few slight notes about it vs/ Chromium Edge too there. Will read more of this post of yours when I get a chance.

[browserstrangeness]

I just did this to get both versions of Edge side-by-side: https://docs.microsoft.com/en-us/deployedge/microsoft-edge-sysupdate-access-old-edge

Because I had already upgraded the machine, I reinstalled the stable version using the 'after you already upgraded to chromium' method.

[WebMechanic]

I already did change my browsertrangeness site

I was only looking at a local copy of the index.html source in VSCode here so I didn't catch your EdgeHTML updates. Good job!

That blocker is the tool / method I had in mind when I mentioned IT departments can block IE/Edge updates (or other potentially BC breaking system updates). There were similar tools / registry settings before to prevent IE7 from replacing IE6 etc.

I was actually unaware of MS also providing Dev and Canary build for Edgium. I had Canary installed only for a few weeks side-by-side "legacy Edge" when I learned about this blocker on their Insiders site and instantly applied it. Hope it sticks! :) I don't need any flavour of Edge other than to do some final touch up testing, so Edge/18 "legacy" and Edg/Canary are sufficient. Like Chrome Canary or Firefox Nightly they all give me a little heads up of changes that might be useful; e.g. last year's belated WebP support in Firefox.

Another "unintentional" source to find CSS filters and bridges to use with media and|or supports is Lea Verou's https://css3test.com It's like the practical application of CanIUse "at a glance".

Just check for orange and red bars and drill down a set to see what's behind. Sometimes only single (exotic) values are unsupported by a render engine or vendor. Then head over to caniuse and often you can tell who came up with it (i.e. Apple) by having the only green bar and --as a consequence--learn who'll probably not implement it ;-)

[browserstrangeness]

Ever try downloading open source code like Firefox or Chromium? Scanning those for CSS to use also works. It is a lot more time intensive of course.

[WebMechanic]

Nope. All I ever downloaded (and collected for some time) are their "html.css" defaults just to learn what I (don't) need to reset. For IE this was/is burried in some .dll though.

[WebMechanic]

Did you knew about that? https://caniuse.com/#feat=css-descendant-gtgt If you care for (another) Safari 11-only hack.

I wonder if @supports selector(...) (once it's more widely supported) will always give the same result as a regular selector hack or open doors to a new generation of hacks, where the actual syntax can be shortened similar to some @supports ( bla:some-func("") ) statements.

[browserstrangeness]

I love targeted ones like that. Will play with it.

As far as the @supports selector method, for hacks it may not be all that needed, but I love having the option. For CSS itself, that really does give many more options for development.

[browserstrangeness]

The possibilities are truly exciting for devs and hacks both.

[WebMechanic]

Just found this note on caniuse:

iOS Safari 10 and 11, and Safari 11 renders display:contents as display:inline. @supports will also report as true.

Read: @supports does not mean the feature being tested is implemented as it should :) If the tested feature isn't actualy applied inside the block, this might not be an issue. In particular if sth. like "supports(--foo:bar)" might actually stand for "if ( !MSIE )".

I mean if you have a truly hackish selector like one of the old underscore hacks, you could wrap a bunch of style tweaks inside a single @supports selector( _::-webkit-thing) instead of constantly adding the hack as a preamble. That's for new such hacks starting with Firefox/70 or Chrome/83 of course :D

[browserstrangeness]

You are on a roll :)

[browserstrangeness]

At the very least, since they are supported on the major non-safari browsers, that means at least people who keep updated can generally use the supports selectors.

[browserstrangeness]

Meaning - it already has hack potential meaning that firefox having put things behind a flag gives it targetable status already.

[browserstrangeness]

(Firefox for android has it flagged.)

[browserstrangeness]

The https://developer.mozilla.org/en-US/docs/Web/CSS/@supports page (at the bottom) shows even Edge and Chrome showing up in a few versions if the non-release versions keep to the projected stats.

[browserstrangeness]

Okay since you posted a few of these, I made these two as tests combining this and one of your other postings;

@supports selector(_:-webkit-full-screen) { .selector { } } / Chrome(Dev)83 / / Source Combination: WebMechanic & Jeff Clayton /

@supports selector(:-webkit-full-screen) { .selector { } } / Chrome(Dev)83 / / Source Combination: WebMechanic & Jeff Clayton /

Chrome and Chromium (developer version 83) both support them. The old version of Safari from High Sierra may be a match as well. That would be the '.0' version, not the '.1' version. BrowserStack has the latest (.1) update only, so for now it just needs that additional test to be exact.

If Chrome/EdgeChromium keep them then there you are. I don't tend to post things as final until they get their final release though.

[browserstrangeness]

I just figured out a really simple Safari 9+ one-liner this evening.

_:not(a,b), .selector { property:value; } / Safari 9.0+ /

It sort of caught me by surprise while looking through moz docs.

[WebMechanic]

I guess the underscore family of hacks is a constant for WebKit :)

So in Canary builds +83 selector() is finally enabled by default; just checked. FF Android will follow suit in a couple of weeks when v69 will finally ship. Nightly already works. There are various CSS or JS features unflagged in FF Desktop that take a few month to trickle down to Android which lags behind by 6-7 versions.

[WebMechanic]

IIRC from some blog post, WebKit is somehow working on selector() but there seems no target TP on the horizon. Which is sad, 'cos Safari 9 (2015) already added support for the "of selector syntax" from Level 4 in :nth-[last-]child() or lists in :not(b,i,a,s) but you can't safely test for it to build a workaround. This should be given priority 'cos implementing advanced L4 selectors but not be given the tools to test for them (in CSS) is counter productive.

[browserstrangeness]

So then happy Easter weekend! I thought you might like that. :)

[WebMechanic]

Thanks, Happy Easter to you, too. Not sure you actually need the _ in front of :not( selector list ). It's officialy in Level 4 and may eventually come to other browsers.

[browserstrangeness]

Everything changes I am sure given enough time.

[browserstrangeness]

Did you knew about that? https://caniuse.com/#feat=css-descendant-gtgt If you care for (another) Safari 11-only hack.

I have played around with it, and found this to work:

    html >> * .safari_11_only
    {
        color:#f00;
    }

    <div class="safari_11_only">Safari 11.0 (Only) '>>' Combinator Hack</div>

This does not work in 11.1. It just singles out 11.0.

[browserstrangeness]

Added it to the test page

[WebMechanic]

Nice. Will pull the repo :)

This does not work in 11.1. It just singles out 11.0.

so caniuse is right then? :-)

As I understand this bizarre selector a simple (practical) variation such as ul >> li {} would also restyle the list items in SF 11.0 only, right?

Maybe that's one way doing it or this is just a requirement for your test page to deal with all the other class names and style rules. It just seems weired to me to explicitly add a class such as "safari_11_only" to any element (or a larger list) to fix an issue. Skinning cats...

[WebMechanic]

I just dump this in here.

Most -webkit- prefixed properties also work with an -apple- prefix.

Maybe this allows to fine-tune / simplify -webkit- hacks that ought to match Safari and incidently also match others that shouldn't.

Found on MDN:

[browserstrangeness]

Nice. Will pull the repo :)

This does not work in 11.1. It just singles out 11.0.

so caniuse is right then? :-)

As I understand this bizarre selector a simple (practical) variation such as ul >> li {} would also restyle the list items in SF 11.0 only, right?

This is what should happen yes.

Maybe that's one way doing it or this is just a requirement for your test page to deal with all the other class names and style rules. It just seems weired to me to explicitly add a class such as "safari_11_only" to any element (or a larger list) to fix an issue. Skinning cats...

There were 2 thoughts actually. One led to the other. The first being that I was working on a web project and ONLY in one version of Safari the CSS was failing. It was on an expensive business site at a company I was working for and there was not a way to rewrite the source in a reasonable timeframe, but finding a way to patch it in that version of Safari would have solved the problem quickly. The best plan is to use the time gained to work on the core code and find a better solution.

The second idea was based on the first... if it is possible that one version of Safari (or more often Internet Explorer) has issues with CSS in a site, it is needed to find bandaid fixes -- and know exactly which versions the fixes target.

Anyway that's why I find it important to target 1) a browser version and lower, 2) a browser version and higher, or 3) a specific browser version. All of those are important in a place where things do not always fit the specs.

...that and I hate to have a blank in the middle of a form that is not filled out ;)

[browserstrangeness]

And the simple answer to adding a class is this -- adding a class usually is often more easily possible with a javascript solution. While that is available, the trick here is to attempt to do it purely in CSS. Sometimes that is not possible without an external option like a script. There is nothing wrong with that option, and can be a terrific solution. I am thinking of modernizr and other options that do that.

[browserstrangeness]

The other part of your question regarding fixing patches all over the site can occur, of course. The situation I am referring to was actually not one of those. It was a single spot with a needed patch. Nothing else in the site was screwing up.

[browserstrangeness]

In this case CanIUse was correct. Some hacks work on versions where they are unintended. That is the nature of a real hack (usable undocumented bug/oddity) that has unforeseen issues.

[browserstrangeness]

What I hope that can be gained from all if this goes back to the simplest point - it is not a good plan to use a hack as a permanent solution. If they are used, they are really only duct tape to fix a problem until one can find out the cause and repair it... thus removing the hack... and hopefully before the hack itself gets patched/removed/modified, like in the ones that previously affected only chrome and safari.