Could you explain how „format“ would work if the content of the element
can not be formated like that? How could attributes be re-formated?
Cameron Jones cmhjo...@gmail.com writes:
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Qebui Nehebkau
On Wed, 19 Feb 2014, Michael[tm] Smith wrote:
Ian Hickson i...@hixie.ch, 2014-02-18 23:59 +:
On Tue, 18 Feb 2014, Jonathan Watt wrote:
I wonder if it would be that bad to have a 'year' type to compliment
the 'month' and 'day' types...
This has come up a few times, but so far
On Thu, Feb 20, 2014 at 9:19 PM, Jonathan Watt jw...@jwatt.org wrote:
For what it's worth I just tried the following in Chrome, and if I type in
12,34 then increment using the spinner it resets to zero, seeming to
indicate that the , was rejected. Is that expected?
data:text/html,input
Ryosuke Niwa writes:
On Mar 7, 2014, at 3:54 AM, Smylers smyl...@stripey.com wrote:
An international website wanting a [year] ... could internally store
all years using one particular system (say the Gregorian one), but
allow input in other systems. This could be with a free-form text
On Mar 11, 2014, at 2:28 AM, Smylers smyl...@stripey.com wrote:
Ryosuke Niwa writes:
On Mar 7, 2014, at 3:54 AM, Smylers smyl...@stripey.com wrote:
An international website wanting a [year] ... could internally store
all years using one particular system (say the Gregorian one), but
Ryosuke Niwa writes:
On Mar 11, 2014, at 2:28 AM, Smylers smyl...@stripey.com wrote:
Ryosuke Niwa writes:
On Mar 7, 2014, at 3:54 AM, Smylers smyl...@stripey.com wrote:
Are there many websites currently catering [for] Japanese years
by offering such an interface? If so, it
On Mar 7, 2014, at 3:54 AM, Smylers smyl...@stripey.com wrote:
Ryosuke Niwa writes [re-ordered]:
On Feb 19, 2014, at 7:36 AM, Jukka K. Korpela jkorp...@cs.tut.fi
wrote:
2014-02-19 11:10, Smylers wrote:
Jukka K. Korpela writes:
The point is that year numbers aren't really numbers in
/#presentation_19
-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Nils Dagsson Moskopp
Sent: Saturday, March 08, 2014 1:25 AM
To: Jonathan Watt; whatwg
Subject: Re: [whatwg] input type=number for year input
Jonathan Watt jw
David Dailey ddai...@zoominternet.net writes:
Addresses frequently, but moreso in cities than in rural areas [2]
have the property that 123 Huaihai Zhong Road is geographically
between 120 Huaihai Zhong Road and 130 Huaihai Zhong Road, hence
obeying the transitive property when articulated
Let me point out that not every calendar uses simple 2-4 digit numbers to
denote years.
The Japanese era name calendar system, for example, requires an era name such
as Showa and Heisei associated with each year.
For example, I was born in Gregorian year 1986 but any Japanese government
Ryosuke Niwa writes [re-ordered]:
On Feb 19, 2014, at 7:36 AM, Jukka K. Korpela jkorp...@cs.tut.fi
wrote:
2014-02-19 11:10, Smylers wrote:
Jukka K. Korpela writes:
The point is that year numbers aren't really numbers in a
normal sense, any more than car plate numbers,
Jonathan Watt jw...@jwatt.org writes:
is it wrong to use input type=number for year input.
I am certainly not an expert on the topic, but I believe the conceptual
problem can be reduced to using an input designed for a group (in the
mathematical sensce) to represent a value that is torsor.
Nils Dagsson Moskopp writes:
Jonathan Watt jw...@jwatt.org writes:
is it wrong to use input type=number for year input.
I am certainly not an expert on the topic, but I believe the
conceptual problem can be reduced to using an input designed for a
group (in the mathematical sensce) to
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,
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes:
On Wed, Feb 19, 2014 at 7:51 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
CE or BE or ROC do not specify units (successor elements), but points of
reference (neutral elements). In my examples, the unit for a time offset
On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
The number of a calendar year really does not fit into to the number
model. Year numbering conveys something different than floating point
numbers or even integers. Standardization of values on ISO years
Jukka K. Korpela writes:
The point is that year numbers aren't really numbers in a normal
sense, any more than car plate numbers, credit card numbers, product
numbers, or social security numbers are. Surely they can be regarded
as numbers, but so can car plate numbers and the others.
Except
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes:
On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
The number of a calendar year really does not fit into to the number
model. Year numbering conveys something different than floating point
numbers
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes:
On Wed, Feb 19, 2014 at 4:32 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
The number of a calendar year really does not fit
Jones cmhjo...@gmail.com
Sent: Wednesday, February 19, 2014 07:09
To: Nils Dagsson Moskopp
Cc: whatwg; Ian Hickson; Jonathan Watt; Qebui Nehebkau
Subject: Re: [whatwg] input type=number for year input
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Qebui
2014-02-19 11:10, Smylers wrote:
Jukka K. Korpela writes:
The point is that year numbers aren't really numbers in a normal
sense, any more than car plate numbers, credit card numbers, product
numbers, or social security numbers are. Surely they can be regarded
as numbers, but so can car plate
Jukka K. Korpela writes:
2014-02-19 11:10, Smylers wrote:
Jukka K. Korpela writes:
The point is that year numbers aren't really numbers in a normal
sense, any more than car plate numbers, credit card numbers,
product numbers, or social security numbers are. Surely they can
be
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
I consider year-era-constructs as names for a duration of time. We can
have different names than refer to the same duration of time, like 2014
CE and 2557 BE and ROC 103. The fact that most of these
Qebui Nehebkau qebui.nehebkau+wha...@gmail.com writes:
On Wed, Feb 19, 2014 at 11:38 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
I consider year-era-constructs as names for a duration of time. We can
have different names than refer to the same duration of time, like 2014
CE
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
- Not accept grouping separators and don't show grouping separators
We showed grouping separators in the past. But we
On Wed, Feb 19, 2014 at 7:51 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
CE or BE or ROC do not specify units (successor elements), but points of
reference (neutral elements). In my examples, the unit for a time offset
is always the duration of a solar year.
Yes, sorry, by
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 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 value is 1234 and the user's locale is
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 is
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 2/18/14, 17:17, Ian Hickson wrote:
On Tue, 18 Feb 2014, Jonathan Watt wrote:
The question is, should I change Mozilla's implementation to stop
displaying the internal value using grouping separators, or is it wrong
to use input type=number for year input. I'm erring on the former, but
I'd
On 2/18/14, 17:55, Mike Taylor wrote:
On 2/18/14, 17:17, Ian Hickson wrote:
On Tue, 18 Feb 2014, Jonathan Watt wrote:
The question is, should I change Mozilla's implementation to stop
displaying the internal value using grouping separators, or is it wrong
to use input type=number for year
On Tue, 18 Feb 2014, Jonathan Watt wrote:
My recommendation would be to just use comma separation
It would be the appropriate separator(s) for the locale in use, not
necessarily the comma, but I'm guessing that's what you meant.
Sure.
for numbers greater than . It doesn't help
2014-02-19 1:59, Ian Hickson wrote:
I would be interested in hearing more about the locales where not using
separators even for four digits is bad/suboptimal.
It would break a few national standards on number representation.
The point is that year numbers aren't really numbers in a normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Ian Hickson i...@hixie.ch, 2014-02-18 23:59 +:
On Tue, 18 Feb 2014, Jonathan Watt wrote:
...
I wonder if it would be that bad to have a 'year' type to compliment the
'month' and 'day' types...
This has come up a few times, but so far
Le 19 févr. 2014 à 08:17, Ian Hickson i...@hixie.ch a écrit :
It doesn't help that much for four-digit numbers, and
years beyond four digits often _do_ have commas, e.g.:
http://en.wikipedia.org/wiki/Year_10,000_problem
In English.
The same page you used:
西暦1年問題
Problema del año
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 Tuesday, February 18, 2014 8:24 PM
Karl Dubost wrote
Le 19 févr. 2014 à 08:17, Ian Hickson i...@hixie.ch a écrit :
It doesn't help that much for four-digit numbers, and years beyond
four digits often _do_ have commas, e.g.:
http://en.wikipedia.org/wiki/Year_10,000_problem
In English.
Hickson
Cc: whatwg; Jonathan Watt
Subject: Re: [whatwg] input type=number for year input
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Ian Hickson i...@hixie.ch, 2014-02-18 23:59 +:
On Tue, 18 Feb 2014, Jonathan Watt wrote:
...
I wonder if it would be that bad to have a 'year' type
Ian Hickson i...@hixie.ch writes:
On Tue, 18 Feb 2014, Jonathan Watt wrote:
My recommendation would be to just use comma separation
It would be the appropriate separator(s) for the locale in use, not
necessarily the comma, but I'm guessing that's what you meant.
Sure.
for numbers
2014-02-19 2:30, Michael[tm] Smith wrote:
The following info seems relevant -
http://www.thepunctuationguide.com/comma.html#numbers
Most authorities, including The Associated Press Stylebook and The Chicago
Manual of Style, recommend a comma after the first digit of a four-digit
41 matches
Mail list logo
