On 20/02/2014 01:34, TAMURA, Kent wrote:
Hi,
The current WebKit/Blink behavior is:
- Accept both of the ASCII digits and localized digits
- Accept both of the standard decimal point '.' and a localized decimal point
That sounds similar to what I've implemented, but users can't mix digits,
When implementing input type=number for Mozilla I decided to display the value
to the user using the grouping separator (generally the thousands separator) of
the users locale. So, for example, if the input's value is 1234 and the user's
locale is English, it is displayed to the user as 1,234.
On 18/02/2014 23:09, Jonathan Watt wrote:
When implementing input type=number for Mozilla I decided to display the value
to the user using the grouping separator (generally the thousands separator) of
the users locale. So, for example, if the input's value is 1234 and the user's
locale
On 18/02/2014 23:17, Ian Hickson wrote:
On Tue, 18 Feb 2014, Jonathan Watt wrote:
When implementing input type=number for Mozilla I decided to display
the value to the user using the grouping separator (generally the
thousands separator) of the users locale. So, for example, if the
input's
On 19/02/2014 01:24, Karl Dubost wrote:
I wonder if it would not be more flexible to have a `format` attribute.
input type=number format=%Y/
(or any other formatting syntax)
I'm not sure a formatting attribute is desirable, at least not if it leads to
content authors making decisions
On 02/08/2013 23:39, Glenn Maynard wrote:
On Fri, Aug 2, 2013 at 11:15 AM, Jonathan Watt jw...@jwatt.org wrote:
In my prototype implementation it took around 30 seconds to build the
FileList for a directory of 200,000 files with a top end SSD; so depending
on what the page is doing, directory
On 05/08/2013 00:54, Glenn Maynard wrote:
On Sun, Aug 4, 2013 at 2:47 AM, Jonas Sicking jo...@sicking.cc wrote:
We can't do what you are suggesting for a plain input type=file
multiple since there's already a defined API for that, and that API
only exposes a .files property in the DOM.
Sure
The result of the discussion here:
http://www.w3.org/mid/514a17d4.3070...@jwatt.org
is that I've changed Firefox Nightly's handling of input type=range to allow
it to render as a vertical slider if it has an orient=vertical attribute on
it. There was only one reply to my email to www-style,
On 26/03/2013 14:55, Simon Pieters wrote:
On Tue, 26 Mar 2013 15:07:55 +0100, Jonathan Watt jw...@jwatt.org wrote:
The result of the discussion here:
http://www.w3.org/mid/514a17d4.3070...@jwatt.org
is that I've changed Firefox Nightly's handling of input type=range to
allow it to render
On 17/01/2013 20:13, Ian Hickson wrote:
Fixed, by adding if there is a number that matches these
constraints, which means that the value now ends up at 0 and remains
suffering from a step mismatch.
Regarding this change:
http://html5.org/tools/web-apps-tracker?from=7640to=7641
For what it's
In addition to the value sanitization algorithm, some input types specify
actions that the user agent must take when the element's value is suffering from
underflow/overflow or a step mismatch. To make it clearer that these actions
will also be run when the value sanitization algorithm is run,
I'm working on implementing input type=range for Gecko and have encountered
what I believe to be an issue in the spec.
Step 1 of the algorithm to find the step base:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#concept-input-min-zero
says If
On 17/01/2013 19:29, Jonathan Watt wrote:
I'm working on implementing input type=range for Gecko and have encountered
what I believe to be an issue in the spec.
Step 1 of the algorithm to find the step base:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element
The text on input type=range at:
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29
says:
The step scale factor is 1. The default step is 1 (allowing only
integers, unless the min attribute has a non-integer value).
I
It seems like there should be a way to get iframe to size to the intrinsic size
of the embedded content without having style from the embedding document inherit
into the embedded document. Could we have a way to do just the intrinsic sizing
please?
On 18/07/2012 13:31, Ojan Vafai wrote:
I made a proposal for this at the end of
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/036584.html.
Great!
The
best way to get this specced is to provide additional use-cases (for having
intrinsic sizing without inheriting style) in
The extend mode of canvas gradients isn't under user control as it is in SVG.
I'd like to propose adding a setExtend(in DOMString extend) method to the
CanvasGradient interface[1], where the method would accept the arguments none,
repeat, reflect and pad. These would be defined similarly to the
17 matches
Mail list logo
