5 ms·
I share your opinion, but recently got very disappointed to find out that safari still needs lots of -webkit- prefixes; even for stuff seemingly available for a
by 9dev 4y ago
I share your opinion, but recently got very disappointed to find out that safari still needs lots of -webkit- prefixes; even for stuff seemingly available for ages now. So we’re not fully out of the pit yet, at least until the most valuable company in the world finally cares to fix their fucking browser (yes, dear Apple engineer, I’m talking to you!)
- _hyn3 4y agoApple's app monopoly gets stronger when the browser gets weaker.
- CharlesW 4y ago> recently got very disappointed to find out that safari still needs lots of -webkit- prefixes; even for stuff seemingly available for ages now. Safari is fairly conservative in de-prefixing new features, but also sometimes beats Firefox (e.g. Container Queries and Container Query Units). For reference, here's the caniuse.com list of Safari CSS features which need prefixing, compared to Firefox: https://caniuse.com/?compare=safari+16.1,firefox+107,ios_saf+16.1&compareCats=CSS https://caniuse.com/?compare=safari+16.1,firefox+107,ios_saf...
- easrng 4y agoIt feels kinda weird but a lot of the time you can just use the -webkit- prefixed versions and they'll work in firefox too.
- zerocrates 4y agoFirefox added support for -webkit prefixes several years ago now... I think mostly to capture things written for mobile Safari but also Chrome I imagine. I don't know if anybody really does other directions of that, though. There was probably no percentage in working with -moz prefixes for other browsers by the time this became an idea to do.
- hajile 4y agoIt's like user agent strings. Developers didn't fix their user agents, so other browsers just lied about what they were so the website would run properly. Only now they were stuck with the lie as long as devs depended on the user agent string for stuff leading to abominations like this one from Chrome on Android where it basically claims to be every single browser out there. Mozilla/5.0 (Linux; Android 12; Pixel 6 Build/SD1A.210817.023; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/94.0.4606.71 Mobile Safari/537.36 Devs were NOT supposed to use prefixes in production, but they did anyway (best viewed in Chrome). Unfortunately they then proceeded to NEVER UPDATE these as other browsers added support. Non-webkit browsers had the choice of interpreting the CSS or leaving their users with a broken experience. Major browsers moved away from vendor prefixes between 2012 and 2016 (when webkit finally stopped), but it was too late. Browsers 50 years from now will still be supporting this garbage because of what devs did. The key takeaway: Never give devs a tool you don't want to be stuck with forever. Also, can we please not do this yet again in the future?
- kibibu 4y ago> Never give devs a tool you don't want to be stuck with forever. That's right. You can pry the <layer> element out of my cold, dead, hands.
- robertoandred 4y agoPrefixes for what?
- piskerpan 4y agoI don’t know what you’re using but most developers most likely don’t need “lots of -webkit- prefixes”. In the link posted by the sibling commenter, I see 2-3 properties that could be useful to the general public. The rest is esoteric, never-ratified, or straight up user hostile (font-smooth)