On 08/02/2012, at 12:39 AM, Ian Hickson wrote:
On Fri, 20 Jan 2012, Cameron Heavon-Jones wrote:
The lang attribute is the structural declaration of the content's
localization, be it prose or data values.
Technically it just sets the language, not the localisation. I expect we
will in
On Thu, 19 Jan 2012, John Tamplin wrote:
[...] a user types 1,575 in a field. Is that interpreted as a value
between 1 and 2 or between 1000 and 2000? [...]
That's entirely up to the UA.
On Thu, 19 Jan 2012, Bronislav Klu�~Mka wrote:
This should depend on selected locale, is coma
On 20/01/2012, at 6:52 PM, Bronislav Klučka wrote:
On 20.1.2012 18:52, Cameron Heavon-Jones wrote:
The lang attribute is the structural declaration of the content's
localization, be it prose or data values. There should be no difference in
what the following mean:
p lang=enThis is
On 20.1.2012 1:29, Jukka K. Korpela wrote:
Why would things suddenly change when it comes to user interface?
Besides, there is nothing in CSS as currently defined that even tries
to address such issues.
Yucca
I've joined this discussion to point out the difference between
presentation
On 20/01/2012, at 1:33 PM, Bronislav Klučka wrote:
On 20.1.2012 1:29, Jukka K. Korpela wrote:
Why would things suddenly change when it comes to user interface? Besides,
there is nothing in CSS as currently defined that even tries to address such
issues.
Yucca
I've joined this
Sorry, I didn't mean to argue that CSS should be involved, merely that the
communication user to user-agent should be considered to use locle-dependent
formats, and that the communication user-agent to server should be in a
standard format.
On Jan 19, 2012, at 16:29 , Jukka K. Korpela wrote:
On 20.1.2012 18:52, Cameron Heavon-Jones wrote:
The lang attribute is the structural declaration of the content's localization,
be it prose or data values. There should be no difference in what the following
mean:
p lang=enThis is some english text/p
input lang=en type=text value=This is
On Sat, 16 Jul 2011, Jukka K. Korpela wrote:
16.07.2011 00:01, Ian Hickson wrote:
Much discussion on this topic happened when we started on this work in
2004 and 2005, I highly recommend perusing the archives around that
time.
Authors and implementors will need to be able to
On Thu, Jan 19, 2012 at 3:38 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 14 Apr 2011, John Tamplin wrote:
The entire web application, which includes both client and
server-side code, must have the same idea about what locale the user
is using. If the app provides a drop-down
On 19.1.2012 21:51, John Tamplin wrote:
On Thu, Jan 19, 2012 at 3:38 PM, Ian Hicksoni...@hixie.ch wrote:
On Thu, 14 Apr 2011, John Tamplin wrote:
Indeed. To solve this, we need help from CSS. That's one of the
reasons we createdoutput in HTML.
This is about data representation and
On Jan 19, 2012, at 13:35 , Bronislav Klučka wrote:
On 19.1.2012 21:51, John Tamplin wrote:
On Thu, Jan 19, 2012 at 3:38 PM, Ian Hicksoni...@hixie.ch wrote:
On Thu, 14 Apr 2011, John Tamplin wrote:
Indeed. To solve this, we need help from CSS. That's one of the reasons
we
2012-01-20 1:19, David Singer wrote:
What the user enters and sees on screen is a presentational/locale issue
Which one? “Presentational” normally refers to things like layout
design, colors, fonts, and borders. Locales are something different.
The difference between “1.005” meaning one
On 15/04/2011, at 10:56 PM, Aryeh Gregor wrote:
Trying to add more features to the
new form stuff is premature when we only have one really good
implementation (IMO: Gecko's), and that implementation is partial.
The time to talk about new features is when we have some amount of
stability and
On 16/07/2011, at 5:52 AM, Jukka K. Korpela wrote:
16.07.2011 00:01, Ian Hickson wrote:
Much discussion on this topic happened when we started on this work in
2004 and 2005, I highly recommend perusing the archives around that time.
Authors and implementors will need to be able to
On Thu, 14 Apr 2011, Jukka K. Korpela wrote:
I was surprised at seeing that the Finnish-language version of Google
Chrome 11 beta accepts a number with a comma, such as 4,2, in input
type=number. It silently converts the comma to a full stop, 4.2.
This looked like a useful feature at
16.07.2011 00:01, Ian Hickson wrote:
Much discussion on this topic happened when we started on this work in
2004 and 2005, I highly recommend perusing the archives around that time.
Authors and implementors will need to be able to understand the topic
without checking discussions archives,
Aryeh Gregor wrote:
On Sat, Apr 16, 2011 at 9:18 AM, Jukka K. Korpela
jkorp...@cs.tut.fi wrote:
An element for user input of a real number in a format that uses a
suitable decimal separator is hardly a specific need.
It's more specific than just an element for user input of a number.
This
Dne Fri, 15 Apr 2011 23:56:45 +0200 Aryeh Gregor
simetrical+...@gmail.com napsal(a):
2011/4/14 Oldřich Vetešník vetes...@mrmil.cz:
I am afraid that if the decimal separator (in rendering) doesn't behave
the
way people expect it to, it will mean web developers will have to deal
with
clients
On Sat, Apr 16, 2011 at 9:18 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
An element for user input of a real number in a format that uses a suitable
decimal separator is hardly a specific need.
It's more specific than just an element for user input of a number.
We don't even have that
Aryeh Gregor wrote:
I didn't read the whole thread, but: authors with specific needs will
always want to roll their own inputs for most of these things, and
that's fine.
An element for user input of a real number in a format that uses a suitable
decimal separator is hardly a specific need.
2011/4/14 Oldřich Vetešník vetes...@mrmil.cz:
I am afraid that if the decimal separator (in rendering) doesn't behave the
way people expect it to, it will mean web developers will have to deal with
clients saying We wan't to be able to enter a comma. The dealing might
mean not using input
I was surprised at seeing that the Finnish-language version of Google Chrome
11 beta accepts a number with a comma, such as 4,2, in input
type=number. It silently converts the comma to a full stop, 4.2.
This looked like a useful feature at first sight, as decimal comma is
standard in Finnish
On Thu, 2011-04-14 at 12:05 +0300, Jukka K. Korpela wrote:
I was surprised at seeing that the Finnish-language version of Google Chrome
11 beta accepts a number with a comma, such as 4,2, in input
type=number. It silently converts the comma to a full stop, 4.2.
This looked like a useful
Dne Thu, 14 Apr 2011 11:40:12 +0200 Henri Sivonen hsivo...@iki.fi
napsal(a):
On Thu, 2011-04-14 at 12:05 +0300, Jukka K. Korpela wrote:
I was surprised at seeing that the Finnish-language version of Google
Chrome
11 beta accepts a number with a comma, such as 4,2, in input
type=number. It
Henri Sivonen wrote:
The the requirements you cite apply to what goes over the wire and
appears in the DOM. The browser may provide a comma-base UI for
manipulating the value that is stored and transfered using a period.
I see... thanks for the clarification. Yes the description is very
On Thu, Apr 14, 2011 at 7:23 AM, Jukka K. Korpela jkorp...@cs.tut.fiwrote:
I think the main problem is triggering the decimal separator mode (or
the order of numeric day and month for that matter) on the UI locale
rather than the locale of the page,
Well that's certainly at least _one_ of
John Tamplin wrote:
The entire web application, which includes both client and
server-side code, must have the same idea about what locale the user
is using.
Well, HTML(5) is not just about client-server applications. It’s also about
offline applications and about the bulk of web and
On Thu, Apr 14, 2011 at 12:40 PM, Jukka K. Korpela jkorp...@cs.tut.fiwrote:
Well, HTML(5) is not just about client-server applications. It’s also about
offline applications and about the bulk of web and intranet content that
cannot be characterized as “applications” in any significant meaning.
28 matches
Mail list logo
