iPhone Safari CSS positioning bug

19 views
Skip to first unread message

wayne

unread,
Nov 11, 2007, 12:49:08 PM11/11/07
to iPhoneWebDev
The CSS positioning of TEXTAREA using position:relative
or position:absolute (:fixed doesn't work either) cause
editing caret to leave the text area and do a kind of
"invisible" editing outside, as shown by the example
below. Desktop Safari 3 works fine. Any workarounds?

<html>
<head><title>TEXTAREA bug</title>
<meta name="viewport" content="width=device-width; initial-scale=1;">
</head>
<body>
Below is a test "textarea".<br>
Scroll to its first line<br>
and type there.<br>
The typing caret will leave<br>
the textarea box<br>
and the "invisible" typing will <br>
be going on above it.<br>

<textarea rows=3 cols=20
style="position:relative; left:15px; top:10px;">
top line
line two
three
four
five
six
seven
eight
nine
ten
eleven
twelve
</textarea>
</body>
</html>

wayne

unread,
Nov 11, 2007, 8:39:49 PM11/11/07
to iPhoneWebDev
Couple other related problems with iPhone keyboard:

1. If the code repositions the textarea to fit right above
the keyboard (so user can have some contiguous text
above), the keyboard loses track of its edit "lens" and
still activates the lens in the original place (which is
where it scrolled the textarea initially, half way
between the top of kbd and top of screen). Laying
down two fingers onto the textarea resyncs the lens
again.

2. When Enter is pressed, very often the keyboard
scrolls the text area from the case (1) (i.e. the area which
was moved down to cover the default gap), back to the
initial position with the gap. This behavior is erratic and
there seems to be no pattern in their decision
which 'Enter' will cause the gap to reappear. Fighting
it by scrolling the area down on each such uninvited
scroll (which doesn't appear as event but has to be
detected from a timer event) ends up bringing up the
lost lens problem described in #1, hence its not worth
the trouble.

Altogether, it seems Apple has rushed this keyboard
"design" out the door well before it was ready for
developers. Hopefully the upcoming versions will fix
it up and provide a proper interface for keyboard
activation, control and customization (e.g. key caps
& codes produced) by the applications.


Reply all
Reply to author
Forward
0 new messages