6 ms·

I’ve heard that before. It’s still fair to blame Google for the whole fiasco. Especially since the non-AMP versions had always worked fine.

by bdhess 9y ago

lern_too_spel 9y ago
Why not blame Apple for building a buggy browser that you have no choice but to use? Stop buying buggy user-hostile phones. AMP pages work perfectly fine in Firefox for Android.
- davepeck 9y ago
  Let’s say you’re an engineer about to roll out a feature to (literally) a billion users. Through testing, you know your feature is busted for the ~14.5% of your users who use Safari. But it’s not your fault! Apple should fix it. Quick quiz: do you release a feature that is broken for 145M users, which brokenness they might plausibly encounter multiple times a day? In a typical organization, the answer would probably be an unambiguous “no”. Without passing judgment, I find the fact that Google decided to ship anyway to be a useful indicator of their beliefs, culture, and priorities.
  - lern_too_spel 9y ago
    You could turn that around and ask why Apple didn't bother to fix something that was causing pain for some of their users and continued not to fix it after it was causing pain for most of their users. Google made a bad engineering decision, but I would place most of the blame on Apple. It's the same for IE and web applications that didn't work in that browser. Luckily, people (for the most part) stopped using IE. We can only hope that iOS Safari will share that fate.
    - davepeck 9y ago
      It doesn’t feel equivalent to me; I tend to think that there’s a meaningful distinction between a bug known before shipping and a bug discovered after. That said, it’s fair to ask why Apple hasn’t placed priority on the scrolling bug, post-AMP. What the real dynamics are I can only guess; I’d love to hear from lurking AMP or WebKit engineers.
      - dwaite 9y ago
        The three main issues are that scrolling behavior was busted, clicking on the top bar doesn't scroll to the top like it does in all other scroll views in the system, and the URL bar doesn't show the 'real site' so links shared via the built-in mechanism are links to google, not to the actual site content. All three of these are Google not taking into account mobile browser design. None of these can really be classified as issues in Safari, rather they are consequences of the Safari design and the design choices Google made. The first two are due to the content being embedded within an iframe. The scrolling issue was partly because Safari implemented custom scroll behavior (supposedly due to a Steve Jobs request) for its main web view, but scrollable iframes did not override the scrolling behavior. The fix here (I believe it was rolled out in iOS 11) was to change system-wide behavior for Safari to use the system default scrolling behavior, so that everything behaved the same. The title bar issue is due to the content not being a scroll view, but a view the size of the screen containing one or more scroll views (the iframes). Which of these should be scrolled to the top on a tap? Changing this behavior could change it for deployed sites, so rolling out any sort of new heuristic requires testing and probably wouldn't be done outside a new major version (e.g. iOS 12). The third issue is across all browsers - Google is the one serving the content, not the third party that wrote the content. Because of this, any attempt to change where the browser 'thinks' a page is being served to another domain runs afoul of pretty fundamental web security principles. You might be able to design some sort of call (similar to CORS) to ask if google is representing your content in order to get permission to forge the address, but that would be a new web standard that hasn't been written yet.
        saurik 9y ago
        Google should have just not used a scrolling iframe. MobileSafari has this beautiful quirk that iframes greater than 8 pixels tall automatically expand to the size of their content, solving all of the awkward coordination problems of sizing the iframe. It would have been just so damned simple for Google to fix this in MobileSafari :/.
        kuschku 9y ago
        That's certainly an interesting quirk, I've never heard of it, nor seen it in another browser. Definitely useful, though, why isn't that a feature in HTML5?
- bdhess 9y ago
  I’m not going to switch my browser or my hardware platform over some trivial bug that only surfaces on one website. I’m just not going to visit that website.
  - lern_too_spel 9y ago
    > I’m not going to switch my browser Don't blame anybody else for your poor choices. If you choose to use IE 6 or iOS, don't cry if the world doesn't bend over to support your buggy platform. Work within the shrinking confinements of your platform.

I’ve heard that before. It’s still fair to blame Google for the whole fiasco. Especially since the non-AMP versions had always worked fine.

by bdhess 9y ago

I’ve heard that before. It’s still fair to blame Google for the whole fiasco. Especially since the non-AMP versions had always worked fine.

lern_too_spel 9y ago

Why not blame Apple for building a buggy browser that you have no choice but to use? Stop buying buggy user-hostile phones. AMP pages work perfectly fine in Firefox for Android.

davepeck 9y ago
Let’s say you’re an engineer about to roll out a feature to (literally) a billion users. Through testing, you know your feature is busted for the ~14.5% of your users who use Safari. But it’s not your fault! Apple should fix it. Quick quiz: do you release a feature that is broken for 145M users, which brokenness they might plausibly encounter multiple times a day? In a typical organization, the answer would probably be an unambiguous “no”. Without passing judgment, I find the fact that Google decided to ship anyway to be a useful indicator of their beliefs, culture, and priorities.
- lern_too_spel 9y ago
  You could turn that around and ask why Apple didn't bother to fix something that was causing pain for some of their users and continued not to fix it after it was causing pain for most of their users. Google made a bad engineering decision, but I would place most of the blame on Apple. It's the same for IE and web applications that didn't work in that browser. Luckily, people (for the most part) stopped using IE. We can only hope that iOS Safari will share that fate.
  - davepeck 9y ago
    It doesn’t feel equivalent to me; I tend to think that there’s a meaningful distinction between a bug known before shipping and a bug discovered after. That said, it’s fair to ask why Apple hasn’t placed priority on the scrolling bug, post-AMP. What the real dynamics are I can only guess; I’d love to hear from lurking AMP or WebKit engineers.
    - dwaite 9y ago
      The three main issues are that scrolling behavior was busted, clicking on the top bar doesn't scroll to the top like it does in all other scroll views in the system, and the URL bar doesn't show the 'real site' so links shared via the built-in mechanism are links to google, not to the actual site content. All three of these are Google not taking into account mobile browser design. None of these can really be classified as issues in Safari, rather they are consequences of the Safari design and the design choices Google made. The first two are due to the content being embedded within an iframe. The scrolling issue was partly because Safari implemented custom scroll behavior (supposedly due to a Steve Jobs request) for its main web view, but scrollable iframes did not override the scrolling behavior. The fix here (I believe it was rolled out in iOS 11) was to change system-wide behavior for Safari to use the system default scrolling behavior, so that everything behaved the same. The title bar issue is due to the content not being a scroll view, but a view the size of the screen containing one or more scroll views (the iframes). Which of these should be scrolled to the top on a tap? Changing this behavior could change it for deployed sites, so rolling out any sort of new heuristic requires testing and probably wouldn't be done outside a new major version (e.g. iOS 12). The third issue is across all browsers - Google is the one serving the content, not the third party that wrote the content. Because of this, any attempt to change where the browser 'thinks' a page is being served to another domain runs afoul of pretty fundamental web security principles. You might be able to design some sort of call (similar to CORS) to ask if google is representing your content in order to get permission to forge the address, but that would be a new web standard that hasn't been written yet.
      - saurik 9y ago
        Google should have just not used a scrolling iframe. MobileSafari has this beautiful quirk that iframes greater than 8 pixels tall automatically expand to the size of their content, solving all of the awkward coordination problems of sizing the iframe. It would have been just so damned simple for Google to fix this in MobileSafari :/.
        kuschku 9y ago
        That's certainly an interesting quirk, I've never heard of it, nor seen it in another browser. Definitely useful, though, why isn't that a feature in HTML5?
bdhess 9y ago
I’m not going to switch my browser or my hardware platform over some trivial bug that only surfaces on one website. I’m just not going to visit that website.
- lern_too_spel 9y ago
  > I’m not going to switch my browser Don't blame anybody else for your poor choices. If you choose to use IE 6 or iOS, don't cry if the world doesn't bend over to support your buggy platform. Work within the shrinking confinements of your platform.