.
--
TAMURA, Kent
Software Engineer, Google
that I can still allow the implementation to accept
input from the user that contains grouping separators, even if when the
internal value is set/changed the visual result will be updated to a
string
that does not contain grouping separators.
--
TAMURA, Kent
Software Engineer, Google
I know I'm proposing a strange thing. Some use-cases are just workarounds
and there are ideal solutions.
On Tue, Sep 24, 2013 at 5:35 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 21 Aug 2013, TAMURA, Kent wrote:
On Sat, Jul 13, 2013 at 6:39 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 9 Jan
On Sat, Jul 13, 2013 at 6:39 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 9 Jan 2013, TAMURA, Kent wrote:
On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 7 Sep 2012, TAMURA, Kent wrote:
* For date, datetime, datetime-local, month, time, week, the
attribute
On Mon, Jan 14, 2013 at 2:19 AM, Ian Hickson i...@hixie.ch wrote:
On Sun, 13 Jan 2013, TAMURA, Kent wrote:
So, I think it's impossible for us to build reasonable UI for
type=datetime. It should be removed from the specification.
In the simplest case, the UI for type=datetime doesn't
, the
absolute time in UTC could be different for the server and UA.
Indeed.
So, I think it's impossible for us to build reasonable UI for
type=datetime. It should be removed from the specification.
--
TAMURA Kent
Software Engineer, Google
handling for invalid/ambiguous time. If UI was independent from a local
timezone, only User-D/E/F could use it.
--
TAMURA Kent
Software Engineer, Google
I think I can do it for WebKit if WHATWG specification and W3C
specification are changed so.
On Thu, Nov 15, 2012 at 2:23 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On 13/11/12 09:42, TAMURA, Kent wrote:
The current UI implementations of Opera, iOS, and Chrome-Android spoil
the
HTML standard
.
Thanks,
--
Mounir
--
TAMURA Kent
Software Engineer, Google
have less impact to the standard. If no one has concern about this
idea, I'd like to implement C in WebKit.
On Thu, Sep 13, 2012 at 3:18 PM, TAMURA, Kent tk...@chromium.org wrote:
Proposal:
Making an input element invalid state if the input has an invalid string
specified by a user with browser
, I don't like submitting empty value silently. Users expect their
input strings are submitted.
I think the best UI is to notify users about a field has an invalid string,
and give a chance to correct it. Applying the standard form validation
mechanism must be reasonable.
--
TAMURA Kent
Software
is editing the
value and let value sanitization algorithm happen afterward.
It doesn't work for type=email.
Suppose an email field has root@グーグル.com as a display value. A screen
reader reads it as r...@xn--qcka1pmc.com because HTMLInputElement::value
returns a sanitized string.
--
TAMURA Kent
Software
, and other types
- JavaScript-based screen readers can read user-visible content of input
fields.
Strings returned by rawValue attribute may be browser-dependent and
locale-dependent. However it would be useful.
--
TAMURA Kent
Software Engineer, Google
Form control presentations and ECMA Globalization API should be
synchronized. We might need HTMLInputElement::numberFormat to set/get a
Globalization.NumberFormat object.
http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
--
TAMURA Kent
Software Engineer, Google
the field is focused.
* autofocus + placeholder is useless in the current specification.
--
TAMURA Kent
Software Engineer, Google
, but there may be more
cases
where text gets shorter as you type.
Ishii-san,
It's not related to this thread.
Anyway, do you have any concern about the behaviors of the current
browsers?
--
TAMURA Kent
Software Engineer, Google
compatibility issues about maxlength.
http://www.google.com/support/forum/p/Chrome/thread?tid=4f612fe2abafc365hl=en
--
TAMURA Kent
Software Engineer, Google
for the current specification can't satisfy
requirements
of actual Web application UI and type=number won't be used widely.
On Mon, Nov 1, 2010 at 11:31, TAMURA, Kent tk...@chromium.org wrote:
A team in Google tried to use input type=number for a product, and they
decided
not to use it.
What
On Tue, Nov 2, 2010 at 05:50, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
On Sun, Oct 31, 2010 at 10:31 PM, TAMURA, Kent tk...@chromium.org wrote:
The number type control in Opera and WebKit allow a user to
input
out-of-range value even if the control has min
by default, and sanitization algorithm may be different.
I'm not sure how to solve this issue. Introducing new content attribute or
another number type?
--
TAMURA Kent
Software Engineer, Google
compatibility issues and we
can't force authors to update their web pages. I'm wondering UA should
show a dialog with The web page has invisible invalid form fields. Do you
want to submit the form? [Yes] [No].
--
TAMURA Kent
Software Engineer, Google
Please see
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-July/027243.html
In short words, I disagree with the current spec.
On Wed, Jul 28, 2010 at 08:45, Ian Hickson i...@hixie.ch wrote:
On Mon, 5 Apr 2010, TAMURA, Kent wrote:
On Sat, Apr 3, 2010 at 06:37, Ian Hickson i
On Sat, Apr 3, 2010 at 06:37, Ian Hickson i...@hixie.ch wrote:
On Sat, 3 Apr 2010, TAMURA, Kent wrote:
I found type=number also had no typeMismatch. If a user wants to type a
negative value, he types '-' first. This state should make typeMismatch
true because '-' is not a valid floating
for
existing sites as possible. e.g. disabling interactive form validation for
documents without !DOCTYPE html.
On Fri, Jun 4, 2010 at 00:16, TAMURA, Kent tk...@chromium.org wrote:
An element is a candidate for constraint validation if
1. it is a validatable type,
e.g. true if input type
attribute)
I couldn't find exceptional rules for validating invisible controls in the
current draft.
Chrome 5 was released with a part of interactive validation, and we received
a bug report about validation against invisible form controls.
--
TAMURA Kent
Software Engineer, Google
/issues/detail?id=45640
2010/6/4 TAMURA, Kent tk...@chromium.org
An element is a candidate for constraint validation if
1. it is a validatable type,
e.g. true if input type=number, false if input type=reset
2. has no disabled attribute,
3. has no readonly attribute,
4. inside of a form
On Fri, May 7, 2010 at 06:41, Garrett Smith dhtmlkitc...@gmail.com wrote:
Opera has native support that mostly works but failed with dates prior
to 1582, last I checked.
This seems reasonable. Gregorian calendar started in 1582.
--
TAMURA Kent
Software Engineer, Google
On Sat, Apr 3, 2010 at 06:37, Ian Hickson i...@hixie.ch wrote:
On Sat, 3 Apr 2010, TAMURA, Kent wrote:
I found type=number also had no typeMismatch. If a user wants to type a
negative value, he types '-' first. This state should make typeMismatch
true because '-' is not a valid floating
I found type=number also had no typeMismatch.
If a user wants to type a negative value, he types '-' first. This state
should make typeMismatch true because '-' is not a valid floating point
number.
--
TAMURA Kent
Software Engineer, Google
,
typeMismatch won't be true.
--
TAMURA Kent
Software Engineer, Google
has barred the element from
constraint validation.
--
TAMURA Kent
Software Engineer, Google
.
--
TAMURA Kent
Software Engineer, Google
1,264,492,163,000. The float type can't represent this value
precisely.
If we do the following with float valueAsNumber, the input value loses the
data.
input.type = datetime;
input.value = 2010-01-26T08:00Z;
var num = input.valueAsNumber;
input.valueAsNumber = num;
--
TAMURA Kent
Software
'input.valueAsNumber = Number.NaN' also makes the value empty.
--
TAMURA Kent
Software Engineer, Google
On Mon, Jan 25, 2010 at 19:10, Philip Taylor
excors+wha...@gmail.comexcors%2bwha...@gmail.com
wrote:
On Mon, Jan 25, 2010 at 9:55 AM, TAMURA, Kent tk...@chromium.org wrote:
It seems the current spec doesn't define behavior in a case of setting
NaN
or Infinitiy to HTMLInputElement
probably rare enough that it's not worth putting effort
into.
Yeah, a warning seems reasonable. The current implementation of WebKit does
nothing, and I might add the warning if the spec say nothing about this.
Thank you.
--
TAMURA Kent
Software Engineer, Google
remains
--
TAMURA Kent
Software Engineer, Google
is suffering from a step mismatch.
and doesn't mention the relationship with rangeUnderflow and rangeOverflow.
So I think stepMismatch should work even if value is less than min or
greater than max. I'd like to clarify it.
--
TAMURA Kent
Software Engineer, Google
unusable email address
like tk...@
--
TAMURA Kent
Software Engineer, Google
was introduced for Japanese cell phone addresses.
- domain-part should be [a-zA-Z0-9]+(\.[a-zA-Z0-9]+)+
It requires at least 1 dot. The last non-dot sequence should have at
least 2 characters.
I have never heard requests to support for non-ASCII characters other than
IDN.
--
TAMURA Kent
- domain-part should be [a-zA-Z0-9]+(\.[a-zA-Z0-9]+)+
Correction. - is allowed for domain-part.
--
TAMURA Kent
Software Engineer, Google
.
--
TAMURA Kent
Software Engineer, Google
42 matches
Mail list logo
