The Unholy Trinity of Web Browsers: A Frontend Nightmare
Description
A classic two-part meme format. The top text reads, 'Therapist: Mozilla Chrome Explorer isn't real, it can't hurt you'. The bottom text simply says, 'Mozilla Chrome Explorer:'. Below this, there is a horrifying, cursed image of a hybrid web browser logo. The Mozilla Firefox fox is wrapped around the Google Chrome circular logo, which in turn is encircled by the golden swoosh of the old Internet Explorer logo. This meme humorously visualizes a web developer's worst nightmare: a single browser that combines the rendering engines, development tools, and historical baggage of Firefox (Gecko), Chrome (Blink), and the notoriously problematic Internet Explorer (Trident). For experienced developers, this isn't just a funny mashup; it represents the chaos of conflicting web standards, impossible-to-debug CSS quirks, and the painful memories of writing IE6-specific hacks, all rolled into one monstrous application
Comments
28Comment deleted
Its user agent string would just be 'Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36; I-am-pain/1.0'. And yes, `!important` would be ignored at random
Mozilla Chrome Explorer: the monster that spawns when the enterprise RFP says, “One codebase, but it must leverage Gecko’s privacy, Blink’s performance, and still run that Trident-only payroll app from 2004.”
After 15 years of writing -webkit-, -moz-, and -ms- prefixes, I've finally achieved enlightenment: the real browser compatibility issue was the friends we alienated along the way by insisting they upgrade from IE11
This meme perfectly captures the existential dread of every frontend developer who's ever had to support IE11 while explaining to stakeholders why 'just make it work in all browsers' isn't a trivial request. The fictional 'Mozilla Chrome Explorer' is somehow less cursed than the reality of maintaining separate CSS files for each rendering engine, writing polyfills for basic features, and discovering that your perfectly valid flexbox layout renders as a Picasso painting in older browsers. At least this chimera would theoretically consolidate our compatibility nightmares into one predictable horror show
The enterprise “single browser” strategy: Blink features, Gecko quirks, and Trident policies - supported only in Edge’s IE mode on Citrix with Autoprefixer and 500 KB of polyfills
Real enough to spike your BrowserStack bill and resurrect IE11 polyfills in prod
Pro tip: if your code still relies on UA sniffing, you’ll eventually support “Mozilla Chrome Explorer” - Edge’s IE mode on Chromium pretending to be Firefox
a- Comment deleted
😂😂😂 Comment deleted
The only code that works in it is code that properly runs in all 3 browsers Comment deleted
without usong browser-specific shit, right? Comment deleted
You can't use modern JS, but also not browser-specifc stuff, because that wouldn't work in all 3 browsers Comment deleted
that forces to create simple ans small web sites, so it would be good for everyone (except those who decided to put a lot of unneeded things that make website look "better") Comment deleted
Sounds awesome! Comment deleted
Biggest problem we face rn. Tho excellent websites can be made which are equally compatible on every modern browser, the developers choose the cheap way. Comment deleted
webdev with like 0.25 experience here - web browsers' implementation of the HTML and CSS standards are dogshit. Firefox comes the closest, but even there are some… spicy surpises sometimes. Comment deleted
that's why nobody wants to be a webdev and why everyone uses js instead of making a proper design with CSS and HTML - it's easier to make it compatible with every browser Comment deleted
But isn't most of it standard and browsers do follow most of it. I mean, there are a few differences now and then but on the whole. 😆 Make designs based on web standards and leave the rest to browsers. Comment deleted
mate the standard says that position:absolute should position the element relative to the nearest positioned parent. By default, and when position:static is applied, an element counts as non-positioned. Now, here's the problem: I don't fully know how the standard defines that, but if an element has a transformation applied to it, it also counts as a positioned element in this context. Chromium and Safari, and therefore more than 90% of the market, don't think so. Firefox handles this case correctly. That means, if you put a drop shadow (which is a transformation) onto an element, and put position:absolute on a child of it, the standard says that the child should be positioned relative to the element with the shadow, but chrome will just ignore that and position it relative to the root (most likely). Combine that with the fact that absolutely every soywebdev will just think "fucking css" and/or "fucking firefox" to themselves, and solve it in javascript instead, and you got a page that takes 5 seconds just to compile the code. 1/3 horror stories from the web Comment deleted
then the case of vertical-align in a flexbox. Flexboxes are designed to replace all the complicated old css alignment stuff and make it easy to …well, align things. Once you understand it, it's the best thing ever. Now, if you don't understand it, however, things can get weird. Picture this: a soywebdev wants to vertically center an icon within a horizontal flexbox. Well, let's see if vertical-align exists. Yes, it does. Great… okay, seems we need to vertical-align:super to get the icon centered there. *goes to test the website on firefox* Wtf, this isn't centered! Firefox sucks, let's just calculate the center position with javascript and positon it that way for the sake of compatiblity. I have no idea what the standard says, but vertical-align should just do nothing in flexboxes 🤦♂️ Both Firefox and Chrome try and fail horribly to use it within flexboxes, which creates conflicting styling (since both the flexbox and the element itself try to command its vertical placement) 2/3 shitbag dicknut stories Comment deleted
<div class="d-flex"> it all the way Comment deleted
and then the whitespace stuff… ugh. basically, web browsers like to handle whitespace between elements as a single space. Most of the time, when you use normal code formatting with inline elements, you basically have to<!-- -->to get a newline without a pixel of unexplained distance between elements. I believe this one is a remnant from the HTML1 days, when there wasn't much style and mostly just text, but daaamn boy, I'd really like to just have a CSS rule to disable that shit for the entire website. Doesn't work like that last time I checked though. Best way to avoid it rn is to set the font size to 0 globally (since that reduces the size of a space to 0 as well) and then setting the font size to whatever you want for where you need it, but that's hacky as fuck and I don't like it. 3/3 supersoystories Comment deleted
<br />: *exists* Comment deleted
that's not- Comment deleted
Imposibru Comment deleted
polifill Comment deleted
I'm never scared But there's one horrible thing thar I'm afraid of (internet explorer) Comment deleted
the_rapist Comment deleted