Which engine would need to learn this? The web browser (Fennec, MicroB, or whatever) receives coordinates where the input device clicked after which it decides to act upon this input, or not. So it already has to do that. If the hyperlink top left is at X = 50, Y = 30 and you want to zoom in if its 20 pixels off then if the touched coordinates are 50 - 20 >= 30, 30 - 20 >= 10 it should zoom in. That counts for every corner, but it also already has to do this in order to know a link is clicked. So it doesn't seem to be that much more complex than currently except that now there is also zooming which indeed does cost some resources, but with a hardware 2D/3D driver and because furthermore no other applications is focussed upon, this is neglectable.

when you press mouse button down, the browser has to decide whether you hit a link or not.
If you hit the link it gets highlighted and follows that path, if not it enters scrollmode (because you hit the element behind)

if the ui keeps jumping and dancing around because it cannot decide whether you are near a link or wanting to scroll we are in bigger trouble.

On an unscrollable keyboard its less of a problem, but because the ui interaction on a webpage is already multifunction it will cause complications.

Of course this wont stop us from trying and seeing and it might actually work really well, i'm merely playing devils advocate.

You make a good point, and it isn't as simple as I put it. The implementation makes touchscreen-based scrolling (especially with finger) more unusable.

When I use Fennec or MicroB to browse Slashdot this is already a problem. In the middle are all the items on the day. On the left is either categories (with links) or banners, or white space. On the right the same situation. So wherever you try to scroll there are always risks you're clicking on a link. Now if every link would suddenly become 20 pixels in each direction (top, right, bottom, left) wider it'd be even harder to scroll up or down.

But one can maybe notice if the user is scrolling or attemping to click a link. I'm not sure, but if one is scrolling I would say the finger makes a movement after a very short (say it is 100ms) moment of time whereas if the user wants to press a link she is more firm. That is where I want to go to. So there is hardly any, if any at all, movement in that case.

allnames,
in liqbase on the graffiti wall I have implemented the scrolling to allow both scrolling and selection.

If the selection area is <25 pixels (or some arbitrary figure) when mouseup occurs its taken as if it was a selection (the click event is raised in this instance).

Scrolling is however enabled all the time and happens live, its rare that the 2 distinct actions are misidentified.

This seems to work quite well but I would be nervous about mixing scrolling with zooming, and is the primary reason why I have not implemented the physics type movement within the live graffiti wall (my original idea was to allow physics sketch zooming confined within each day boundary).

this is what I hope to achieve with multiselect and kinetic scrolling.

(example is actually for the tagging selection, but it shows what I mean)

Hmm... spade, eh? I guess you could call it that, but you just contributed to the problem...

I'm not a big fan of this click-zooming in a web-browsing context; it seems too disruptive of the whole screen in case of accidental interaction, and not useful enough for intentional interaction. I'd prefer simply enlarging links (by less than 20px, but that's details), as can be done now with CSS, but with smarter handling for the case where two enlarged links overlap. (It should go with the pseudo-geometrically closer one, not go the "later" one. Pseudo- indicates the possibility to weight things; e.g. if you click on the overlap of a tiny link and a huge link, odds are you meant the tiny link; you'd have clicked away from everything else if aiming for the huge one.)

that seems reasonable, even if we simply allow a customizable border region for the user to setup.

http://www.youtube.com/watch?v=jT3_UCm1A5I

WTF???...........O....K?

The Fremantle release will certainly improve on the scrolling issues. Don't expect fat scrollbars, for one.

Anyway, about the main issue: for the size detection, there were many reasons for removing it - some rather technical and unfortunate realities - but I guess it boils down to making choices about the UI. We're going towards finger usability. It is certainly not trivial to design two good UI's for the same amount of information or contents. Yes it can be done in some pre-defined cases, but to have it system-wide and as a functionality that scales as an indefinite amount of extra information is added to the UI, not so well anymore.

The harder you try to hold on to dual support for stylus and thumb, the more you are constrained in your thinking about what would be a good touch UI. Take any issue. Take multitouch, for instance. If a device would plan to support multitouch properly - and multitouch has not been announced for any release or device - you cannot really do it, if you must also ensure that your designs work with a single touch, i.e. stylus. You can do some "additional nice stuff" with multitouch in a situation like that, but cannot change any core UI thinking.

Also widgets, the UI components. If supporting a stylus, you can still cling on to components like checkboxes, scroll bars etc. With a dual UI, allowing components like that will mean that those will get used, and therefore there should be two versions of those, and usually the finger based alternatives being the "suboptimal" ones of those two.

Finger vs. stylus halves the amount of UI space available for a given UI. It is not possible as a system-wide issue to design UI's for all the applications that would be 'optimal' for both stylus and the finger at the same time, unless nearly doubling the design and implementation effort.

So for "it could have been as simple as that", I don't agree.

i keep being reminded of something that came to mind when i first started reading about touch screens. a finger friendly ui also work with a stylus or mouse, a mouse friendly ui may work with a stylus, but will never work with fingers.