5 ms·

> 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

> 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.

idle_zealot 8y ago
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.
azinman2 8y ago
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).
- weberc2 8y ago
  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).
  - geden 8y ago
    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.
- birdman3131 8y ago
  But if they are testing on iphone they are probably writing it as a mobile page which usually suck anyways.
- singlow 8y ago
  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.
- iaml 8y ago
  I have personally experienced this bug https://stackoverflow.com/questions/46309641/what-happens-in-safari-with-the-transparent-color https://stackoverflow.com/questions/46309641/what-happens-in....
  - bunnycorn 8y ago
    That's not a bug. "transparent 0" is not a standard way of defining things, and bad use o CSS in production.
    - iaml 8y ago
      It works like that regardless of presence of percents, I had it with "linear-gradient(transparent, white);".
- zuzun 8y ago
  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.
  - ksec 8y ago
    Yes, I really wish Webkit, or may be Safari improve on this.
- lowkeyokay 8y ago
  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
- bunnycorn 8y ago
  Probably nothing, since it's more a meme than anything else.
- Phillips126 8y ago
  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-search-no-longer-shows-cancel-button-x-under-ios https://stackoverflow.com/questions/35583503/input-type-sear...
  - dak1 8y ago
    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/input/search 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.
    - Phillips126 8y ago
      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-guidelines/ios/bars/search-bars/ https://developer.apple.com/design/human-interface-guideline...
drenvuk 8y ago
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.
- irrational 8y ago
  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).
  - emerongi 8y ago
    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.
    - AsyncAwait 8y ago
      Just wanted to say thanks to everyone targeting Firefox first.
      - godDLL 8y ago
        We all probably have Firefox DE for the Dev Tools. And main browser is Chrome or Safari.
- danpalmer 8y ago
  I'm not saying that Safari is correct, just that developers often already develop for just Chrome.

idle_zealot 8y ago

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.

azinman2 8y ago

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).

weberc2 8y ago
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).
- geden 8y ago
  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.
birdman3131 8y ago
But if they are testing on iphone they are probably writing it as a mobile page which usually suck anyways.
singlow 8y ago
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.
iaml 8y ago
I have personally experienced this bug https://stackoverflow.com/questions/46309641/what-happens-in-safari-with-the-transparent-color https://stackoverflow.com/questions/46309641/what-happens-in....
- bunnycorn 8y ago
  That's not a bug. "transparent 0" is not a standard way of defining things, and bad use o CSS in production.
  - iaml 8y ago
    It works like that regardless of presence of percents, I had it with "linear-gradient(transparent, white);".
zuzun 8y ago
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.
- ksec 8y ago
  Yes, I really wish Webkit, or may be Safari improve on this.
lowkeyokay 8y ago
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
bunnycorn 8y ago
Probably nothing, since it's more a meme than anything else.
Phillips126 8y ago
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-search-no-longer-shows-cancel-button-x-under-ios https://stackoverflow.com/questions/35583503/input-type-sear...
- dak1 8y ago
  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/input/search 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.
  - Phillips126 8y ago
    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-guidelines/ios/bars/search-bars/ https://developer.apple.com/design/human-interface-guideline...

drenvuk 8y ago

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.

irrational 8y ago
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).
- emerongi 8y ago
  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.
  - AsyncAwait 8y ago
    Just wanted to say thanks to everyone targeting Firefox first.
    - godDLL 8y ago
      We all probably have Firefox DE for the Dev Tools. And main browser is Chrome or Safari.
danpalmer 8y ago
I'm not saying that Safari is correct, just that developers often already develop for just Chrome.