Hi,
I'd like to propose a new input type attribute value for phone
numbers (input type=phonenumber perhaps). The primary benefit
would be to enable use of phone number specific input methods (for
example a virtual keyboard) and pickers (for example a system address
book). A useful
On 31.3.2009, at 0:12, Ian Hickson wrote:
On Mon, 30 Mar 2009, Antti Koivisto wrote:
I'd like to propose a new input type attribute value for phone
numbers
(input type=phonenumber perhaps). The primary benefit would be to
enable use of phone number specific input methods (for example
On 31.3.2009, at 10:02, James Graham wrote:
FWIW I would imagine that the most useful aspect of input
type=tel or whatever would not be validation (because validation
is hard) but would be better integration on mobile devices e.g.
making the default action of the keypad be number keys,
On 31.3.2009, at 13:35, Anne van Kesteren wrote:
On Tue, 31 Mar 2009 22:19:35 +0200, Antti Koivisto an...@apple.com
wrote:
Validation is indeed a complete red herring, this is about input
methods.
In that case it might be better to re-introduce the inputmode=
attribute for this purpose
On 16.11.2008, at 16:16, Ian Hickson wrote:
First of all, I'm not sure I fully understand the problem you are
solving here. Could you summarize it?
You don't have to fire the event if nobody is listening for it.
(Browsers
likely already have this implementation for mutation events if
On 15.10.2008, at 15:07, Eric Carlson wrote:
It sounds like we agree that looping *can* definitely be
implemented in JavaScript, but that it can be very difficult to do
so without visible/audible artifacts.
Would it be sufficient to have boolean attribute for enabling and
disabling
On 14.5.2008, at 23:37, Ian Hickson wrote:
It would be nice to have a read-only attribute (called playing for
example) that would be true when the element is actively playing.
Knowing if the playback is progressing is necessary for implementing
basic playback UIs with JS. It is clumsy and not
recursion it can end up
in an infinite loop. Having a limit seems OK since most JavaScript
engines already have a limit on the size of the call stack.
On Mon, Mar 10, 2008 at 11:54, Anne van Kesteren [EMAIL PROTECTED]
wrote:
On Mon, 10 Mar 2008 19:49:21 +0100, Antti Koivisto
[EMAIL PROTECTED
a limit seems OK since most JavaScript
engines already have a limit on the size of the call stack.
On Mon, Mar 10, 2008 at 11:54, Anne van Kesteren [EMAIL PROTECTED]
wrote:
On Mon, 10 Mar 2008 19:49:21 +0100, Antti Koivisto
[EMAIL PROTECTED] wrote:
WebKit, Firefox and IE all implement
Hi,
WebKit, Firefox and IE all implement a protection mechanism against re-
entering click() on the same element:
input type=checkbox onclick=this.click()
WebKit (and based on testing Firefox) make click() a no-op when
invoked as a result of a click event generated by calling click() on
Hi Charles,
You are correct that the current draft leaves this aspect of the
controls attribute unspecified. The video implementation available in
the WebKit nightlies uses overlay controls that fade away during
playback and don't affect the size of the video box. I saw a Firefox
demo
On 28.1.2008, at 13:51, Charles wrote:
Antti,
Thanks for the response.
The video implementation available in the WebKit nightlies uses
overlay controls that fade away during playback and don't affect
the size of the video box. I saw a Firefox demo of this feature
that took similar approach
12 matches
Mail list logo
