Hacker News Reader

Comment by danpalmer | Hacker News Reader

> I'm assuming I'm not the only one who's afraid of Blink becoming the new Internet Explorer; instead of people following a web standard, they'll follow what's Chrome-compatible.

This is already the norm. I use Safari and find many sites have issues. Before that I used Firefox and many sites had issues.

Typically the JS works, but styling often looks different (and worse) on Safari and Firefox.

View on HN

I can say wholeheartedly that it's Safari that's the problem, not Firefox or Chrome. I develop for Firefox first and have no issues with Chrome but Safari is requires some special tricks repeatedly.

I'm the same way. Firefox first, then Chrome. If it works on Firefox, it will work on Chrome (and least that has been my experience).

There are occasional inconsistencies. Just this week I fixed a small styling issue that differed between Firefox and Chrome.

I develop for Firefox first as well.

Just wanted to say thanks to everyone targeting Firefox first.

We all probably have Firefox DE for the Dev Tools. And main browser is Chrome or Safari.

I'm not saying that Safari is correct, just that developers often already develop for just Chrome.

Do you have examples? I use Safari and don’t find this to be true. Given Safari is what people use in iOS, id expect this to be rarely the case (most sites will test on an iPhone).

Same here; I don't know if I've ever seen a site that works in Chrome but not Safari (I don't doubt they exist, I just don't tend to come across them).

As a MacOS Safari 12 user, I've recently come across several important sites where some functionality fails hard in Safari yet works in Chrome ie barclays.co.uk and easyjet.com

I don't have any proof but my suspicion is that I've seen more sites failing Safari since Mojave.

I really dislike (& distrust!) using Chrome now, especially for e-commerce sites or anything with SMS based 2FA as Safari's ability to pull codes automatically from messages is a godsend.

But if they are testing on iphone they are probably writing it as a mobile page which usually suck anyways.

Cant come up with example but i have fixed quite a few safari issues as a web dev. Often they dont appear on iphones because the media queries for mobile are tested on iphones, but desktop layouts are tested on chrome. Safari had a few flexbox quirks that caught me out most recently.

I have personally experienced this bug https://stackoverflow.com/questions/46309641/what-happens-in....

That's not a bug.

"transparent 0" is not a standard way of defining things, and bad use o CSS in production.

It works like that regardless of presence of percents, I had it with "linear-gradient(transparent, white);".

In my experience it's easy to brick Safari and other WebKit-based browsers with CSS animations that run at 60fps and <10% CPU on Chromium and Firefox.

Yes, I really wish Webkit, or may be Safari improve on this.

I have seen this many times during development. Noteworthy sites that cause problems are, well, Microsoft sites: portal.azure.com - problems downloading publish profiles. SharePoint - too many to mention

Probably nothing, since it's more a meme than anything else.

I created an internal application for our company to use that is essentially a directory of staff members. I do most my development in Chrome but the bulk of the users are on iOS (Safari). I always find little nuances that I need to tweak for things to be "just right" on Safari. One example is that in all other browsers (including Safari Desktop) a <input type="search"> will show a little clear button ("X") at the end of the input. Some bug removed it from iOS Safari and we're still waiting for them to resolve the issue. It was reported in 2016 and was acknowledged by Apple [1]...

[1] https://stackoverflow.com/questions/35583503/input-type-sear...

There's nothing in the spec that promises you a little "x" to clear the value: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

Chrome also frequently attempts to cover up incorrect code with what it thinks the author probably meant. Firefox tends to be much better than Chrome at following the actual spec.

I tend to develop primarily with Chrome first for some different reasons (ability to disable CORS, support for self-signed certs with WebSockets, and its better debugging of WS frames), but I always make sure to test later with Firefox and Safari, and occasionally find code that worked in Chrome, but doesn't elsewhere, and the reason is almost invariably always that Chrome didn't follow the spec.

Fair enough about it not being in the spec. It does appear to be a part of Apples' "Human Interface Guidelines"[1], although these guidelines are pointed to native applications. It was just an unexpected regression that occurred during the rollout of iOS9 and is an example of one of the little nuances that caused me to do something different. I've had some other issues regarding scrolling and focus, but this one seemed to be easier to talk about.

[1] https://developer.apple.com/design/human-interface-guideline...

I run into the cause of this issue quite a bit when writing styling. The fact is that each major browser veers from the spec in its own unique ways, so if you're testing your page in a single browser (usually Chrome, though personally I use FF) the styling will often end up working differently in other browsers. As of now, the only real solution is to pick a set of "supported browsers" and to test your page in each of them before publishing, tweaking your styles to work around each engine's quirks. The problem with a browser monoculture is that it encourages developers to only test against the dominant platform, forcing competitors to be bug-compatible in order to provide a non-broken experience. The advantage is that a true and reliable standard would emerge, making developers' lives easier. Of course, the optimal solution would be for browsers to properly conform to the existing standards so that testing across browsers wouldn't be necessary in the first place, as any deviations would be a bug that would hopefully be fixed before too long.

Reply on news.ycombinator.com