There is a definition file on unicode spec about a character should be n half-width in monospacr context. Not sure if it includes all symbol though. Also don't know if it handles symbol that has more than 2 half-width
The point is they are not even compliment to their "own" spec. They are part of whatwg. But if you ever write web page. You will know it's always the safari that differs from the spec. Firefox in the other end never have such issue.
Write a page on chrome, works 90% on Firefox. But will likely works 10% on safari. Supports safari literally means support another browser (by workaround all its bugs).
> The point is they are not even compliment to their "own" spec. They are part of whatwg.
I think web devs have too much faith in the "standard"; the WHATWG specifies anything supported by two implementations, and with Google controlling Mozilla that already feels somewhat unfair...
> Write a page on chrome, works 90% on Firefox. But will likely works 10% on safari.
Disregarding the issue that you're writing pages that only 90% work on anything but Chrome... do you have any examples of Safari misbehaving?
The ios safari lies you about (or simply bugged out) video play event, display video element on play event will show a blank screen to user. This never happen in any other browser(including those china vendor browsers) except safari. To make this worse, you can't make a unloaded video element on safari to have transparent background so user will definitely see a black square unless you add a delay to mitigate the problem.(Most players already do it, but it's still a pain if you need to make one from scratch)
It's not even exaggerated, the ticket count about safari on my board is almost higher than sum of every other browser in total. I 100% just want this browser die if apple ever allow other browser on ios.
I mean that could be "two Safari tickets" for all we know, and you could be ignorantly chasing Chrome's ChromeOS un-standards or bleeding edge RFCs thinking a reference implementation or a mere memo should work everywhere. Personally, I almost never see Safari-specific bugs be reported and can't find one in my company's JIRA system in the last year. Are you sure you're not self-inflicting this pain?
Your desire for Safari to vanish is also historically short sighted. Ladybird has near-zero usage, Firefox is practically dead and is fully bought and paid for by Google, everything else is just a Chrome or Chromium fork. Safari is realistically the only thing holding back an outright Chrome monopoly with meaningful usage.
The safari literally broke border-radius of image whenever a opacity transition is triggered. It's the simplest effect you will see everyday. Or broke layer of position: fixed element when containing container is scrolled. They aren't even new features and exists since like 10 year ago? And it's still broken that requires specific workaround. Or on ios 26(the one just released). Every page that added to ios home screen is no longer able to play video at all if you close it and open it the second time. The list can go on infinitely if I ever want to dig up. When is the crap even usable? There isn't a way to not hit bugs at all unless your page is extremely barebone and require little interaction.
Besides these, the service worker debugger never work on my iphone device since like two major version ago.(It did not show up in the safari menu) There is no way to use it as a developer even I want to (let alone the devtool crashes and disconnects frequently)
Me as engineer: does apple even pass the bar by their own? I hit shit tons of safari only bug that is 100% non web-compliment. Some are so stupid that as a normal person writing web pages must have ran into it already.
The mindset that someone will buy a album because he have no idea about WTF it is and can not listen to it on the internet is really interesting to me.
Like, why would you even buy a album and add it to your collection if you have no idea what it is?
> someone will buy a album because he have no idea about WTF it is
Based on the advertising I see in Nashville's Music Row, I'm pretty sure that actually is their strategy. The signs they put out usually have only the artist name as meaningful information, which is only helpful if you're already a fan (I guess it does get their name into your brain otherwise), and a QR code. I have no idea who scans the QR codes.
Some people have told me it's really meant for other people in the music industry, but it feels odd that they'd have to find out about music by random signs on the side of the road.
I won't say most react apps performs like this. But it's what you will get if you ship a big react app without optimization at all.
Other framework mostly have a much saner default (for example, component without argument change does not re-render). So it will work well (not best though) even in large scale. But in react they are all opt-in.
I think the power efficiency of AMD graphics is improved by a lot in the past 10 years. If you compare Rx580 and Radeon 890m. They are 7 years apart, with almost the same performance, and 12X power usage difference (the new one is so low so it can be put into a mini pc and used as igpu). It's unimaginable if you said this 7 years ago.
You probably haven't see front-end projects that pulls tons of library for a simple sorting or grouping task. Sometimes even solvable with build-in array function alone. It's a true nightmare when you have to deal with that kind of projects.
What, like lodash? Some of those hail from a time that we didn't have a good set of native methods. So the library is just legacy'd in. But I do agree, lodash performance compared to native functions is crazy bad.
Is that the case? I saw a talk by the author of lodash years ago and he touched on performance. The built-in functions are (or were?) implemented in JS, level terrain for a library like lodash to beat "native" performance. Lodash beat browser built-ins in some cases. The talk was ten years ago, though, so things may have changed. Perhaps more of the built-ins are written in C++ now.
Ｉt's not really about the performance. It's about the readability. The performance don't even matter if you are just grouping dozens or hundreds items on the gui.
Abuse Lodash or Underscore everywhere means the code is not readable unless you know what is every used lodash function intended to do. Combing with weak type and undocumented business logic (and api types), it's a true nightmare experience to work with.
It's probably irrelevant in a personal project. But it's a headache if you are collaborating.
Sometimes it got even worse that original user don't know the exact specification of the utility function either. And the code works just by pure luck. (something like, the method work if all keys are numeric) It will give you a hard time to troubleshoot the problem if it happens.
That's exact why I reply this though (or probably I should reply to your parent comment?). The place these get used are mostly performance insensitive location, it don't really do anything except ruins the readability. And the project is not that old either(It's a past es6-era project), I don't really get why it is used at all.
I'm not a lodash stalwart or anything, but years ago when I used it heavily, it made navigating and manipulating large/complex/irregular objects much easier. It's LINQ for JavaScript. And it was very readable and consistent, since most functions in lodash have the same signature.
> "this behaviour is as seen in Word 95", "this behaviour is as seen in Word 97"
The office relies on behaviour in windows itself "a lot". Even office mac or office web they made themselves isn't a 1:1 replica of the office on windows.
Let alone describe it as a standard.
"this behaviour is as seen in Word 95" sounds sloppy, but it is indeed the closest they can get.
Or what else can you do? You can't just also ship a installation media of word 95 and windows into the ISO standard, right?
> You can't just also ship a installation media of word 95 and windows into the ISO standard, right?
That's what they almost literally did. The spec is littered with "behavior of this program that has no specification and to see it you need to install it and run it"
And that's on top of re-inventing a bunch of specs in MS-only and MS-specific manner (like dates, for example)
https://www.unicode.org/reports/tr11/
reply