Opera 12 @media(view-mode)

[WebMechanic]

From my personal collection:
view-mode describes the mode in which the Web application is being shown:

• windowed | floating | fullscreen | maximized | minimized

Opera (Presto) was the only browser to ever implement this back in 2011 as a media query. It was obsoleted by W3C in 2018 and revived as display-mode in browsers as part of the Web App manifest (presumably also valid for browser web extensions) incl. OP34+ (Blink).

• https://www.w3.org/TR/view-mode/
• https://www.w3.org/TR/2011/PR-view-mode-20110811/

@media (view-mode:windowed)   {}
@media (view-mode:fullscreen) {}
@media (view-mode:maximized)  {}

Other alternatives to actually use the feature are :fullscreen, :-webkit-full-screen and :-ms-fullscreen CSS pseudo-class.
To turn them into a filter however would require the long awaited @supports selector() which currently only ships in FF/70+. Announced to come in CH/83+ (now Canary) followed by other Blink browsers as Edgium/83, Opera/70+ and Vivaldi.

[browserstrangeness]

Back when people needed an ie11 specific one, this combination I came up with worked well:

_:-ms-fullscreen, :root .selector { property:value; }

I have to say, nice job with the detail on your posts.

[WebMechanic]

Thank you.

I actually don't care so much about all these granular "hacks" to trick parsers but try to use simple @media filters and now @support to test a feature I either actually need or that serves as a wrapper for a whole set of settings.

My dislike for hacks is that almost any IDE and editor I used over the decades sooner or later chokes on their (rightfully "wrong") syntax, the highlighting goes down the drain, and the files are cluttered with distracting error markers.
That's another reason why I eventually group them into separate files and find a mechanism to make a browser load "theirs" as a final do-over with as little cross contamination as possible. I don't use preprocessors or prefixers; they emmit too much polution and even the simplest of CSS files explodes in size.

In many projects I used to have a trident.css ever since IE5.5 that later included fixes for IE6 and beyond. Gecko had a few quirks too, so it got fed its gecko.css etc.
Now trident.css (if I need one) only deals with IE11 and covers some "Edge-cases" using @supports.

[browserstrangeness]

You are most welcome!

As far as the hack I chose for that one, there seemed to be no other 'ie11 only' hack at the time, maybe still? Most of the ones that do it also do other IE versions (often ie10) but some even do EdgeHTML.

Well that and inline hacks are just fun!

I always prefer a media query (or @supports feature query) if I can help it, but sometimes a combination of those and such single-line mini hacks are required to do a successful target of one specific browser or a group of them. The idea isn't to do one or the other, it is to attempt to do only CSS to get the job done -- if at all possible. Separation of versions can be a seriously time consuming task to say the least. I am sure you know of course.

[browserstrangeness]

I have used external style sheets loaded by hacks too, those are interesting in their own way. Different purpose and reasoning but it is either a bunch of style sheets to organize or a bunch of hacks in a single document. The former is more of a 'patch it' method obviously.

[browserstrangeness]

You are right about ide and other tool kits. For many hacks, I do find it important to tell people that whatever tools they use, one must apply the odd code after the interpreter or compiler are completed. Otherwise they remove or damage the hack so it just can't work properly.

[browserstrangeness]

Almost forgot this one for Safari 7.1+ that was of the same ilk:

_::-webkit-full-page-media, _:future, :root .selector { property:value; }

Again this was one that targets a decent superset of versions. It took me forever to find something to do it until the full page stuff showed up.

[browserstrangeness]

That's actually why I started all this years back by the way - no real specific Safari hacks were in existence, and the documentation of which versions of which browsers were targeted never seemed to be adequate.

[browserstrangeness]

Here is the excerpt I use on one of my stackoverflow postings regarding the type of issue you brought up. It is really the culmination of responses to feedback I have received over the years:

NOTE: Filters and compilers (such as the SASS engine) expect standard 'cross-browser' code -- NOT CSS hacks like these which means they will rewrite, destroy or remove the hacks since that is not what hacks do. This is non-standard code that has been painstakingly crafted to target single browser versions only and cannot work if they are altered. If you wish to use it with those, you must load your chosen CSS hack AFTER any filter or compiler. This may seem like a given but there has been a lot of confusion among people who do not realize that they are undoing a hack by running it through such software which was not designed for this purpose.

[browserstrangeness]

The blurb came from my Safari hack list there, which is mostly comprised of code that will do just that - choke IDE toolkits, etc...