Web developers need to concentrate on clear and effective communication. By all means present attractive pages that are viewable and useable for a wide variety of host environments but let users deal with device related issues such as different sized screens, number of pixels, aspect rations, dot densities and so on themselves.

For example, my eyesight isn’t what it used to be so zooming is very important when using Mobile Safari. Therefore it is extremely annoying when a site is configured to prevent zooming. A designer can’t know every visitor’s circumstance and can’t accommodate them all specifically, so instead they should try to allow as much freedom as possible when the site is viewed. Taking control of resolutions, orientation, font sizes, whatever is obstructive and thoughtless. Just don’t do it.

“The classnames are terrible of course, but were used purely for clarity in the demos. I definitely don’t recommend using names like that in production.”

A few years ago somebody wrote a great research paper, Design Fragments Make Using Frameworks Easier, that studied 36 code samples found on the Internet, used in open source projects, and showed they all were traceable back to code samples on Sun’s developer website, and that some of the demo code contained sub-par coding practices.  The number of users affected by these sub-par coding practices cannot even be counted.

Bottom line: You should always provide code with your name on it that you would drop-in to production.  Hope this comment changes your practices going forward, and that you will always post production-ready samples.

That button looks cool.

Though for the technical advice, I can’t completely agree.

Citing Wikipedia for Ems is fine for amateurs but for a technical publication such as this one, any CSS specification should do (CSS 2.1 – lengths).

Using ems is right, but the rest is no good.

“Currently, in Sencha Touch, we use Javascript user-agent sniffing to detect the device”

Such technique is limited to today’s devices. Where it works, it cannot be expected to be forwards-compatible.

I’m not convinced that the iPhone is scaling undesirably. Sure, it’s inconsistent with iPad, but iPhone users are used to it being smaller on the smaller iPhone.

Use class with semantics in mind. textsize_2x is not a semantic class.

Thanks, and… really, thanks!

=)

Anyway pretty interesting idea.

http://www.helephant.com/wp-content/uploads/2009/08/svg1.html

for example.  But if you’re going to deal with background images in some non-SVG way, even better.

* I do use the occasional px measurement in Sencha Touch, but only for borders/highlights. These could/may become ems, but ultimately, it’s not the worst thing, as they’re all ‘1px’ and just trying to say “the smallest unit possible,” in a sense (ie. A 1px highlight at the top of a tab). Other places where you see px are likely just in the process of being refactored.
* Using ems and SVG are somewhat different, so the fact that Sencha Touch will not _rely_ on SVG in the near future doesn’t affect that we’ll continue using ems for sizing.

Hope that helps answer your questions-