16 comments

  • Razvan HRazvan H, 8 years ago

    Only for pages with unscalable viewports. I hope this doesn't mean more websites will have pinch to zoom disabled

    7 points
    • Oliver PattisonOliver Pattison, 8 years ago

      Not surprisingly, Jeremy Keith has something to say about this. If implemented, it definitely means that more websites (masquerading as apps) will be encouraged to turn off user zooming. Modern web design and development focuses so much on control, but this control is being wrested from people using the web.

      3 points
      • Elliott ReganElliott Regan, 8 years ago (edited 8 years ago )

        Before reading the article, by opinion is this:

        While this may be taking control away from the user, it is providing a faster experience, which most people are going to expect from their faster devices. Fewer and fewer sites theses days have a need to zoom in, and doing so would actually end up hiding information, instead of making it easier to see. I think it's a bout time developers get the control to choose which experience their users will have.

        A nice middle ground would be to add an option in the accessibility settings to turn zooming back on.

        2 points
        • Oliver PattisonOliver Pattison, 8 years ago (edited 8 years ago )

          That link is actually just a Twitter conversation so it may not be that illuminating. I think the whole problem is that the viewport as specified overrides user settings. I think as long as the user can have final say on output without too much effort, this could be far less of an issue – definitely a possible middle ground. And yes, performance is a huge contributor to usability too, so any way that we can have both would be a better solution. The proposed Webkit solution seems to favor rigidly inaccessible design to improve performance, though – at least as viewports exist today.

          Jeremy actually offered solutions for this issue way back in 2013 when it was Blink trying to solving it. He suggested a delay on only non-focusable elements. That would require more semantic markup than the average website UI has, but it’s another possible solution. The web is entirely about finding the middle ground!

          0 points
  • Oz PinhasOz Pinhas, 8 years ago

    About time! Any idea when it will be shipped? Guessing iOS 9.1 tho Apple doesn't tend to ship Safari "features" in minor releases, so crossing fingers we're not doomed till next September

    2 points
    • Marc EdwardsMarc Edwards, 8 years ago

      Apparently it's still being discussed and not planned for release any time soon. It’s a tough problem to solve well, so I'm glad they’re taking their time with it.

      3 points
      • Elliott ReganElliott Regan, 8 years ago

        They also added the Vibration API to webkit at some point, but that never made it into Safari.

        0 points
  • Anselm UrbanAnselm Urban, 8 years ago

    Now that´s good news.

    0 points
  • Will FroelichWill Froelich, 8 years ago

    I just use this pattern for sites that I want to get rid of that delay

    var clickOrTap = ('ontouchstart' in document.documentElement) ? 'touchstart' : 'click'; $("#thing").on(clickOrTap, function(){ ...

    Which let's me support desktop & mobile while maintaining double click or other gestures.

    0 points
  • Ivar Sylvester, 8 years ago

    ELI5?

    0 points
    • Valtteri KarestoValtteri Karesto, 8 years ago

      There's 350ms delay when you tap for example a link in webkit browser. In the future this will be removed. Delay exists so browser can differentiate between tap and double-tap events like David and Marc above described. Delay will be removed only if you have disabled page zoom.

      2 points
      • Hans van de BruggenHans van de Bruggen, 8 years ago (edited 8 years ago )

        This will make web apps behave more like native apps. There is concern that websites will use this to improve speed at the cost of accessibility.

        The intent seems to be for improving the performance of web apps.

        1 point
  • Robert Deniszczyc, 8 years ago

    Anyone think of a reason why this is only applied to unscalable viewports?/Why is there a delay built-in in the first place?

    0 points
    • David Barker, 8 years ago

      I believe it's there to allow for the detection of a double-tap (which alters the zoom level) vs. a single tap.

      6 points