ribute is updated.
The spec should follow this behavior.
--
TAMURA Kent
Software Engineer, Google
main-part
is not practical. The production accepts apparently unusable email address
like "tk...@"
--
TAMURA Kent
Software Engineer, Google
out "." restriction.
This looseness 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 charact
- domain-part should be [a-zA-Z0-9]+(\.[a-zA-Z0-9]+)+
Correction. "-" is allowed for domain-part.
--
TAMURA Kent
Software Engineer, Google
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
What should happen to selected files in a case that a user selects multiple
files for and then a script code removes the
multiple attribute from the input element?
- nothing, no change to the selected files and they will be submitted,
- cleared, or
- a single file remains
--
TAMURA Kent
will do this
someday, but it's 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
AsNumber.
Because 'input.valueAsDate = null' makes the value empty, I think
'input.valueAsNumber = Number.NaN' also makes the value empty.
--
TAMURA Kent
Software Engineer, Google
On Mon, Jan 25, 2010 at 19:10, Philip Taylor
wrote:
On Mon, Jan 25, 2010 at 9:55 AM, TAMURA, Kent wrote:
> It seems the current spec doesn't define behavior in a case of setting
NaN
> or Infinitiy to HTMLInputElement::valueAsNumber.
http://whatwg.org/html5#float-nan : &q
och is
about 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.valueAsN
.
--
TAMURA Kent
Software Engineer, Google
didate for constraint
> validation except when a condition has barred the element from
> constraint validation.
--
TAMURA Kent
Software Engineer, Google
ation,
typeMismatch won't be true.
--
TAMURA Kent
Software Engineer, Google
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
On Sat, Apr 3, 2010 at 06:37, Ian Hickson 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 '-
eld selection APIs for email, number, 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
ue returns the raw input while a user 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 HTM
x27;s not a good user experience. Users
don't expect their input strings are cleared by UA.
Also, 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 t
would 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 wrote:
Proposal:
Making an input element invalid state if the input has an invalid string
specified by a user with browser UI. &
not timezone agnostic, we could add something. For the
moment, given the state of the implementations and the very tiny use
cases that could solve, I think having this type would hurt more than
help.
Thanks,
--
Mounir
--
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 wrote:
On 13/11/12 09:42, TAMURA, Kent wrote:
The current UI implementations of Opera, iOS, and Chrome-Android spoil
the
HTML standard. Web authors
we would need Computer-E and extra
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
On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson wrote:
On Fri, 7 Sep 2012, TAMURA, Kent wrote:
Proposal:
I'd like to propose adding new IDL attribute to HTMLInputElement.
readonly attribute DOMString rawValue;
It returns text content which a user actually see in an input
cal events. Or the server might be using latest timezone
> data but the UA could be using three year old data. In either case, 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
On Mon, Jan 14, 2013 at 2:19 AM, Ian Hickson 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
ector. In fact it's the precise key difference between
datetime-local and datetime.
I don't think so. If you make a repeating event in a region with daylight
saving time, Google Calendar respects the local time which you specified.
--
TAMURA Kent
Software Engineer, Google
On Sat, Jul 13, 2013 at 6:39 AM, Ian Hickson wrote:
On Wed, 9 Jan 2013, TAMURA, Kent wrote:
On Wed, Nov 21, 2012 at 7:51 AM, Ian Hickson wrote:
> On Fri, 7 Sep 2012, TAMURA, Kent wrote:
> >
> > * For date, datetime, datetime-local, month, time, week, the
> > attribute
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 wrote:
On Wed, 21 Aug 2013, TAMURA, Kent wrote:
On Sat, Jul 13, 2013 at 6:39 AM, Ian Hickson wrote:
> On Wed, 9 Jan 2013, TAMURA, Ke
o note 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
ed results for users; for example, a user
types in "1,234" meaning 1234 but the input takes the value 1.234. Or
maybe
I misunderstand?
You're right. Such confusion can happen even in WebKit/Blink
implementation. However, it's much better than accepting both of grouping
se
On Fri, May 7, 2010 at 06:41, Garrett Smith 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
x27; property of CSS isn't 'none' and no
'hidden' content 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
user agents may report a script error.
This sentence is about process against controls of which validation result
is invalid.
I think UA doesn't need to validate such controls.
The Chrome bug report is here:
http://code.google.com/p/chromium/issues/detail?id=45640
2010/6/4 TAMURA, Kent
>
dation for
existing sites as possible. e.g. disabling interactive form validation for
documents without "".
On Fri, Jun 4, 2010 at 00:16, TAMURA, Kent wrote:
> An element is a "candidate for constraint validation" if
> 1. it is a validatable type,
>e.g. tr
On Sat, Apr 3, 2010 at 06:37, Ian Hickson 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 '-
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 wrote:
On Mon, 5 Apr 2010, TAMURA, Kent wrote:
> On Sat, Apr 3, 2010 at 06:37, Ian Hickson wrote:
> >
, we still have 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
uot;required" 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
On Tue, Nov 2, 2010 at 05:50, Aryeh Gregor
wrote:
On Sun, Oct 31, 2010 at 10:31 PM, TAMURA, Kent wrote:
> The number type control in Opera and WebKit allow a user to
> input
> out-of-range value even if the control has min=1 and max=16 attributes.
> It's not
> a go
fy
requirements
of actual Web application UI and type=number won't be used widely.
On Mon, Nov 1, 2010 at 11:31, TAMURA, Kent wrote:
A team in Google tried to use for a product, and they
decided
not to use it.
What they needed was a control to select an integer from a specific
integer
using some
compatibility issues about maxlength.
http://www.google.com/support/forum/p/Chrome/thread?tid=4f612fe2abafc365&hl=en
--
TAMURA Kent
Software Engineer, Google
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
t when
the field is focused.
* autofocus + placeholder is useless in the current specification.
--
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
44 matches
Mail list logo
