Thank you! The worst is when pinch-to-zoom is disabled on an image viewing/sharing page. I believe Twitter is guilty of this. It's idiotic.

I've also heard many arguments that responsive design makes pinch-to-zoom unnecessary. A page should automagically adjust so that it's optimal for a 27" monitor, a 2" mobile display, or anything in between. It's a great idea in theory, but I've yet to see it executed well in practice. I guess it's exceedingly difficult to design an effective UI that can automatically and seamlessly scale between a large-format screen and a small-format screen.

In some browsers, removing the ability to zoom removes the 300ms delay that the click event has before it fires.

You can use 'touchend,' but in certain cases this causes another set of bugs because the click event follows anyway.

To fix this in a cross-browser way, you need to write some extra logic. There are several implementations floating around of various quality.

  > Html is elastic by nature, and html 5 will win over
  > native apps because it is elastic.

HTML won't win anything, first and foremost because it is not fighting anything. And HTML is neither elastic or inelastic. Calling HTML elastic is like calling an idea "green and wet". HTML is for marking up structure of the document (I am ignoring a couple of presentational attributes in HTML, but they should be ignored). CSS tells the browser is something is elastic or not.

But all that has nothing to do with winning or loosing. Users don't give a shit if it is elastic or rigid. Does it work smoothly? Great. Does it look great? Superb. Was it coded with HTML/CSS/JS? Who cares… unless it impacts the first two.

> HTML won't win anything, first and foremost because it is not fighting anything. And HTML is neither elastic or inelastic. Calling HTML elastic is like calling an idea "green and wet". HTML is for marking up structure of the document (I am ignoring a couple of presentational attributes in HTML, but they should be ignored). CSS tells the browser is something is elastic or not.

I think everybody here understands that, and the parent was using it as a shorthand for "the set of technologies commonly used in hypertext documents on the Web." It is not productive to issue a correction every time you encounter synecdoche.

Actually, users don't give a shit either at how it looks or even if it works smoothly. They just care positively about content and entertainment, look at Wikipedia, Minecraft, early Google.

But they also care negatively if something is getting in their way. That's why headers carved into gif images and flash for text and any other mean to force text size upon user are less and less used on the desktop.

So why should it be current on my phone?

"HTML is for marking up structure of the document" - exactly. The trouble starts when you start trying to use it for app's GUI.

I too hate the disabling of pinch-to-zoom on websites. Chrome on my Android phone has the wonderful feature (in accessibility settings) that allows you to always pinch-to-zoom (overriding the sites viewport declaration).

Until recently I too disabled pinch-to-zoom because it introduces so many bugs on every mobile browser I have tried - see my comments here: http://stackoverflow.com/a/10747648/436776

And on an iPhone or Android app, you can't pinch-to-zoom.

Pinch to zoom isn't that applicable on mobile-optimised webapps. If you have a fixed header on the top of the page what would pinch to zoom do? Make the header bigger? Or would it ignore the header and just zoom in on the body content?

This is tangential to the pinch-to-zoom discussion, but I'd say if you have a fixed element anywhere, you don't have a mobile-optmised webapp. There are plenty of Android devices with 640x480 or 320x240 out there; a fixed header in one of them looks like a big waste of screen space.

Huh? Do you regard the title bar at the top of native Android apps to also be wasted space?

Depending on the application and the space available, yes. That's why some aren't fixed, and some are hidden once you scroll after a certain point.

I think he point is that the title shouldn't be fixed but dynamic to the device.

Ah, well, I meant fixed in the CSS sense rather than the "exact size" sense.

You are not too far from carving your header in a JPEG file there. Some may remember good ol' times when most web sites did so. It was the same reason: someone decided the size must be fixed for the header to be following a fixed grid or corporate design paper, or something the like.

You couldn't select the text, it was heavy, ugly, hackish, crawling against the grain of HTML, which is elastic. Now we know better, and let content flow, adjust itself, at the will of the users (on the desktop).

This was the Dark Ages of the Web, why do we need to go through the same lows on mobile?