[HN Gopher] Safari releases are development hell
___________________________________________________________________
Safari releases are development hell
Author : AshleysBrain
Score : 276 points
Date : 2023-04-03 11:10 UTC (11 hours ago)
(HTM) web link (www.construct.net)
(TXT) w3m dump (www.construct.net)
| coldtea wrote:
| We should have static builds and mostly static environments (libs
| etc).
|
| The "evergreen" madness must stop for platforms that are app
| delivery targets.
|
| Or do it like Java does it...
| davbryn wrote:
| Other than the CompressionStream API bug, the rest of these could
| have been avoided by a) not relying on a supported 3D Offscreen
| Canvas and b) having unit tests so you aren't running prod
| against a Chromium bug.
|
| I understand the stress, but why do they think their product
| deserves more of Apple's attention than Safari's own product team
| who undoubtably are working to hard deadlines?
|
| This felt like a really, really long whine because they didn't
| account for certain issues, and I found the 'Apple employee'
| references to be a little crass
| AshleysBrain wrote:
| Sure, mistakes happen, and sometimes it's our fault. But the
| point is Apple's policies turn what would normally be a routine
| bug fix in to a total nightmare.
| tokamak-teapot wrote:
| The suggestions as to what Apple could do to help are all
| great, but it does look (from here) like there could be ways
| to tweak application development process to better shield
| against breakage.
|
| It might seem like I'm stating the obvious, but I really do
| think it could be worth spending time with the preview
| releases.
|
| I assume the reason this isn't done is as pointed to in the
| article - a lack of correlation between what goes into a
| preview release and what ends up in a real release, but is it
| really the case that none of the three issues raised could
| have been avoided if they had been spotted slightly earlier?
|
| The first looks like it was a case of over reliance on what
| was communicated by Apple. "Trust but have a backup plan"
| would seem like a useful approach here, if it is reasonable
| to consider the option of enlisting or creating a compatible
| replacement for using the Javascript zip library.
|
| The second issue - reliance on a bug - just seems like
| something that is easy to fall foul of, but in retrospect
| would it have been possible to have noticed that there was an
| assumption being made, or that there might be a test missing
| to catch a future change in behaviour?
|
| The third sounds like an assumption in the application code
| (that a value would not be null) which may have been a
| perfectly fine thing to do, if it was going to be obvious
| what the issue was as soon as it broke, but...
|
| ... the description of the pain of having to put out an
| 'emergency' release gives the impression that there is scope
| for making this process easier. I understand, of course, that
| automated testing of anything that runs in a browser is still
| hard, so it may be that it's this part of the release process
| that causes friction and the returns from improving this have
| already diminished as it's been refined.
|
| It's such a great product and I hope there can be less
| friction in keeping up with Safari as it's fantastic to see
| cross platform web applications continuing to thrive.
| sunaurus wrote:
| I switched to a Safari-first approach for web development a while
| back and it has reduced my pain considerably. In fact I use it as
| my main daily driver browser in general now.
|
| I've yet to run into a single case of some code running well on
| Safari but breaking on other major browsers, so by ensuring my
| code is compatible with Safari, I'm basically guaranteeing full
| compatibility with everything.
| folkrav wrote:
| Anecdotally, about half the frontend bugs that I see go through
| our JIRA at work seem Safari/iOS specific lol
| coldtea wrote:
| Seeing that Safari/mac/iOS and Chrome/blink (so also
| Edge/Opera) are the only game in town adoption wise (FF has
| fallen way below), how else would it be?
| recursive wrote:
| Those that aren't browser specific, unless this is some
| kind of trick question.
| coldtea wrote:
| I don't think the parent refers to/includes non-browser
| based bugs...
| recursive wrote:
| When I said "browser specific", I meant "referring to a
| specific browser", not "relating to browsers".
| coldtea wrote:
| Yeah, I got what you meant.
|
| Probably didn't word my answer well: by "Non-browser
| based bugs" I mean bugs caused by the code of the webpage
| having logic issues/bugs (as opposed to bugs caused by
| browser JS issues or CSS/HTML implementation
| incompatibilities and such). Perhaps "browser-engine-
| related" would be a better term
|
| So, I read the parent comment as referring to browser-
| engine-related bugs - things caused by a browser engine
| behaving differently, not implemented, etc, and not
| including in his numbers regular webpage bugs due to
| html/js programmer error.
| recursive wrote:
| If there's a logic error in the visibility of a button, I
| would classify that as a "frontend bug".
| jalk wrote:
| And about the other half is for chrome, and the rest is for
| all other browsers or what?
| bzzzt wrote:
| Probably because all the frontend people are using Chrome, so
| those bugs were already fixed.
| simondotau wrote:
| It's ironic that the people who hate dealing with Safari
| are, though they would never admit it, actually complaining
| because they resent having to test in more than one
| browser.
|
| Let's just throw in the towel now and rename the web to the
| Chrome Platform.
| creeble wrote:
| Or resent having to pay Apple to test in their browser.
| [deleted]
| selectodude wrote:
| Good news! Microsoft makes a Webkit browser that's up to
| date with Safari's webkit version.
|
| https://github.com/microsoft/playwright
| fHr wrote:
| 2023 state of frontend testing still scares me
| [deleted]
| folkrav wrote:
| Whenever I look at the frontend QA loop vs. the backend at
| the places I've worked at, I'm glad I work in machine
| readable, typed, easier to test API land.
| capableweb wrote:
| That would be a helpful process for more people to maybe look
| into, if it wasn't for the fact that most computers can't even
| run Safari, as it's not available on their platform, less than
| 10% worldwide who browse the web are using macOS.
| coldtea wrote:
| A hella lot more are using iOS though.
| capableweb wrote:
| Sure, but what's your suggestion? Load http://192.168.2.24
| on your iPhone while you develop on your Windows machine?
| Seems unlikely this is a better workflow.
| mouzogu wrote:
| > "so by ensuring my code is compatible with Safari, I'm
| basically guaranteeing full compatibility with everything."
|
| Ah the sweet nectar of naivety. Godspeed to you.
|
| Can't believe I've been a webdev 15 years. What's old becomes
| new, except for me that is....
| rimliu wrote:
| And I have been for 25 years. Looks you still have some
| learning to do.
| coldtea wrote:
| Well, I've been a webdev for more, and he sounds prudent, not
| naive.
| illiarian wrote:
| "Back fifteen years ago IE held back the web because web
| developers had to cater to its outdated technology stack.
| "Best viewed with IE" and all that. But do you ever see a
| "Best viewed with Safari" notice? No, you don't. Another
| browser takes that special place in web developers' hearts
| and minds."
|
| https://www.quirksmode.org/blog/archives/2021/08/breaking_th.
| ..
| bioemerl wrote:
| "the new IE" can mean two different things.
|
| 1. IE6, a titanic that that wants to harm the web so they
| can push their own ecosystem instead.
|
| 2. IE11, the incompetent and rarely updated browser that
| you have to support because a segment of your userbase is
| stuck with it.
|
| This article tries to argue 1 isn't the case, but I have to
| disagree. Safari isn't as large as IE6, but it regardless
| tries to fill the same role. Ensuring apple gets their app
| store cut.
|
| 2 is also the case, but that needs less argument.
| illiarian wrote:
| > IE6, a titanic that that wants to harm the web so they
| can push their own ecosystem instead.
|
| What a retcon.
|
| > This article tries to argue 1 isn't the case, but I
| have to disagree. Safari isn't as large as IE6, but it
| regardless tries to fill the same role.
|
| Of course it doesn't
|
| > 2 is also the case, but that needs less argument.
|
| It needs as much argument, if not more.
| bioemerl wrote:
| How is that a retcon? I believe Microsoft and IEs
| stagnation was to keep people using Microsoft software
| instead of the web.
|
| The primary reason for chrome being developed in the
| first place was to push the web into a place that stuff
| like Google maps, docs, and so on could exist at all.
|
| > It needs as much argument, if not more.
|
| Read this thread where people talk about their
| experiences developing for safari. Read any open source
| web libraries issue list. It will be immidiately apparent
| that safari is the odd man out who constantly has to be
| baby sat in order to work properly.
|
| The reason I said it needs less argument is that I
| assumed it would be immidiately apparent. Most people who
| do web dev come away with this impression.
| illiarian wrote:
| > The primary reason for chrome being developed in the
| first place was to push the web into a place that stuff
| like Google maps, docs, and so on could exist at all.
|
| Retcon again.
|
| > Read this thread where people talk about their
| experiences developing for safari. Read any open source
| web libraries issue list. It will be immidiately apparent
| that safari is the odd man out who constantly has to be
| baby sat in order to work properly.
|
| And then when you _actually_ read what people are saying,
| it turns out they only develop on Chrome, couldn 't be
| arsed to develop for or test on other browsers, and want
| Chrome-only non-standards delivered yesterday to every
| browser.
|
| To quote again, "But do you ever see a "Best viewed with
| Safari" notice? No, you don't. Another browser takes that
| special place in web developers' hearts and minds."
|
| > The reason I said it needs less argument is that I
| assumed it would be immidiately apparent. Most people who
| do web dev come away with this impression.
|
| I do web dev, and it is definitely not immediately
| apparent.
| bioemerl wrote:
| > Retcon again
|
| After IE6 achieved it's goal of destroying the
| competition, Microsoft literally disbanded the
| development team. Why would they do that for a very
| successful product? Because the web didn't have
| potential?
|
| Firefox started innovation back again a bit, but it took
| chrome and Google's want to applicationize the web to
| really kick us into gear.
|
| https://www.androidauthority.com/google-chrome-
| history-10256...
|
| > A few days before Google Chrome launched, Google
| released a blog post titled "A fresh take on the
| browser." The post explained that they were releasing
| this new browser because they believed they could "add
| value for users and, at the same time, help drive
| innovation on the web."
|
| > Third, Google saw Chrome as more than just a browser by
| developing it with rich, interactive web applications in
| mind. Lastly, it offered tab "sandboxing," which kept the
| entire browser from crashing when one website crashed.
|
| ...
|
| > And then when you actually read what people are saying,
| it turns out they only develop on Chrome, couldn't be
| arsed to develop for or test on other browser
|
| I develop for Firefox. Chrome basically always works fine
| with my pages. Safari chokes on all of them.
|
| And if you want to test Safari? You literally have to buy
| a dedicated piece of hardware for it. You wonder why it
| isn't tested?
|
| So here's a browser that fails to just work, even when
| you primarily use Firefox to build the page.
|
| You have to buy extra hardware to test on it.
|
| And you blame the developer?
| illiarian wrote:
| > A few days before Google Chrome launched, Google
| released a blog post titled "A fresh take on the
| browser." The post explained that they were releasing
| this new browser because they believed they could "add
| value for users and, at the same time, help drive
| innovation on the web."
|
| What Google says, and what Google does are two very
| different non-intersecting things.
|
| Edit: Google's maps and docs etc. ran just fine in
| WebKit. What Google wanted was _control_. What they did
| with that control we all know. For example, sabotaged
| Firefox:
| https://twitter.com/johnath/status/1116871237240852480
|
| > I develop for Firefox. Chrome basically always works
| fine with my pages. Safari chokes on all of them.
|
| Doubt.
|
| > So here's a browser that fails to just work, even when
| you primarily use Firefox to build the page.
|
| Funnily how I've used Safari as my primary browser since
| 2007, and I've been a web developer for far longer than
| that... and I haven't run into these issues everyone on
| HN pretends to have.
|
| > And you blame the developer?
|
| Yes, yes I do. Always. Even in the days of IE6 the
| problem was always with the developer.
| recursive wrote:
| > > I develop for Firefox. Chrome basically always works
| fine with my pages. Safari chokes on all of them.
|
| > Doubt.
|
| For what it's worth, my development profile is similar. I
| would say that Safari works _most_ of the time, but I get
| browser-specific failures from it at a noticeably higher
| rate than Chrome-derivatives.
|
| One memorable one, if you're curious, was triggered
| because of a minification step. Terser[0] has a special
| argument `--safari10` to emit code that's supported by
| Safari. I discovered this argument after running into the
| bug.
|
| [0]: https://github.com/terser/terser
| illiarian wrote:
| > Terser[0] has a special argument `--safari10` to emit
| code that's supported by Safari. I discovered this
| argument after running into the bug.
|
| So the problem is with the tool, not with the Safari it
| seems. Without an explanation what "non-standard" is
| about Safari 10/11 it's on the same level as the rest of
| hand wringing on HN.
| recursive wrote:
| > So the problem is with the tool, not with the Safari it
| seems.
|
| You're making an assumption. I'm not sure where you're
| getting that. From what I recall, it was common `const`
| or parameter declarations in nested scopes. Safari was
| (is?) unambiguously wrong.
|
| Edit: here's the bug:
| https://bugs.webkit.org/show_bug.cgi?id=171041
| tinus_hn wrote:
| The reason for IEs stagnation wasn't that Microsoft was
| trying to hold back the web, it was that their domination
| was strong enough they didn't see a need to change. So
| why would they invest in updating it?
|
| The updates came in plugins tied to the Windows platform:
| ActiveX. Because that strengthened the monopoly, they
| were pulling the strings and setting the standards, at
| their own terms. Tie it to operating system versions, tie
| it to Office, tie it to the next product they want to
| promote. Whatever they like.
| bioemerl wrote:
| > it was that their domination was strong enough they
| didn't see a need to change. So why would they invest in
| updating it?
|
| Why invest so hard in capturing the web in the first
| place, then? Their behavior is consistent with a push to
| keep people on windows as much as possible.
| Waterluvian wrote:
| This seems wise. It's akin to developing for the slowest
| machine. I'm tempted. Though developing on Chrome just feels
| the best given the tools.
| bioemerl wrote:
| This statement here should be seen as a crimson flashing red
| flag waving as madly as a person can wave.
|
| "Want global web compatibility? Fuck you buy a Mac"
|
| -Apple
| coldtea wrote:
| Better than the alternative: leave it to Google to dictate
| whatever they like as a standard and ship it.
| bioemerl wrote:
| I would happily rather that neither of these happen. For
| safari not to be a buggy mess/work without extra
| development efforts and for chrome to have real competition
| enough to prevent them setting a standard.
|
| I will however, take chrome and user choice every single
| day over Safari's monopolistic crap.
|
| The mere fact it's largely successful by it's nature of
| being bundled should scream to you how bad it really is.
| kitsunesoba wrote:
| > I will however, take chrome and user choice every
| single day over Safari's monopolistic crap.
|
| That's the problem, though: more and more as time goes
| on, Chrome _isn 't_ user choice. Sites that only work
| with or only perform as expected under Chrome are
| becoming more and more common. It's becoming a monopoly
| too, but enforced by developers rather than a platform
| owner (though this is muddy with how Google gives Chrome
| performance advantages in Youtube, Docs, etc), and I'm
| not sure it's really any better.
| illiarian wrote:
| > though this is muddy with how Google gives Chrome
| performance advantages in Youtube, Docs, etc
|
| When (mostly) Chrome came up with Web Components, they
| immedieately re-wrote Youtibe with Web Components v0 (now
| deprecated). The polyfill for them was infamously slow on
| Firefox. Just another ooops in a long line of oopses:
| https://twitter.com/johnath/status/1116871237240852480
| nobleach wrote:
| I don't have such a problem with browser makers putting
| their own ideas into their software. If Google wants to put
| a Flutter runtime into Chrome, great, go ahead. Where
| things fall apart is when they prioritize these projects
| ahead of supporting standards upon which they agreed.
| Microsoft was free to build and support VML back in IE
| days. The issue I had was that they refused to support SVG
| which WAS A ratified standard. So Google creating
| experiments is just that. They're free to build these,
| evangelize them and bring these to WHATWG, CSSWG or TC39,
| or whatever other governing body they'd like. They aren't
| "creating standards" if these governing bodies do not adopt
| their experiments.
| illiarian wrote:
| > So Google creating experiments is just that. They're
| free to build these, evangelize them and bring these to
| WHATWG, CSSWG or TC39, or whatever other governing body
| they'd like. They aren't "creating standards" if these
| governing bodies do not adopt their experiments.
|
| Then why is HN is screaming bloody murder when other
| browsers don't implement the plethora of Chrome-only non-
| standards?
| kevincox wrote:
| To me this is the biggest difference between Safari and
| IE/Edge. Microsoft provided free VMs that you could download
| with all supported versions of IE and Edge. So you could test
| sites and investigate bug reports. With Safari you can't
| debug an issue without expensive Apple hardware. I was happy
| to keep my sites compatible with IE and Edge (maybe not
| constant testing but some manual testing after big changes).
| However no way I was going to do that work for Apple when
| they didn't help out at all.
|
| (The Edge VMs don't appear available anymore but since Edge
| is cross-platform and free it should be easy enough to
| install it in your own VM or on your workstation.)
| jojobas wrote:
| Well who wouldn't want to be in position to dictate that your
| bugs have to be other peoples' specs?
| illiarian wrote:
| > "Want global web compatibility? Fuck you buy a Mac"
|
| Still better than "whatever we throw over the wall is now a
| standard" that Chrome has, and you can see people clamouring
| for those on HN.
| zdragnar wrote:
| That's part of the ECMA standards process, and part of some
| others; progressing from a certain stage requires a minimum
| of two major implementations. The chrome team happens to
| sit on the leading edge of that process, being more willing
| to experiment. Safari sits on the other end, for better or
| worse depending on the feature.
| illiarian wrote:
| > progressing from a certain stage requires a minimum of
| two major implementations. The chrome team happens to sit
|
| The Chrome team happens to throw something over the wall
| and ship it to production with no oversight. And
| sometimes complain that that they cannot hide it behind a
| flag because people are already using it.
|
| There's no end of people _right here on HN_ who scream
| bloody murder when Safari (and Firefox) refuse to
| implement some new Chrome-only API.
| jefftk wrote:
| _> sometimes complain that that they cannot hide it
| behind a flag because people are already using it_
|
| The way this is supposed to work is an origin trial: you
| ship something behind a flag, and then allow sites to
| flip the flag for testing and experimentation. But it's
| well documented that this is a temporary process, some
| Chrome visitors you get won't be eligible for trials, and
| it's not guaranteed that features in origin trials will
| ship. What are you thinking of where they just shipped
| something, without an OT?
| illiarian wrote:
| > The way this is supposed to work is an origin trial:
| you ship something behind a flag, and then allow sites to
| flip the flag for testing and experimentation.
|
| For something to become a standard they way it's actually
| supposed to work is for browsers to come up with two
| independent implementations.
|
| And yet, Chrome frequently ships APIs it calls standard
| with just Chrome as the sole implementor.
| jefftk wrote:
| That wasn't the part of your comment I was replying to.
| You said they sometimes "complain that that they cannot
| hide it behind a flag because people are already using
| it", and I was (a) explaining why that's not supposed to
| happen and (b) asking about where you saw that happen.
| illiarian wrote:
| Constructible Stylesheets was released despite objections
| from both Safari and Firefox when it had both badly
| designed API _and_ an easily reproduced race condition.
|
| Literally "Note that .adoptedStyleSheets is used on about
| ~.8% of page loads in Chrome now. Backwards-incompatible
| changes are definitely an issue here."
| https://github.com/WICG/construct-
| stylesheets/issues/45#issu...
|
| ---
|
| WebMIDI allows enumeration of devices without asking the
| user for permission:
| https://twitter.com/denschub/status/1582730988118867968
| (note this is a part of a whole bunch of hardware APIs
| that Chrome just shipped, no consensus needed)
|
| Well, what do you know
| https://groups.google.com/a/chromium.org/g/blink-api-
| owners-...
|
| "this is a case where we're going from no permission
| prompt to a permission prompt, I think a PSA and
| developer communication is a good idea. Other chromium-
| based browsers may want to know as well, via these
| channels."
|
| Thankfully, there will be a change. At some point.
|
| ===
|
| These are two I know of, that's why I said "sometimes".
| As Chrome releases 400 new APIs each year, it's
| impossible to track them all.
| jefftk wrote:
| In both of your examples they're not saying they "cannot
| hide it behind a flag because people are already using
| it":
|
| * With adoptedStyleSheets they're objecting to making
| backwards incompatible changes, which is reasonable:
| everyone hates browsers breaking sites. But there are
| ways to do this safely, like changing the name of the
| property (as rniwa suggested
| https://github.com/WICG/construct-
| stylesheets/issues/45#issu...) and if that were the only
| issue I think they'd have done something like that.
|
| * With WebMIDI they're saying they want to do an
| announcement before making the change. (I do think it's
| nuts how long they're taking to fix this, and if you look
| on the blink-api-owners-discuss thread you linked you'll
| see I've been bugging them about it.)
| illiarian wrote:
| > With adoptedStyleSheets they're objecting to making
| backwards incompatible changes
|
| Which would not be backwards incompatible if they hadn't
| shipped something that wasn't agreed on in the first
| place.
|
| Again, slowly: they literally shipped that to production
| despite loud and explicit objections from _both_ Firefox
| _and_ Safari. When asked to hide it back behind the flag,
| "but backwards incompatible change, the framework we're
| developing is already depending on it"
|
| And since you're quoting rniwa, here's the relevant quote
| https://github.com/WICG/construct-
| stylesheets/issues/45#issu...:
|
| --- start quote ---
|
| I feel like I've put so much time & energy into making
| this feature something sane & useful, and all you did was
| basically to dismiss many of my feedbacks and go with
| whatever you like and just ship it. And now you're saying
| you can't make changes because you shipped it?
|
| I'm sorry but that's just not how standards work.
|
| --- end quote ---
|
| > With WebMIDI they're saying they want to do an
| announcement before making the change.
|
| Indeed. Once again: because they shipped an API that
| _neither_ Safari _nor_ Mozilla supported. Now that this
| issue has surfaced (no thanks to Chrome), they can 't
| just roll it back or fix it because people already rely
| on this behaviour, which they implicitly acknowledge.
| andybak wrote:
| How is it better?
| bioemerl wrote:
| Not really in my experience as a primary Firefox dev.
|
| It's easy enough to not use stuff like web USB, and in my
| experience chrome and firefox "get along" while a page
| (doing more advanced things) not built for safari simply
| will not work in safari.
|
| The problem with safari is that Apple makes it so you have
| to use it if you want your site to work on it. Chrome, I
| can safely ignore.
|
| I also literally can't use safari if I don't have a Mac.
| illiarian wrote:
| > while a page (doing more advanced things) not built for
| safari simply will not work in safari.
|
| I've yet to see such a page [1]. And I've been using
| Safari since 2007
|
| [1] Unless it's built with Chrome's non-standards of
| course.
|
| Edit: of course there will be pages broken in Safari (or
| FF) for no reason other than the sheer incompetence of
| people building them. E.g. we have an internal dashboard
| page that is literally nothing more than tables and
| charts. Ooops, "only works in Chrome".
|
| There's also the minor case of nominally open audio and
| video codecs that Google pushes to device manufacturers
| on pain of removing access to its services, but even that
| hasn't affected me, or most people really, that much.
| bioemerl wrote:
| > I've yet to see such a page
|
| Developers are eating the problems for you because safari
| support is almost always a requirement.
|
| This is a developer side problem, not a user side one.
|
| > for no reason other than the sheer incompetence of
| people building them
|
| Safari never breaks, but when it does it's because the
| developers are incompetent?
|
| The fact it takes a bunch of extra work to support safari
| (in more advanced cases like graphs and dashboards) is
| the whole problem. I have every intent to kick safari out
| of any home game stuff I do.
| illiarian wrote:
| > Developers are eating the problems for you because
| safari support is almost always a requirement.
|
| The problems "developers are eating" are hugely overblown
|
| > Safari never breaks, but when it does it's because the
| developers are incompetent?
|
| In 99% of the times? Yes.
|
| > The fact it takes a bunch of extra work to support
| safari
|
| No, it doesn't. Source: web developer myself.
|
| Of course, if you rely on Chrome-only non-standards,
| that's a different issue.
|
| > in more advanced cases like graphs and dashboards
|
| Graphs and Dashboards are advanced use cases now. Gotcha.
| bioemerl wrote:
| You should reconsider your position when your only
| response is dismissal and insult.
| illiarian wrote:
| > You should reconsider your position when your only
| response is dismissal and insult.
|
| I've been in these threads many times, and it's the same
| thing again and again:
|
| - Safari is holding back the web! It doesn't. Well, if
| you think that Chrome is web, then you're entitled to
| your opinion
|
| - Safari is new IE! It's not. That it doesn't implement
| the 400 or so APIs a year that Chrome implements is a
| feature, not a bug. If your site ends up with a "only
| works in Chrome" badge, _that_ is your new IE
|
| - Chrome split from WebKit three years after WebKit
| appeared. And the only reason for the split? Well, to do
| the same thing you accuse Apple and MS of doing: control.
| And look how well it worked for them. Everything they do
| is now considered standard and gospel by the gullible
| masses of web devs.
|
| And so on.
|
| The irony is that it's Chrome that breaks the web often,
| and badly, but they get a pass because it's Chrome! They
| have the new shiny APIs!
| Kiro wrote:
| You're just being obnoxious. Stop it.
| the_other wrote:
| > I also literally can't use safari if I don't have a
| Mac.
|
| You should embrace this; this is how the web should be.
|
| I don't mean you need to buy a Mac. Instead, I mean that
| the web standards effort originally came up out of
| supporting diversity. There was a wider range of possible
| clients, on a wider range of "popular" platforms. As
| developers we had to cater to support diverging
| capabilities. Progress on API development was slower, but
| it was more evenly spread out. Today, Chrome lurches
| ahead of everyone else in terms of API feature count,
| mostly supporting Google's business aims, and many vocal
| developers seem to think they should only support one set
| of capabilities. The slower, broader, way was better, in
| my opinion.
| kitsunesoba wrote:
| Yes, exactly. Use APIs that are broadly supported and
| somewhat settled and agreed upon. There is seldom an
| actual need to use whatever new thing that just became
| supported or is only implemented by Chrome... 95%+ of
| sites and web apps are doing the same old CRUD things
| that sites and web apps have been doing for decades and
| work fine with "boring" APIs.
| frozenlettuce wrote:
| At least Chrome does not have a price tag - In my country a
| MacBook equals 22 months of work on minimum wage
| flatiron wrote:
| https://github.com/kholia/OSX-KVM also works (also not very
| legal)
| notpushkin wrote:
| I don't think you really need a Mac - any browser running
| on WebKit should get you 95% there. GNOME Web on Linux, for
| example.
| tonetheman wrote:
| [dead]
| Eric_WVGG wrote:
| You're not wrong (I develop that way as well), but I'd wager
| that like me you're not neck deep in service workers and WASM
| and a "compression streams API."
|
| This isn't a Chrome vs Safari issue (Safari is better, of
| course), it's the fact that browser development suffers from
| Apple's corporate wall of silence. In this case, devs literally
| suffering.
| faitswulff wrote:
| This wouldn't have helped the author, though, since their
| issues were contingent on what fixes were included in the
| actual releases.
| ricardobeat wrote:
| It's always been a web developer's job to workaround browser
| incompatibility issues. Expecting them all to be 100%
| compliant with specs is a mirage.
| saagarjha wrote:
| Ok, but that doesn't actually help when you run into WebKit
| bugs.
| giraffe_lady wrote:
| It does because you notice you've run into a webkit bug and
| work around it. A surprisingly high number of sites have core
| functionality like signin, nav or payment broken on safari
| and apparently aren't aware of it.
| lostgame wrote:
| This is an exceptionally smart outlook; and reflects my own
| experience - if something is wrong in my code in Safari it is
| usually wrong elsewhere.
|
| There's an important and cool concept here about using the
| weakest link sometimes.
|
| Similar example: as an app developer, I intentionally use a
| phone several, several generations behind so I can see what the
| actual response time and general UX feeling is on the devices
| frankly a lot of users are going to have.
|
| If my app runs well on my iPhone 8, it's obviously going to
| scream on a 12.
| ChrisMarshallNY wrote:
| Currently, my LET (Low-End Test) device is an original SE,
| running iOS 15. I also have a 4th gen iPad Mini, and an
| iPhone 8Plus (for the screen).
| robinsonb5 wrote:
| For a moment there I thought you meant one of these:
| https://en.wikipedia.org/wiki/Macintosh_SE
| ChrisMarshallNY wrote:
| I started with a Plus.
| ohgodplsno wrote:
| I switched to an Internet Explorer-first approach for web
| development, and it has reduced my problems considerably. In
| fact, I make my websites assume they will be viewed in a
| 640x480 viewport.
|
| I'm basically guaranteeing full compatibility with everything,
| because everyone has to comply with IE's behaviour. After all,
| I put a "Best viewed in Internet Explorer", this way if it
| fails, people blame their browser and not me.
| chatmasta wrote:
| I concur with the frustrations in the article. Note that you can
| automatically test Safari releases with Playwright and GitHub
| Actions MacOS runners.
| victor96 wrote:
| I've always struggled with Safari for it's terrible WebGL
| implementation. Even had to globally disable anti-aliasing
| otherwise the app would be unusably slow!
| meindnoch wrote:
| TL;DR: they are mad because of:
|
| 1. A genuine (?) Safari bug with the CompressionStream API. (we
| never learn what the actual bug was, and their bugreport to
| WebKit was literally just that "hey, our website at URL ...
| doesn't work" - no minimal reproducible example whatsoever. Lol)
|
| 2. An issue due to them relying on a Chromium bug.
|
| 3. An issue due to them assuming that OffscreenCanvas will always
| support both 2D and 3D (WebGL) contexts.
| mrweasel wrote:
| It honestly impressive how quickly they get a fix. Sure it take
| seven days for someone to get to the bug they filed, but from
| there it's fixed in 12 hours.
|
| The post makes it sound like both Mozilla and Google are better
| at handling releases, but Chrome has the service worker bug, so
| I don't know if that's actually true.
|
| I get that Safari is sluggish, at least compared to Chrome and
| is currently lacking features, but doesn't it seem like they've
| picked up the pace in the last year or so?
| theodorejb wrote:
| These were just a few issues with the latest version. Similar
| problems have occurred with past releases for years, and it
| seems the author is justifiably stressed out over the lack of
| transparency and never being sure if/when a breaking change is
| about to occur for customers using Safari.
| MrBuddyCasino wrote:
| I've read the standard [0], to be fair there is nothing in
| there explicitly indicating that some contexts might be
| unsupported, except the vague "if this does not throw an
| exception" condition, which is easy to miss.
|
| [0] https://html.spec.whatwg.org/multipage/canvas.html#the-
| offsc...
| lapcat wrote:
| > TL;DR: they are mad because of:
|
| This is not a good summary of the article. They're aren't mad
| at the bugs, they're mad at how Apple handles Safari releases
| (as seen in the very title of the article).
|
| If you read the "how to fix it" section, the fixes are
| "transparency", "update Safari independently of the OS", "more
| pre-release testing options", "communication".
| lucideer wrote:
| Release schedules &c. aside, they have no argument if they're
| complaining about the Safari team's "communication". The
| diligence from the Safari team in responding to those bug
| reports is not something I've seen from other browsers
| vendors.
| lapcat wrote:
| > Release schedules &c. aside, they have no argument if
| they're complaining about the Safari team's
| "communication".
|
| You can't put that aside, because it's the entire point!
|
| "The bug is fixed in the git repository, but we refuse to
| tell you if or when the fix will appear in Safari" is
| communication, but it's not the kind of communication
| needed for web developers.
|
| > The diligence from the Safari team in responding to those
| bug reports is not something I've seen from other browsers
| vendors.
|
| I have to disagree there.
| lucideer wrote:
| > _You can 't put that aside, because it's the entire
| point!_
|
| Sorry I didn't mean to imply it wasn't relevant, merely
| that I wanted to address one small sub-point of your
| comment.
|
| > _is communication, but it 's not the kind of
| communication needed for web developers._
|
| That's fair, but it's relative: a quick response with a
| commitment of work (if not of timelines) & active
| dialogue on debugging efforts (due to the complete lack
| of effort on the part of the reporter) is a LOT better
| than no commitment or response, or a "please provide more
| info" / "WONTFIX" / CNR. Which is much more common.
|
| Particularly given I think a "please provide more info"
| would've been a perfectly reasonable response to the
| first report.
| replygirl wrote:
| > I assumed it would have parity with the standard <canvas>
| element. Why wouldn't it? The MDN documentation mentioned
| nothing about inconsistent availability of contexts.
|
| only mdn docs do list the context types as separate subfeatures
| in the support table, as does caniuse
| VWWHFSfQ wrote:
| Safari is easily the worst browser in existence. It is absolutely
| riddled with bugs. Anything except the most basic functionality
| you can expect to be a buggy piece of crap for years on end. See
| webrtc.
|
| Hopefully apple gets sued someday so we can stop using their
| horrible browser
| ezfe wrote:
| lol
| tgv wrote:
| I understand they're annoyed, but "hell"? Chrome put me through a
| wild goose chase somewhere around version 94 with some non-
| standard behavior, and Safari 16 has some weird issue with
| requestAnimationFrame, but "hell"? That's out of proportions.
| throwayyy479087 wrote:
| His complaints are very well outlined. They are a bit niche due
| to his use case, but they certainly are real, breaking changes
| out of nowhere.
|
| Standards compliance really is the name of the game, and I wish
| people like GP had more pull to force Apple to make these
| reasonable changes.
| lucideer wrote:
| If you think this you haven't read the linked bug reports.
|
| His second one in particular is his app relying on
| unspecified implementation quirks - the Safari devs are
| responsive due to a desire to be more compatible with
| Chrome's quirks, not because they've failed to conform to
| spec.
|
| His first bug report is just lazy and devoid of any detail -
| completely relies on the Safari team to do the work of
| debugging his app for him.
| AshleysBrain wrote:
| I credited the Apple developers with doing a good job in
| the blog. The point is Apple's policies end up turning what
| should be a routine bug fix in to a total nightmare.
|
| I've filed dozens of issues with Apple and many of them go
| in to great detail. However when you're pushed for time and
| dealing with multiple potential emergencies, you can't
| always manage much more than a "heads up, this looks wrong"
| type issue. In the case of the first bug, it was indeed a
| real problem with Safari and it was Apple's responsibility
| to fix it. Given that Apple are a trillion-dollar company
| with thousands of employees, and we have a handful of
| people in an office in south-west London, I think it's
| reasonable that Apple does more of the heavy lifting
| investigating Safari issues anyway. Ultimately it's up to
| Apple to make Safari a high-quality browser, not us,
| although we still do our bit with bug reports where we can.
| tough wrote:
| Man is free to make up their own personal hells
| exabrial wrote:
| Server side rendering... makes things a lot easier.
| blahblah1234567 wrote:
| [dead]
| wdb wrote:
| My main problem with Safari is that it is not as convenient to
| use a developer tool. Sure, its devtools looks pretty but it
| doesn't have all the useful devtools extensions that Chrome/Edge
| has.
|
| I use Safari as my main content browser but typically switch to
| Edge for development work.
|
| Also when you read W3C specs it can get confusing pretty quickly,
| vage wordings, etc. Or have MDN documentation that doesn't
| describe particular behaviour that is defined in the W3C specs
| etc.
| toyg wrote:
| _> "I desperately want Apple to change"_
|
| Ahh, that's your problem right there, man. Apple don't change for
| you, for me, or for anyone who isn't called Tim Cook. They'll be
| out there doing their monopolistic, zero-sum, winner-takes-all,
| my-way-or-the-highway, straight-outta-the-'90s thing, forever and
| ever.
|
| Apple doesn't care about developers really, as far as the company
| is concerned they're all little sharecroppers on Steve's garden.
| Any help you get you should be thankful for, because you have no
| rights there and never will have. Enjoy your Stockholm syndrome
| while it lasts.
| kingboss wrote:
| Why would they care about developers? They care about their
| customers. People buy their stuff and you, as a dev, have to
| support Safari. Whether you like it or not. It's called work.
| jmull wrote:
| > ...which in turn uses the Compression Streams API when
| supported
|
| > ...uses OffscreenCanvas when available
|
| I think it's a mistake to write your code to automatically use
| new platform capabilities when they become available if you won't
| have an adequate chance to validate them first.
|
| It's just too optimistic to believe a new implementation of a
| low-level mechanism is going to work exactly the way you need.
| (1) new things have new bugs; (2) changes are you'll end up
| depending on implementation details that will vary between
| different implementations.
| jefftk wrote:
| What should you do instead? The alternative is UA-sniffing, and
| that's worse: https://news.ycombinator.com/item?id=35425549
| jmull wrote:
| > What should you do instead?
|
| It's your choice: (1) don't use it; (2) validate it before
| using it; (3) roll the dice on behalf of your users -- that
| is, use it without validating it.
|
| Don't let religious beliefs around UA-sniffing cause you to
| screw over your users.
| AshleysBrain wrote:
| Browser makers, including Apple, always say to use feature
| detection - i.e. to use features when they appear to be
| available. The alternative is user-agent sniffing, which they
| advise against.
| kevincox wrote:
| Yeah, this is the problem with feature detection which isn't
| talked about enough. It is often easy enough to detect whole
| APIs or even some new methods but correct functionality and
| optional parameters can be hard or impossible to test.
|
| In most cases I have found that feature detection + a
| blacklist of problematic browsers is often a good compromise.
| But there is no perfect solution.
| ricardobeat wrote:
| These bug reports are very poor, with apparently no effort to
| zoom in on the underlying issue, but the WebKit team took
| application-specific problems like "can't open project", "the app
| gets stuck in the loading screen", dug in and fixed them in days
| time. This is stellar support for a single company or product,
| props to the Safari team for that.
|
| I do agree releasing a broken implementation is bad, not clear
| what happened there. Aren't Safari releases held back until a TP
| is free of critical issues? Was this not marked as critical due
| to being reported as an app issue instead of a Compression
| Streams or Service Workers incompatibility / regression?
| sccxy wrote:
| It is very hard to properly debug iOS bugs also.
|
| "a problem repeatedly occurred" and page crashes all the time.
|
| Only in Safari iOS 16. Worked in iOS 15. Works even in IE.
|
| What kind of bug report can you make out of it?
| mh- wrote:
| Attaching Safari Dev Tools from a Mac to the iOS device
| should surface those errors, in my experience.
| MatthiasPortzel wrote:
| This experience is wonderful in my opinion. It's difficult
| to discover: you have to check Safari Settings > Advanced
| on your phone to enable it.
| sccxy wrote:
| No errors are shown when debugging this way.
| theodorejb wrote:
| What if you don't have a Mac?
| olyjohn wrote:
| "Fuck you, buy a Mac." -Apple.
| vxNsr wrote:
| I was gonna say then how are you developing for iOS, but
| this is a website, so you're right, it's kinda
| ridiculous. OTOH if you're a large enough website you
| should be testing on every platform.
| sccxy wrote:
| Same should said to Apple.
|
| They release new API but they "forgot" to test when
| website is added to home screen (PWA).
|
| New API passes feature detection but does not work in
| PWA.
|
| iOS and macOS Safari have different bugs also...
|
| So you have to sniff user agent and other things to find
| out broken iOS versions and hardcode workarounds...
| ricardobeat wrote:
| What if you don't have Windows?
|
| In either case, there are plenty of browser testing SaaS
| that give you real Mac/Win/Linux/iOS/Android machines for
| testing and debugging.
| sccxy wrote:
| Microsoft offers free Windows 11 Virtual Machine files:
|
| https://developer.microsoft.com/en-
| us/windows/downloads/virt...
| theodorejb wrote:
| Microsoft Edge is available for both Mac and Linux.
| lucideer wrote:
| This exactly.
|
| Given the diligence of the Safari team - especially in the face
| of the extremely lazy first bug report - it's kinda wild that
| this person thought it appropriate to post such a negative
| angle.
|
| The second bug report wasn't even a bug: Chrome & Safari had
| implemented an unspecified part of the spec. differently to
| each other (specifically the implementation behind generating
| client IDs for fetch events in web workers -vs- the main
| window). The op is relying on an unspecified implementation
| detail for their app to work. Yet the Safari team actively
| treat it as a bug in an attempt to be more generally compatible
| with Chrome.
|
| My takeaway from actually reading through the content of the
| post is that the Safari devs are responsive and approachable,
| even even the bug reporter is lazy. Which is more than can be
| said of many other browsers projects.
| AshleysBrain wrote:
| I credited the Apple developers with doing a good job in the
| blog. The problem is Apple's policies end up turning a
| routine bug fix in to a total nightmare.
| turnsout wrote:
| I think the larger issue is that you're relying on new or
| exotic browser APIs without enough skepticism about their
| behavior across a range of platforms. CompressionStream is
| brand new in 16.4, so zip.js should absolutely NOT assume
| it's available, and if it does detect the API, it should
| gracefully fall back to the older implementation if it
| encounters errors. I realize this is not your issue, but a
| dependency--but it could be a reason to use a library with
| a less aggressive upgrade philosophy, such as Pako.
| AshleysBrain wrote:
| Browser makers always recommend feature detection (i.e.
| use a feature if it's available) over hacks like user-
| agent sniffing to selectively enable features. Web
| developers can't look in to a crystal ball and pre-
| emptively code around APIs with unexpected issues.
| turnsout wrote:
| But you can avoid adopting APIs that have been Chrome-
| only until 5 minutes ago...
| AshleysBrain wrote:
| That means avoiding features that can enhance your
| software, improve performance, and help get ahead of
| competitors.
| turnsout wrote:
| Yeah, that's one of the many tradeoffs in developing a
| web app. It has not changed since the Netscape days.
| gildas wrote:
| Author of zip.js here, the CompressionStream API is
| available for 3 years in Chromium-based browsers [1].
| That's why I integrated it 6 months ago in zip.js.
| However zip.js can detect if the API is present or not,
| and can work if not available (e.g. in Firefox). It
| cannot detect implementation bugs in the API though. Note
| that there's also an option to disable the use of the API
| [2].
|
| [1] https://caniuse.com/?search=CompressionStream
|
| [2] https://gildas-
| lormeau.github.io/zip.js/api/interfaces/Confi...
| turnsout wrote:
| It doesn't matter if it's been available for 10 years on
| Chrome--if it's not reliable on other platforms, don't
| use it. And you absolutely CAN and should detect
| implementation bugs in the API. At the very least you can
| throw CompressionStream's entire
| compression/decompression process behind a try...catch
| block, and fall back to the older method on an error.
| jefftk wrote:
| _> It doesn 't matter if it's been available for 10 years
| on Chrome--if it's not reliable on other platforms, don't
| use it._
|
| As an author you have two main options:
|
| 1. Feature detection: check to see if the API exists in
| the browser, and gracefully fall back if not.
|
| 2. UA-sniffing: use the API only on browsers where you've
| verified that your program works correctly with its
| implementation.
|
| There's pretty strong consensus on the web that authors
| should be doing (1), and that (2) is harmful to minority
| browsers. Every time someone says "the new feature works
| fine in Firefox if I set my UA to Chrome" they're
| complaining that the site didn't go with (1).
|
| Yes, using (1) means trusting browsers to get their
| implementations correct, but they are usually very good
| about this and getting better. The http://wpt.fyi tests
| have been a big help here.
| duped wrote:
| Option 3: Allow dependents to enable it explicitly with a
| feature flag.
| gildas wrote:
| Options 1 and 3 are implemented.
| turnsout wrote:
| I don't disagree with any of that, but you have another
| option:
|
| 0. Wait: Don't adopt the API at all if it is only
| supported in Chromium, because it's _highly probable_
| that the API will have behavioral or API differences if
| it 's implemented by other browsers in the future.
| gildas wrote:
| Please read the documentation of the API and you might
| think the probability would be very low [1]. Note also
| that zip.js works totally fine in all stable browsers,
| Safari 16.4 included. There are no known issues [2]. I
| have absolutely no idea what we are talking about because
| it looks like the bug has been fixed by Apple in the
| stable version of Safari. And maybe zip.js helped them to
| do so.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/API/Compression...
|
| [2] https://github.com/gildas-lormeau/zip.js/issues
| AshleysBrain wrote:
| Waiting doesn't work when Apple do things like ship a
| working and spec-compliant WebAssembly API which works
| great so you start using it, then they completely break
| it in a subsequent update, and leave it both enabled and
| broken for months. No amount of foresight or caution will
| save you in that case. It's ultimately the browser
| maker's responsibility to make sure APIs work.
| gildas wrote:
| It was hard for me to anticipate that Apple would
| implement the CompressionStream API incorrectly 6 months
| later. However, it is extremely likely that an exception
| was indeed raised when this bug was triggered. I was
| never made aware of the existence of this bug. Besides,
| zip.js does its best to rely on fallback implementations
| in case of errors. I'm not supposed to integrate the
| entire CompressionStream API test suite (and all the
| other APIs) into zip.js either.
| saagarjha wrote:
| > Aren't Safari releases held back until a TP is free of
| critical issues?
|
| No. Safari releases ship in lockstep with iOS releases.
| ilikehurdles wrote:
| Not so on MacOS.
| lapcat wrote:
| It is so on macOS. In fact, macOS updates now ship in
| lockstep with iOS releases.
|
| This is because they all share code, and more importantly,
| security vulnerability fixes.
|
| You might be referring to how Safari is updated
| independently of macOS on the 2 non-latest versions of
| macOS. But those are still released simultaneously with the
| OS updates, and Safari on the latest version of macOS is
| bundled with the OS update.
| ilikehurdles wrote:
| I think I might be referring to that? Mainly referring to
| the separate "Other Updates" section of downloads, but I
| didn't know those are still tied to OS updates for
| Safari.
| lapcat wrote:
| See for example how there's a Safari 16.4 update for Big
| Sur and Monterey but not for Ventura. That's because the
| macOS Ventura 13.3 update includes the latest Safari,
| just like the iOS 16.4 update includes the latest Safari.
| https://support.apple.com/en-us/HT201222
|
| The separate Safari updates are only for back support of
| older macOS versions.
| illiarian wrote:
| I've seen updates just for Safari, but those are
| irregular.
| jwlake wrote:
| The problem I see with this is people assume that web platforms
| are platforms like the windows API where Microsoft doesn't like
| breaking things.
|
| It's more like Xcode, where every point release breaks something.
| You need to design your software and your development pipeline to
| handle that.
|
| Even Google isn't great in this but their continuous release
| schedule makes it less likely to break things in the wild because
| they get constant pushback.
| circuit10 wrote:
| From what I understand the web is meant to be 100% backwards
| compatible. You should be able to load up the first HTML
| document ever made and have it still render fine (and it
| probably would)
| rejectfinite wrote:
| >I asked whether the fix would ship in Safari 16.4, and an
| engineer responded talking about STP.
|
| Spanning Tree Protocol? :D
| ribit wrote:
| Apple would certainly benefit from more transparency in these
| matters, no question. Decoupling Safari updates from OS updates
| and better communication/tracking of issues and release dates
| would be a big help
|
| At the same time, I don't really see why they should aim to
| replicate other browser bugs or be responsible for author's
| idiosyncratic assumptions regarding feature availability. It's a
| shame that browsers don't have to undergo strict compliance tests
| and that JavaScript is generally pretty much awful. Under these
| circumstances the most popular browser (Chrome) is taken as a
| gold standard and that can't be good for the open web.
| illiarian wrote:
| > It's a shame that browsers don't have to undergo strict
| compliance tests
|
| There are compliance tests, and it's a thankless job to create
| and maintain them that some people do. But browsers are bigger
| than some OSes now. It's almost impossible to create
| comprehensive compliance tests that cover everything.
| AshleysBrain wrote:
| Is it idiosyncratic to assume that two variants of the canvas
| API support the same things?
| bzzzt wrote:
| Considering it's a big API with dozens of methods I'd be
| surprised if two implementations would agree exactly.
| AshleysBrain wrote:
| I would have assumed browsers had one internal
| implementation and exposed it through both APIs. They
| wouldn't want to have two separate implementations of a
| large amount of complex code.
| cxr wrote:
| Yes, and it's a little reckless to even get to a state where,
| even in the presence of bonafide bugs re non-standard
| behavior, just showing "a blank screen" when your app dies is
| a possibility. Add some basic error detection/reporting.
| AshleysBrain wrote:
| We did have basic error detection and reporting. For
| example if it failed to get WebGL in a normal HTML canvas,
| it would show a "WebGL not supported" error message with
| some diagnostic details and some advice about what the user
| could do about it. The problem in this case is a gotcha
| where there are two ways to access the canvas API, one
| supporting WebGL, and the other not - a case we never
| anticipated, nor had happened with any previous browser.
| sccxy wrote:
| Safari is real pain for web apps.
|
| "Most powerful" phone runs out of memory, but 10 year old Android
| can handle same site fine. It was working fine in iOS 15 also.
| And works even in old IE11.
|
| Every iOS release is horror, what will be broken again...
|
| Yes, I am angry and tired of Apple's lack of QA. Trillion dollar
| company should invest more in quality.
| TheCoreh wrote:
| A more relaxed solution to the zip issue would be simply to patch
| zip.js to not use the Compression Streams API in Safari. After
| 16.4 came out you could check if it worked, and remove the patch
| at your own pace.
|
| Re: The release timing/schedule problem, I agree that more
| transparency on the release date would be nice, but since it is
| tied to an entire OS release, they probably can't do that. The
| way to go is to keep an eye out for the beta release cycle of
| iOS. They will typically release 5 or more betas, and then one or
| more RCs, and then a GM, and then will start rolling out the
| update to users. There are several websites like Mac Rumors,
| Apple Insider, 9to5Mac where you can get a good temperature of
| where in the cycle Apple currently is.
| afavour wrote:
| > A more relaxed solution to the zip issue would be simply to
| patch zip.js to not use the Compression Streams API in Safari.
|
| IMO absolutely any time you have to sniff a browser user agent
| there's a failure somewhere. If there's a spec the
| implementation should adhere to the spec.
|
| > After 16.4 came out you could check if it worked, and remove
| the patch at your own pace.
|
| Great for regularly updated web sites but if you're making a
| tool you don't want to maintain it'll forever be stuck in a
| state where Safari performs worse because it isn't using the
| correct API. And that sucks for users.
| jeroenhd wrote:
| > IMO absolutely any time you have to sniff a browser user
| agent there's a failure somewhere. If there's a spec the
| implementation should adhere to the spec.
|
| In this case I would probably add an "if Safari >=16.4 then
| skip compression streams" check, but that check would
| probably still be there in a couple of years. Resolving the
| immediate issue of "the product doesn't work on Safari" gets
| priority but "let's see if Safari got their shit together"
| would be a low priority task for me.
|
| There bad (or seemingly incomplete) spec implementations are
| how you end up with "your browser is not supported" plastered
| all over web apps. When Blink will inevitably hit iOS, Apple
| will have to do a better job placating web dev concerns if it
| doesn't want to lose market share.
| zamnos wrote:
| Following the official instructions*, I'm able to run (on
| iDevices tied to my Apple developer account) a custom built
| Chromium binary that is supposed to be Blink on iOS.
| Unfortunately this doesn't seem to be the case, according
| to a JSFiddle for WebTransport **. Desktop prod Chrome is
| able to see the WebTransport variable, Desktop prod Safari
| is unable to, mobile prod Safari is also unable to, and my
| custom Chromium binary, with _use_blink_ set to true is
| also unable to. My guess is that my build is not actually
| reading that flag, but someone more adept at this bespoke
| build system would easily be able to figure out what 's
| going wrong.
|
| * https://chromium.googlesource.com/chromium/src/+/main/doc
| s/i...
|
| ** https://jsfiddle.net/jib1/8gtd3s9v/10/
| [deleted]
| barkerja wrote:
| To piggyback off the beta release cycle, I really like Thinky
| Bits chart on iOS beta releases. Looking at it gives a pretty
| good idea of when the current beta will hit RC.
|
| http://www.thinkybits.com/blog/iOS-versions/
| realusername wrote:
| I'm fortunate enough to be in another job now where we don't need
| iOS web support so we can tell customers that we won't fix it, in
| my past job where I had to it was very hard to keep up with the
| constant stream of broken safari releases, every one of them
| being broken in different ways.
|
| I sympathize with those who still do and I'm looking forward to
| EU regulations to allow other rendering engines.
| z3t4 wrote:
| Most users will have other browsers installed along with Safari.
| And they will just switch browser if something doesn't work, they
| are used to it.
|
| If possible you should have automatic tests that you can run
| automatically in several browsers.
|
| Some browser need to be the first one to implement new
| functionality, before there is a specification! Then the
| specification comes and often it's different then the already
| implemented API.
|
| You should not complain about new features, and you should not
| complain when browsers follow specifications. Instead you should
| have tests, and encourage users to report problems.
|
| Most browsers have a beta/review release, you can run your test
| on that, once per day, automatically. Use a program that automate
| mouse movements and clicks, for example Puppeteer for automating
| Chrome. (tip: also do performance test while you are at it, so
| you will know which changes affect performance)
| rippercushions wrote:
| > _Most browsers have a beta /review release, you can run your
| test on that, once per day, automatically._
|
| A large part of the post's complaint is that not only does
| Safari not have a nightly build, but they don't even give
| advance notice of when their "technology preview" (beta) or
| stable releases are coming.
|
| Chrome, by contrast, not only has a public schedule, but a
| public dashboard where you can follow along.
|
| https://developer.chrome.com/blog/early-stable/
|
| https://chromiumdash.appspot.com/schedule
| Y-bar wrote:
| I thought there were nightly (or at least daily) builds? At
| least it looks that way in the WebKit archive where the three
| latest builds right now are: 262503@main
| April 3, 2023 at 01:23 PM GMT+2 262502@main
| April 3, 2023 at 10:51 AM GMT+2 262501@main
| April 3, 2023 at 10:17 AM GMT+2
|
| https://webkit.org/build-archives/#mac-
| ventura-x86_64%20arm6...
| ducknalddon wrote:
| >Most users will have other browsers installed along with
| Safari. And they will just switch browser if something doesn't
| work, they are used to it.
|
| I don't. If your web site doesn't support Safari then I will
| take my business elsewhere.
| theodorejb wrote:
| > Most users will have other browsers installed along with
| Safari. And they will just switch browser if something doesn't
| work, they are used to it.
|
| Unfortunately iOS users don't have this option.
| luckylion wrote:
| > Most users will have other browsers installed along with
| Safari. And they will just switch browser if something doesn't
| work, they are used to it.
|
| Is there any statistic to back that up that safari users first
| blame their browser and switch to a different one before they
| give up on a site? And why are they still using safari in the
| first place if it happens so frequently that they made a habit
| out of switching browsers? I'm not convinced.
| sccxy wrote:
| > Most users will have other browsers installed along with
| Safari. And they will just switch browser if something doesn't
| work, they are used to it.
|
| HAHAHA.
|
| Are you not aware that every browser in iOS is basically
| wrapper for Safari?
|
| New bugs in Safari will break other browsers also.
| hk1337 wrote:
| > Most users will have other browsers installed along with
| Safari. And they will just switch browser if something doesn't
| work, they are used to it.
|
| I haven't found that to be entirely true. Users will definitely
| have multiple browsers installed but that's usually because
| someone in their IT department had them install a second
| browser for testing. Most users will use one browser the entire
| time and need someone to tell them to try it in another browser
| if it's not working.
| jeroenhd wrote:
| This is also my experience, but people do tend to migrate to
| a different browser entirely if their workflows don't work in
| the other browser.
|
| If every website works in Chrome and most websites work in
| IE, users will switch to Chrome. Same with Safari. If the
| thing you're building is interesting enough for users to
| return to it, the unsupported browser may just stop getting
| used all together, especially if multiple sites break at the
| same time (i.e. when Safari broke WebAssembly support).
| bioemerl wrote:
| > Most users will have other browsers installed along with
| Safari.
|
| Apple literally goes out of their way to deny you the right to
| use another browser engine on their mobile phones.
| realusername wrote:
| > Most browsers have a beta/review release, you can run your
| test on that, once per day, automatically.
|
| Okay, how do I run headless Safari in a CI exactly? And how do
| I run Safari mobile in a CI since it has different bugs than
| the other one sometimes?
|
| I'm sure some people hacked some stuff together with ducktape
| but you are far far outside the supported development cycle of
| this software.
| livelielife wrote:
| quality is expensive. if not even apple can afford it, what can
| we expect from the rest?
| mkl95 wrote:
| The browser world is a political, uncoordinated mess. For example
| WebTransport (an HTTP3 API) has been available on Chromium-based
| browsers for months, but it's still on "Safari Technology
| Preview", and Firefox does not support it at all. You can
| probably find dozens of similar examples over the years.
| illiarian wrote:
| > For example WebTransport (an HTTP3 API) has been available on
| Chromium-based browsers for months, but it's still on
|
| Perhaps because WebTransport is still not even anywhere close
| to be to a web standard? Perhaps because its status is
| literally, quote:
|
| --- start quote ---
|
| works in progress inside a W3C Group and are not required to
| have the consensus of the Group participants. These drafts have
| not received formal review and are not endorsed W3C.
|
| These drafts MUST NOT be cited as W3C standards and may or may
| not become W3C standards.
|
| --- end quote ---
|
| Just because it's shipped in Chrome does not make it a standard
| that every other browser has to implement immediately.
| mkl95 wrote:
| I agree with all your points. I was trying to highlight how
| dysfunctional it feels from my point of view (backend
| engineer).
| lapcat wrote:
| > More pre-release testing options
|
| It's also worth noting that Apple has the bad habit of
| discontinuing Safari Technology Preview support on older macOS
| versions faster than they discontinue Safari support on older
| macOS versions, which results in testing gaps for Safari on those
| versions.
|
| Safari supports the last 3 macOS versions, while Safari
| Technology Preview only supports the last 2. Take a wild guess
| which macOS version gets the most new regressions from new Safari
| versions.
| macguillicuddy wrote:
| We encountered a relatively major regression during the iOS 16.4
| beta which unfortunately went live with the release version of
| 16.4. Requesting an 'environment-facing' camera using
| getUserMedia now provides the ultra-wide camera (rather than the
| usual standard angle lens). The workaround is unfortunately
| rather gnarly - having to rely on an order in a list that's not
| guaranteed by the spec and indeed different on Android.
| https://bugs.webkit.org/show_bug.cgi?id=253186
|
| While it's fixed in webkit, the webkit team were unable to tell
| us if the fix would be in the shipping version of 16.4 and,
| despite discovering and reporting the bug before it even hit a
| beta, the shipping 16.4 has the bug.
|
| I really feel for the team who are maintaining the code. It's
| clear they do a great job in difficult circumstances and it's
| several high-level policy decisions at Apple make things really
| challenging for them: they're unable to talk about when bugs and
| their fixes will (or will not) be present in release software;
| and Safari updates are tied to OS releases.
| saagarjha wrote:
| It's the dumbest policy, and it's not limited to WebKit: you
| see this in other open source projects like Swift and LLVM too.
| As a general policy, Apple does not allow their engineers to
| talk about future products. When the commit that just landed
| into the main branch will ship on user's devices falls under
| "comments on future products" and thus they won't talk about
| it.
| miohtama wrote:
| This is the backwards 80s and 90s corporate culture of a
| secrecy instead of community or customer oriented. Heck, even
| Microsoft is getting this right nowadays. Apple is one of the
| most developer hostile companies still standing.
|
| But I guess they will stand until there is external pressure
| to force them to change e.g. in the form of regulation
| allowing to bundle alternative web browser engines and not
| giving preferential private APIs.
| cjbgkagh wrote:
| Microsoft is only 'getting it' because they are losing
| ground and they know it. I figure that's what you mean by
| external pressure.
| miohtama wrote:
| Even a worm can learn to navigate thru a maze if you give
| it enough electric shocks
| jefftk wrote:
| When I was working on open source at Google this was also
| something we had to be very careful with: you don't want to
| make promises you can't keep. But this wasn't as strict as
| what Apple does, and vague estimates were allowed.
|
| For example, here's what Chrome does:
| https://chromiumdash.appspot.com/schedule. All the dates are
| tentative and sometimes slip, but an engineer can point
| people to it, say "fix X made the branch cutoff for release
| NNN", and you can get a pretty good prediction for when X
| will get to what sort of devices.
| saagarjha wrote:
| Yeah, to be clear, people make jokes about Apple being
| unable to confirm that there will ever be another iPhone.
| They're funny because they're mostly true.
| rob74 wrote:
| Well, you have to understand: the current iPhone model is
| a perfect pinnacle of technology, so talking about
| someday releasing something _even better_ would be
| blasphemy until they actually manage to pull it off...
| AshleysBrain wrote:
| That Chromium dashboard is amazing for planning and exactly
| the kind of thing we need for Safari.
| depressedpanda wrote:
| > and Safari updates are tied to OS releases.
|
| Safari is the last non-evergreen browser. As long as Apple
| insists on this policy it doesn't matter how good a job the
| WebKit team are doing; they're still hamstrung by the outdated
| release policy Apple enforces.
|
| Luckily, soon Apple will be forced to allow alternative
| browsers. At that point, I hope Apple will spend some of its
| trillions on actually improving Safari, in order for it to stay
| relevant and competitive.
| musicale wrote:
| > actually improving Safari, in order for it to stay relevant
| and competitive
|
| Safari seems to be the last bulwark against a Chrome-only web
| driven by features of the week.
|
| Full Chrome/Chromium on iOS could very well end that, and I'm
| not thrilled at the prospect.
|
| Personally I appreciate Safari's resistance to constant
| featurism in general, and conservative approach to features
| that are likely to compromise power usage or privacy. I have
| little desire for web apps to reach complete feature parity
| with native apps, or to have complete access to all hardware
| and OS features. Many developers may hate it and want to
| usher us into Google's PWA future, but I'm absolutely fine
| where things are right now. And I certainly don't want to
| have to use Chrome/Chromium for everything.
|
| Lastly, as a developer, I don't like building on quicksand.
| And yet that's often what it feels like using web/JavaScript
| frameworks and browsers that change from week to week.
|
| Nonetheless, OP's recommendation that Apple note which
| versions of Safari a certain bug is fixed in seems like a
| very good idea that should be adopted.
| noahtallen wrote:
| Frankly, I don't think all that matters. Safari doesn't
| keep up with web _standards._ It's not like they're failing
| to be competitive as with browser features -- that's a
| different question. As long as a web standard is specified,
| and Safari doesn't implement it, it's not doing their one
| job as a browser engine.
|
| The pace of change in the frameworks world is completely
| independent of web and browser features. And the web is
| very backwards compatible -- so new web platform features
| don't rot the foundations of any existing web apps,
| assuming they use specified features.
| bob1029 wrote:
| We've had a similar constraint issue on getUserMedia where it
| will return the lowest possible resolution for video by default
| instead of something more pedestrian. Setting exact constraints
| never seems to work correctly either. Ideal gets closer.
|
| It took us over a year to realize this was the root cause for
| 2D barcode scanning issues - we had an information-theoretic
| failure mode due to the low resolution.
| Etheryte wrote:
| Fyi I don't think this issue is limited to Safari, I've seen
| the exact same problem in some third-party apps which, as far
| as I can tell, look and feel native.
| vially wrote:
| Do you mean third-party apps on iOS? All web-based iOS apps
| are powered by Webkit/Safari so it makes sense that they all
| share the same bugs.
| Etheryte wrote:
| I mean third-party apps that are native, not web wrappers
| such as Cordova etc.
| donmb wrote:
| Safari is the new Internet Explorer. We need to face it.
| kingboss wrote:
| You meant to write Chrome.
| meibo wrote:
| Supporting iOS and macOS in webdev is an absolute nightmare and a
| big reason why I left that space and am not planning to go back
| until something fundamentally changes.
|
| It's clear that they're still trying to undermine the web where
| possible, without it seeming too obvious or getting them into hot
| water re: the recent monopolization debate.
| bzzzt wrote:
| While I get where the 'undermine' narrative is coming from,
| there are other, IMO more plausible, reasons why support is
| difficult:
|
| - Apple doesn't want others to dictate their development
| schedule.
|
| - Some Web standards clash with Apple's privacy promises.
|
| While I'd like Apple to do a bit more about those long standing
| bugs, I think the narrative they are actively undermining the
| web is short sighted. I prefer Apple's behaviour instead of
| Google's behaviour to actively monopolise the web...
| wswope wrote:
| Yes, thank you for speaking up to defend Apple's prerogatives
| here. No one should have to suffer through the ( _checks
| notes_ ) privacy violations and grueling six-year
| implementation timeline of adding a date picker input to
| their browser.
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/in...
| illiarian wrote:
| I wish HN had more complaints like this, and not the usual
| "whatever is the latest Chrome API of the day we need it in
| all browsers now!"
|
| ---
|
| As a tangent. If it was Apple of, say, 5-10 years ago, I'd
| also root for them to get their head out of their ass and
| lead in https://open-ui.org/ (started, of all people, by
| devs from Microsoft). Alas, with the way they approach
| interfaces these days, I'd want them far away from leading
| :)
| wdb wrote:
| Pretty confusing name when OpenUI5 already exists
| kouteiheika wrote:
| This does match up with my experience pretty well.
|
| Hopefully once the EU forces Apple to open up their app store I
| can just tell all of my users that Safari is unsupported and that
| they should switch to Firefox.
| Aaargh20318 wrote:
| They you'd lose me as a user. For me as a user Firefox is a
| terrible browser, it doesn't integrate well with the OS (e.g.
| no iCloud Keychain) and feels clunky but most importantly: I
| don't trust Mozilla. In the past they have on multiple
| occasions shown poor judgment [1][2][3] where they obviously
| prioritise making money over the interests of their users.
|
| For me, Safari is het only browser I truly trust, because Apple
| makes money from selling me stuff, instead from selling me.
|
| [1] https://www.theverge.com/2017/12/16/16784628/mozilla-mr-
| robo... [2]
| https://www.theverge.com/2021/10/7/22715179/firefox-suggest-...
| [3]
| https://blog.mozilla.org/advancingcontent/2015/05/21/providi...
| smoldesu wrote:
| It's alright if you prefer the way Safari works, but I
| wouldn't "trust" any browser. I certainly wouldn't only trust
| the browser made by a company that complies with 90% of
| government requests for account access:
| https://www.apple.com/legal/transparency/us.html
|
| A trustworthy browser holds itself accountable by making it's
| code transparent and it's intentions clear. Mozilla is
| terrible at marketing Firefox, but I'd argue they've built a
| much more amicable framework for the web than Apple has.
| kouteiheika wrote:
| > They you'd lose me as a user.
|
| To be quite honest, I don't care. I'm just a single guy
| working in his spare time; I don't have the resources to keep
| up with a trillion dollar corporation.
|
| I'm so done with the endless Safari-only hacks. I'm so done
| with having to push emergency updates because Apple decided
| to suddenly break half of my website in the newest version of
| Safari. And I'm so done with having to explain to my users
| that, yes, audio autoplay doesn't work on Safari, and no,
| it's not a bug, it's because Apple actively blocks it and
| won't let you decide for yourself if you want to enable it
| for my site, and all of that because they want to force me to
| build a native app (where I can autoplay to my heart's
| content) so that they can extort 30% of my income.
|
| > where they obviously prioritise making money over the
| interests of their users.
|
| ...and Apple doesn't do that?
|
| > because Apple makes money from selling me stuff, instead
| from selling me.
|
| Are you sure? https://proton.me/blog/apple-ad-company
| saithir wrote:
| We'll stop being sure when the ratio of ad revenue to
| hardware sales flips completely, yes.
| tgv wrote:
| And I hope they don't have to. Opening it up will move the
| entire web environment to Chrome, and Google's dominance.
|
| > I can just tell all of my users that Safari is unsupported
| and that they should switch to Firefox.
|
| What do you need from a browser that Safari doesn't support? In
| my experience, everything except obvious bugs has an easy work-
| around that is supported by the other platforms.
| jeroenhd wrote:
| > What do you need from a browser that Safari doesn't
| support?
|
| For me: a download for Linux or Windows so I can test with
| the browser. A macOS VM, like Microsoft used to provide for
| IE development, would also be acceptable.
|
| All my personal projects and even professional projects
| haven't supported Safari for this very reason.
| tgv wrote:
| True. There's browserstack.com, of course, but its free
| tier might not suffice.
| danaris wrote:
| In general, I much prefer Safari to other browsers (though
| Firefox is generally quite good too). However, I've been bitten
| by what _appears_ to be a WebKit bug in the latest update: using
| -webkit-mask-box-image to mask a div with an SVG shape no longer
| seems to respect the other sub-settings for that property,
| resulting in the mask being, at least for my use case, repeated 4
| times within the space that it is supposed to show once.
|
| I'm still investigating whether this is something that's actually
| changed with the not-exactly-spec for this WebKit-specific CSS
| property, but given the behavior I've already observed when
| trying to debug it, it certainly _seems_ like a regression.
| alkonaut wrote:
| I'm so happy I don't develop anything that targets web browsers
| or web servers. Yes deployments are a pain instead, but at least
| it's a known pain. Package the app and send it off.
| VyseofArcadia wrote:
| It's not limited to Safari. I used to work on a macOS desktop
| application, and we used to beg our customers to put off
| upgrading to new macOS versions to buy time to sort out all the
| undocumented behavior changes.
| timeimp wrote:
| Safari is to browsers today what IE once was: dread by those that
| have to support them.
|
| I am yet to meet competent developers who have ever given two
| hoots about "super fastest browser #1!!" blog posts over feature
| completed-ness / spec-compliance.
|
| I hope the C-level exec at Apple sees this and realises why more
| devs are going to go with Edge (lol) / Firefox support: the sales
| guys are running Apple now.
| Y-bar wrote:
| For me, a Firefox user, I don't share your point of view. I see
| a lot more "optimized for Chrome" or "run this in Chrome
| because that is the only browser we decided to support" because
| Google decided on implementing some feature of their own
| making. Never have I been hindered in my web browsing by
| something tailored to Safari.
| masswerk wrote:
| Also, typed arrays being slower than normal arrays for years
| on Chrome (and therefor pretty useless), Chrome breaking
| audio buffer playback for several major iterations, etc. This
| "whatever Chrome does is the standard" attitude reminds
| somewhat of the days of IE6 devs.
| masklinn wrote:
| Yeah the kids don't remember the bad days.
|
| It was not just that IE was broken in all sort of very odd
| ways, or that it was incompatible with the rest (and
| standard), or that it was essentially a monopoly.
|
| It was all three. So a site built for IE would not work at
| all in other browsers if it used anything remotely advanced
| (and advanced back then was users events), you _had_ to
| support IE to live (on anything but demo site), and doing so
| was hell on earth because the bugs went from top to bottom
| (the browser's _memory management_ had to be worked around,
| and there were no memory profiler, hell the debuggers only
| worked half the time).
|
| Not that it's any fun encountering a buggy browser, even less
| so when a feature is so broken you'd be better off if it were
| not supported and just did nothing or used a fallback and you
| now have to coerce it into that, and it does seem to be a
| recurring issue of safari.
|
| But it's no IE, at this point you'd need malice aforethought
| to get there.
| mason55 wrote:
| > _I am yet to meet competent developers who have ever given
| two hoots about "super fastest browser #1!!" blog posts over
| feature completed-ness / spec-compliance._
|
| I'd like to think I'm a competent dev.
|
| I use Safari as my daily driver because the difference in
| performance/battery life on Apple silicon is worth whatever
| small incompatibilities I run into. It just doesn't ever impact
| me on a day-to-day basis in the way that performance and
| battery life do.
|
| Good engineering is all about trade-offs and this is one that
| doesn't even require a second thought for me.
| myspy wrote:
| I use Safari as my main browser too. The features that link
| it between Mac and iPhone are very nice and easy to use.
|
| What also is cool in Safari is to zoom into a page so that
| everything gets bigger which makes it easier to read text or
| view pictures (not sure if this is the normal zoom a site
| has, or something on top OS wise). But a lot of sites are
| breaking that behaviour now, which results in either not
| being able to zoom or elements overlapping in weird ways,
| text not staying where it should. I wonder what CSS stuff is
| used there.
| manuelmoreale wrote:
| > Safari is to browsers today what IE once was: dread by those
| that have to support them.
|
| I mean, I don't think it's even close to beign modern day IE.
| Perfect? Far from it but definitely not as much of a pain as IE
| ihateyouall123 wrote:
| I think so
| squaresmile wrote:
| I think one thing that makes it IE-like is updates being tied
| to the OS. Asking the users to update an app is an easier
| sell than updating their OS.
| kergonath wrote:
| This is so far down the list of issues related to IE 6...
| If it's the worst aspect of mobile Safari, then there's not
| much to complain about.
| ezfe wrote:
| _raises hand_ I think I 'm a competent developer and I use
| Safari primarily. The number of times I've tried to build
| something and found out that Firefox or Chrome got halfway
| through the spec and then stopped working on it isn't 0 either.
| It goes both ways.
| NovemberWhiskey wrote:
| Nah. It's more like "Chrome is the new IE 6": it's the default
| target for everyone and you'd better be bug-for-bug compatible
| or else.
| philistine wrote:
| It's exactly what the article describes. Because Safari was
| correctly implementing something and not reproducing a Chrome
| bug, the dev is asking Apple to change their release
| structure to reduce their stress.
|
| This is the endgame of a monopoly. Other people start
| demanding others stop fairly competing with you.
| kingboss wrote:
| They are begging for their collars.
| robertoandred wrote:
| No real developer thinks Safari is comparable to IE, that's
| just something Google fans say.
| jojobas wrote:
| Why would they care what devs do? They are an infinitesimal
| minority. Their product are status/convenience for "normal"
| people, and they will use whatever browser Apple ships and if
| something breaks it's anybody else's fault. "If your Mac can't
| run it you don't need it".
| Grieverheart wrote:
| Nothing beats Safari in terms of battery usage, and there are
| features like the reading list that work really well (for me).
| For development, yes, I always have Chrome installed in case I
| needed it.
| brnewd wrote:
| I don't think this is still the case with Chrome 110 and
| higher that sleeps/suspends inactive tabs.
| PutinPoopin wrote:
| [dead]
| JoeOfTexas wrote:
| Apple doesn't want webapps to replace their app store. That is
| why they gimp the hell out of Safari.
| pveierland wrote:
| "Epiphany Technology Preview" is a WebKit build available for
| Linux which has been very helpful for testing Safari quirks
| without having macOS available.
|
| https://webkit.org/downloads/
| alex-moon wrote:
| In the job I'm currently in (doing front-end for the first time
| in many years) I can confidently say that every time we've had a
| bug that was browser-specific, that browser was some brand of
| Safari - usually Safari mobile, which shits me even more because
| the iPhone doesn't let users install any alternatives, i.e.
| literally what Microsoft went to court for. Reason enough on its
| own not to get an iPhone, or indeed any Apple product at all. I
| can only imagine how much Safari has cost the industry in wasted
| dev time.
| realusername wrote:
| Sometimes you can even tell it just from the sentry error text
| itself that it's a safari bug.
|
| It has a kind of distinctive feel of nonsense, I don't know how
| to explain it.
| vlovich123 wrote:
| Microsoft went to court over that because they were leveraging
| their OS monopoly into a browser monopoly. Microsoft always let
| you install alternatives by the waybut IE was the default and
| most people don't change defaults.
|
| Apple is not a monopoly unless you're just looking at mobile
| profits, which historically is not how a monopoly is defined
| (they're not even a monopoly in the luxury smartphone market).
| Android is actually much closer to being a monopoly and does
| all sorts of deals to maintain their monopolies on search,
| browsers, and Android which would warrant investigation. Now
| maybe a monopoly should be defined as % of total profits in a
| market? Not sure. It would be breaking new regulatory ground
| for sure.
|
| Also, from the sounds of it, Apple is going to be forced to
| allow third party browsers and app stores via EU regulation.
| It's less clear exactly how that will work and whether that
| will be available to customers in other jurisdictions.
| scarface74 wrote:
| I knew this bit of false internet lore was going to come up.
|
| Out of all the things that the justice system was throwing at
| MS, bundling IE was the least of them and absolutely nothing
| changed about browser bundling in the US. No there was never
| a browser choice mandate.
| vlovich123 wrote:
| That's true. The main focus was on forcing OEMs to bundle
| Windows for kickbacks. The browser stuff came out of the
| EU.
| scarface74 wrote:
| As is true with most laws involving tech and the EU.
|
| https://arstechnica.com/information-
| technology/2014/12/windo...
|
| > While there were early signs that the browser ballot
| screen was influencing browser usage in the EU, with
| Mozilla attributing some European Firefox growth to the
| selection page, long-term trends strongly suggest that it
| was next to useless. In spite of equally prominent
| placement on the selection screen, Opera's share even
| within Europe appears to have declined over the last five
| years. So too have Firefox and Internet Explorer. Chrome,
| however, has experienced significant growth.
| 411111111111111 wrote:
| > _Android is actually much closer to being a monopoly_
|
| Thats only true outside of the US though. iOS is >60% in the
| USA.
| vlovich123 wrote:
| Not sure where that number comes from. [1] indicates Apple
| broke 50% for the first time ever in Q3 2022. I doubt
| they've pole vaulted to 60% the past few quarters.
|
| [1] https://9to5mac.com/2022/09/02/iphone-us-market-share/
| kingboss wrote:
| Laughable take. When there was only IE6 people complained. Now
| that there is more than one people complain that they have to
| test their stuff more and wish to go back to one browser to
| rule them all. You don't like testing? How hard can it be to
| test on the top 3-4 browsers? Maybe it's not wasted dev time,
| it's called work? Maybe software industry isn't for you...
| Sidenote: Why so many snowflakes on HN? Too much entitlement or
| is it the easy money? In what job is it considered acceptable
| to not test on half the devices in the world?
| cxr wrote:
| I've run into a pretty ridiculous Chrome bug:
| let f = document.createDocumentFragment();
| f.appendChild(document.createElement("div"));
| f.firstChild.outerHTML = (`<a
| href="https://bugs.chromium.org/"></a>`);
|
| Fails because a fragment "is not an element node", a completely
| bogus error. No idea if it fails in Safari, too, since I don't
| have a Mac anymore, but I'd guess so, since this reeks of the
| type of corner-cutting that WebKit was guilty of while swimming
| in accolades for being a fast, standards-compliant browser
| engine (in contrast to e.g. Gecko).
| lapcat wrote:
| > a completely bogus error
|
| How is it bogus? outerHTML is an attribute of Element
| https://developer.mozilla.org/en-
| US/docs/Web/API/Element/out... and DocumentFragment is not an
| Element https://developer.mozilla.org/en-
| US/docs/Web/API/DocumentFra...
|
| > No idea if it fails in Safari, too
|
| It does.
|
| Have you considered that it's just a Gecko quirk that it
| happens to work in Firefox? Where do the standards say it
| ought to work?
| cxr wrote:
| > How is it bogus? outerHTML is an attribute of Element
|
| Re-read what is written. I'm setting the outerHTML property
| of an element, not setting it for the fragment (which is
| the only way that your response would make sense).
|
| > Have you considered that it's just a Gecko quirk that it
| happens to work in Firefox?
|
| No, because I'm not a moron.
|
| > Where do the standards say it ought to work?
|
| Exactly where you'd expect to find it: in the specification
| of the outerHTML property (Leithead et al. DOM Parsing and
| Serialization, Extensions to the Element interface, SS7.1
| Attributes: outerHTML. 2016.)
| lapcat wrote:
| See the Notes section of the docs: "If the element has no
| parent element, setting its outerHTML property will not
| change it or its descendants. Many browsers will also
| throw an exception." https://developer.mozilla.org/en-
| US/docs/Web/API/Element/out...
|
| The div has a parent node but no parent element, because
| a document fragment is not an element.
| LegionMammal978 wrote:
| The standard says that if the parent node is a
| DocumentFragment, then a temporary Element must be
| created to act as the context element for fragment
| parsing [0].
|
| [0] https://www.w3.org/TR/2016/WD-DOM-
| Parsing-20160517/#widl-Ele...
| lapcat wrote:
| Well, if Mozilla's own web developer API documentation
| contradicts the spec here, then I'd say that none of the
| browser vendors are doing on good job on this particular
| issue.
| LegionMammal978 wrote:
| To be fair, the Exceptions section on that page gives the
| correct criterion:
|
| > NoModificationAllowedError DOMException
|
| > Thrown if an attempt was made to set outerHTML on an
| element which is a direct child of a Document, such as
| Document.documentElement.
|
| So I'd say the Notes section is simply imprecise.
| cxr wrote:
| It's documentation. It's describing the Blink/WebKit
| behavior and couching it in terms of what "many browsers"
| do--it's not saying what they _should_ do; all you 've
| done is linked to a page that says the bug exists. Nice
| try moving the goalposts, though.
|
| It has been a monumental waste of energy participating in
| this conversation.
| LegionMammal978 wrote:
| That's not quite what it says; it says that
| (unconditionally) it will do nothing without a parent
| element and (conditionally, depending on the browser) it
| will throw an exception. The first part is inaccurate,
| since the standard behavior (which is the current
| behavior of Gecko and the intended behavior of Blink) is
| to let it work naturally on children of
| DocumentFragments. It should probably be updated to
| clarify this, but I wouldn't see the remark as very
| "normative" in the first place.
| LegionMammal978 wrote:
| > Where do the standards say it ought to work?
|
| The wording has not changed since the 2016 version of the
| DOM Parsing and Serialization standard [0]:
|
| > On setting, the following steps must be run: 1. Let
| parent be the context object's parent. [...] 4. If parent
| is a DocumentFragment, let parent be a new Element with
|
| > - body as its local name,
|
| > - The HTML namespace as its namespace, and
|
| > - The context object's node document as its node
| document.
|
| But Blink instead throws a DOMException with name
| "NoModificationAllowedError" and message "Failed to set the
| 'outerHTML' property on 'Element': This element's parent is
| of type '#document-fragment', which is not an element
| node." This was filed as a Chromium bug last December and
| assigned a week later [1].
|
| [0] https://www.w3.org/TR/2016/WD-DOM-
| Parsing-20160517/#widl-Ele...
|
| [1] https://crbug.com/1403060
___________________________________________________________________
(page generated 2023-04-03 23:02 UTC)