Re: Making pt a non-physical unit

On Fri, Jan 15, 2010 at 12:09 AM, Jonathan Kew <jonathan@jfkew.plus.com>wrote:

> On 14 Jan 2010, at 10:21, Robert O'Callahan wrote:> Define "truemm":
> > "truemm" is defined to correspond to physical millimeters in all media.
> For extremely small or large output surfaces, or when the physical media
> characteristics are unknown, the user agent may use an approximation.
>
> While I don't specifically object to this, I'm still not entirely convinced
> we need it at all. Thinking about the suggested use-cases...
>
> Touch interfaces: it seems to me that a touch-screen interface will in
> practice be designed specifically for a (fairly narrow range of) physical
> devices with known characteristics, and as such it could be done using the
> normal CSS units. If you design an interface for a cellphone screen, with a
> number of touch-sensitive UI elements (that need to be around 6mm high,
> let's say), and then move that application to a device with a screen twice
> the size, will it really make sense to use the same collection of interface
> elements at the exact same size as on the little phone? I doubt it.
>
> Thinking of devices I've used personally, my expectations for a
> "reasonable" button size on an iPhone screen is VERY different from a
> "reasonable" size for a functionally equivalent button on an airport
> check-in kiosk. And if I had a "full-size" tablet computer with a
> touch-screen interface, I wouldn't want the UI elements to remain the same
> physical size as they are on my iPod Touch. In general, I'd expect
> interfaces to be extensively redesigned for the different device sizes, but
> even if the same interface layout is used, I still don't think the actual
> element sizes should be fixed.
>
> For an application (such as a mobile/touch version of Firefox, for example)
> that is intended to be usable across quite a wide range of device sizes, I'd
> expect it to make most sense to design several versions of the user
> interface, optimized (not just in terms of dimensions, but also the overall
> layout, number of controls presented at once, etc) for different screen
> sizes. There might be a "small-phone UI", a "PDA UI", and a "tablet UI", and
> the application would either be built separately for different target
> devices, or use some kind of media-query to determine at runtime which to
> use. Within the range of "small phones", for example, a certain amount of
> variation in the UI element sizes according to the exact size of the screen
> seems perfectly natural and acceptable, IMO. People with really tiny screens
> surely expect tinier buttons; people with somewhat larger screens expect
> them to be easier to hit.
>

I think for applications where you're trying to cram as many UI elements on
the screen as you can, you may be right that customizing the UI for each
screen is desirable. However, there are other kinds of applications like
mapping --- and browsers --- where you have a small number of UI controls
and the rest of the screen real estate is dedicated to "content". For such
applications it seems to me it would be fine to use a single layout where
the UI controls have standard physical sizes.

Our mobile browser developers have specifically asked for physical units to
help them make their UI portable across devices. So whether or not they
*should* want this, the answer to "are there developers who want this?" is
simply "yes". (If there is no standard physical unit we'll probably have to
create "mozmm" or something :-).)

And as for "life-size diagrams", it's difficult to think of many realistic
> uses for this. If I'm reading a medical textbook on paper, a life-size
> drawing of the anatomy of the human hand might make sense, for instance.
> This still works if I'm reading it on my laptop - but if I read that same
> textbook on an iPhone, it's not much use. I'm much better served by a
> scalable drawing, with a "6-inch" ruler (also scaled, of course!) beside it
> indicating the actual size. In the unlikely event that I really, truly want
> to see the life-size bones on the phone, I'll need to zoom the display so
> that the ruler becomes physically accurate.... but I'm not convinced this is
> what people want or expect.
>
> For the laptop screen, where viewing the diagram at life size may indeed
> make sense, it could be the user agent's job to offer an "actual size"
> viewing option that renders 1px as 1/96 of a physical inch, if this is not
> its default - in other words, an option to scale the display in the same way
> as a printed version of the page. So no special CSS unit is required; the
> page is designed "for print", and a user who wants to see "true" dimensions
> simply asks the UA to display at "actual size". (And if the UA doesn't have
> the information needed to support this, then it also doesn't have the
> information to implement "truemm" accurately.)
>

I was thinking of applications like an instruction manual which includes
"life size" images of particular small components (e.g. nails and screws)
that you need to buy from a shop. That would be useful to have on your
phone.

I agree that a "life size" mode in the UA would be one solution, but that
doesn't give the author any control. "Please put your browser in 'life size'
mode to view this page" sounds lame :-).

I agree that these use cases are marginal and "truemm" wouldn't --- and
shouldn't --- be used very much. But it's low effort.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]