Bug 33324

Created attachment 46057 [details] Add bounding box rectangle sizes to touch point DOM objects

style-queue ran check-webkit-style on attachment 46057 [details] without any errors.

Created attachment 46105 [details] Touch point bounding box, updated Badly timed preparation for that earlier patch. This one is against the current HEAD.

Created attachment 46106 [details] Touch point bounding box, try 3 ...and that one got diffed incorrectly, and changelog whitespaces were munged. Fixed.

style-queue ran check-webkit-style on attachment 46106 [details] without any errors.

David, Ben: Any thoughts on adding these properties to the JS API?

(In reply to comment #6) > David, Ben: Any thoughts on adding these properties to the JS API? I don't see any harm in adding these properties. However Android does not support touch point bounding boxes so on Android they will always be empty (I see from the QTouchEvent::TouchPoint API that for the rect() function there is a note "This function returns an empty rect if the device does not report touch point sizes.") Looking at the patch, I see that the basic touch test has been augmented with the bounding box information. Would it be possible to move it into it's own test so that we can skip it on Android? Cheers, Ben

(In reply to comment #7) > Looking at the patch, I see that the basic touch test has been augmented with > the bounding box information. Would it be possible to move it into it's own > test so that we can skip it on Android? Certainly, I'll prepare a new patch that does that.

Created attachment 46905 [details] Touch point bounding box, try 4 Touch point bounding rectangle with a new test for it, along with some additional minor changes in the implementation compared to the previous patches.

Just to be pedantic here. A point does not have a bounding rect... When creating JS API you want to support for years to come you should consider this...

Comment on attachment 46905 [details] Touch point bounding box, try 4 I don't think we want to add the feature at this point to the mainline WebKit - The touch event API is completely new and not yet standardized. I think it is better to have a compact API covering the most important use cases first and gain some experience before piling in new features. - Use cases for the feature are not clear so it is hard to evaluate the proposed API. If the main use of the feature is obtaining the strength of the press, would it be better to express that directly as a single number? If the touch shape is really important isn't an axis-aligned bounding rect too coarse grained way of describing it? - Platform support is limited (per comments above Android can't do it for example) - As zecke pointed out, the concept of point bounds is nonsensical. r- on these grounds.

I close the bug. This is still being discussed in standardization. We can open a bug later when the draft is in a better shape.