date format in forms?

[koray]

hi everyone,

in my form i have to take some date information in dd-mm-yy format.
but i don't want user to use tabs while typing. for example s/he
should simply type 280104 but 28/01/04 must appear.

what can i do for that?
should i use three input tags? but then, how can i make the cursor
jump to the next field when typing in current field is done?
or if i use one input tag, how can i keep '/' signs in the field fixed
when user types the date?

[Lachlan Hunt]

koray wrote:

hi everyone,

in my form i have to take some date information in dd-mm-yy format.
You should at least use a four digit year, to make it less ambiguous,
but I recommend you use the international standard (ISO 8601) which is
the format YYYY-MM-DD. There are also other variations, but that seems
the most appropriate for your needs.
but i don't want user to use tabs while typing. for example s/he
should simply type 280104 but 28/01/04 must appear.
Then just use one text field, and write a description of the format you
would like it to be in, in the fields label. But then the server side
processing and validation becomes slightly harder.

On the server, you can use a regex to parse the string, so if you
were expecting the date in dd-mm-yy, but you also want to allow the user
to enter ddmmyy or dd/mm/yy, then use a regex like this. (I don't
recommend using a / as the delimter because it's not used in the 8601
standard for that purpose, but it is commonly used by many people)

/([0-9]{2})[-\/]?([0-9]{2})[-\/]?([0-9]{2})/

When executed on the string, that will return an array, each cell
with 2 characters, which you can then convert to numbers. Then it's
just a matter of checking that each field is within range. Also, if
your interested, and would like to use the ISO 8601 format, then use
this regex.

/([0-9]{4})[-\/]?([0-9]{2})[-\/]?([0-9]{2})/
this allows
YYYY-MM-DD
YYYY/MM/DD
YYYYMMDD
(as well as incorrect versions like YYYY/MM-DD, but that doesn't really
matter, as long as it supports the correct versions)
what can i do for that?
should i use three input tags? but then, how can i make the cursor
jump to the next field when typing in current field is done?
If you want to use three input fields, then you could use javascript
to detect when they have written 2 digits, but I be careful of this. If
done incorrectly, it may make it difficult to the user to make
corrections because of the cursor unexpectidly jumping to the next field.
or if i use one input tag, how can i keep '/' signs in the field fixed
when user types the date?

Don't worry about it, just write a server side script that can handle it
however they enter it, but if your really worried about them entering it
absolutely correctly, then just modify the regexs above and return an
error message to them if they got it wrong.

--
Lachlan Hunt
http://www.lachy.id.au/
la**********@lachy.id.au.update.virus.scanners

Remove .update.virus.scanners to email me,
NO SPAM and NO VIRUSES!!!

[Jukka K. Korpela]

Lachlan Hunt <la**********@lachy.id.au.update.virus.scanners> wrote:

If you want to use three input fields, then you could use
javascript
to detect when they have written 2 digits, but I be careful of this.
If done incorrectly, it may make it difficult to the user to make
corrections because of the cursor unexpectidly jumping to the next
field.

And even when made the best possible way, it confuses people.

As Nielsen writes:

"Splitting what users see as a single piece of information into multiple
fields means that users must waste time moving the cursor around. A
typical example is when forms ask users for their first and last names as
two items, rather than simply letting users enter their full name in a
single field, which is much faster to type. Another example is
[a collection of three fields for a telephone number]."

http://www.useit.com/alertbox/20031222.html point 9
(Too bad Nielsen doesn't put id attributes into his heading
elements, to allow referring to them with URI references.)

Even if we managed to save some of (most) users' time by using JavaScript
to automagically move to the next field, users easily get confused. They
are not used to "automoving", and it's more difficult to recognize
something as a single entity when it has been split into several fields.

In principle, the server-side script should accept any format that can be
unambiguosly recognized. I would say that this means that no format with
a two-digit denotation should be accepted. Even though 01-02-03 is has a
single interpretation according to ISO 8601, we should not expect people
to know that meaning - actually most people mean something different.
Here we must accept the minor incovenience to users, I'd say, of forcing
them to type a year in four digits. But on the Web I think we need to go
farther and be rather restrictive about it, since 2/3/2001 isn't
absolutely clear either - it's probably meant to be interpreted the
American way, but it _could_ some day be meant to be read as
day/month/year. So this seems to boil down to accepting basically just
2001-02-03.

That's external to HTML of course. But the HTML implication is that a
single text input field is normally the best way to let the user enter a
date. I would use size="10" maxlength="10" as a hint, with an explanation
that says that date(s) be entered as year-month-day, with the year in
four digits.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Andreas Prilop]

On Thu, 15 Jul 2004, Jukka K. Korpela wrote:

And even when made the best possible way, it confuses people.

As Nielsen writes:

"Splitting what users see as a single piece of information into multiple
fields means that users must waste time moving the cursor around. A
typical example is when forms ask users for their first and last names as
two items, rather than simply letting users enter their full name in a
single field, which is much faster to type. [ ... ] "

What's the "last name" of Jukka Korpela?
What's the "last name" of Mao Zedong?

I think it is a good idea to have two different fields and let the user
clarify what's his family name and what's his given name(s).

--
Top-posting.
What's the most irritating thing on Usenet?

[Brian]

Andreas Prilop wrote:

On Thu, 15 Jul 2004, Jukka K. Korpela wrote:

As Nielsen writes:

"[...] A typical example is when forms ask users for their first
and last names as two items, rather than simply letting users
enter their full name in a single field, which is much faster to
type. [ ... ] "

What's the "last name" of Jukka Korpela?
What's the "last name" of Mao Zedong?

I think it is a good idea to have two different fields and let the
user clarify what's his family name and what's his given name(s).

Strange conclusion. If it's unclear how the user's name should be
represented, shouldn't there be a single name field? Let the user type
it in as they see fit. If the family name should be first, they'll
type it that way. If it should be last, so it will appear in posted data.

I think addresses would be much easier that way, too. Where does the
postal code go? After the city (and state), like in the US, or before
it, like in France? How many digits are there? In the end, splitting
the address up into 5 or 6 fields (address1, address2, city,
state/province, postal code, country) is harder for the user, and
harder for the server-side programmer. It's probably better to put a
textarea in the form, and let people type in the address just like
they were typing a mailing label. I think most people can be counted
on to know how their address should look.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Chris Morris]

Brian <us*****@julietremblay.com.invalid> writes:

Andreas Prilop wrote:

On Thu, 15 Jul 2004, Jukka K. Korpela wrote:

As Nielsen writes:
"[...] A typical example is when forms ask users for their first
and last names as two items, rather than simply letting users
enter their full name in a single field, which is much faster to
type. [ ... ] " What's the "last name" of Jukka Korpela?
What's the "last name" of Mao Zedong?
I think it is a good idea to have two different fields and let the
user clarify what's his family name and what's his given name(s).

Strange conclusion. If it's unclear how the user's name should be
represented, shouldn't there be a single name field? Let the user type
it in as they see fit. If the family name should be first, they'll
type it that way. If it should be last, so it will appear in posted data.

Also, there's no requirement to have both a given and family name. I
know of at least one person with only a single name.
I think addresses would be much easier that way, too. Where does the
postal code go? After the city (and state), like in the US, or before
it, like in France? How many digits are there? In the end, splitting
the address up into 5 or 6 fields (address1, address2, city,
state/province, postal code, country) is harder for the user, and
harder for the server-side programmer. It's probably better to put a
textarea in the form, and let people type in the address just like
they were typing a mailing label. I think most people can be counted
on to know how their address should look.

Agreed.

The exception, IMO, to Neilsen's advice, is for date/time fields,
where making sure users enter dates in the unambiguous numeric format
yyyy-mm-dd is, I think, unfriendlier than having three <select>s for
day, month and year.

Though where the year might be outside a small-ish range, obviously
that needs to be a text input, and then do all three become text
inputs for consistency?

Anyway, I think in some circumstances at least multiple inputs is a
better way to do date/time.

--
Chris

[Neal]

On 15 Jul 2004 15:27:25 +0100, Chris Morris <c.********@durham.ac.uk>
wrote:

Also, there's no requirement to have both a given and family name. I
know of at least one person with only a single name.

A name field is filled in by the user with their name in their preferred
form, so one field is fine.

Dates, though, have other uses. You might want to order things
chronologically, or see if more responses came in in September than July,
or in 2003 than 2004. Three fields is acceptable here. And I find most
sites use select boxes to choose a date, a spelled-out month, and a year.
Not that this makes it the best way, but clearly users are going to be
familiar with this way of doing it.

[Harlan Messinger]

"Brian" <us*****@julietremblay.com.invalid> wrote in message
news:10*************@corp.supernews.com...

Andreas Prilop wrote:

On Thu, 15 Jul 2004, Jukka K. Korpela wrote:

As Nielsen writes:

"[...] A typical example is when forms ask users for their first
and last names as two items, rather than simply letting users
enter their full name in a single field, which is much faster to
type. [ ... ] "
What's the "last name" of Jukka Korpela?
What's the "last name" of Mao Zedong?

I think it is a good idea to have two different fields and let the
user clarify what's his family name and what's his given name(s).

Strange conclusion. If it's unclear how the user's name should be
represented, shouldn't there be a single name field? Let the user type
it in as they see fit. If the family name should be first, they'll
type it that way. If it should be last, so it will appear in posted data.

Forms don't split up entry of people's names just for fun. The essential
need behind split entry of the user's name is to be able to sort
alphabetically on family name. Reproducing each person's name in the order
particular to the person's culture is secondary and usually non-critical.

I think addresses would be much easier that way, too. Where does the
postal code go? After the city (and state), like in the US, or before
it, like in France? How many digits are there? In the end, splitting
the address up into 5 or 6 fields (address1, address2, city,
state/province, postal code, country) is harder for the user, and
harder for the server-side programmer. It's probably better to put a
textarea in the form, and let people type in the address just like
they were typing a mailing label. I think most people can be counted
on to know how their address should look.

The requirements of most applications require the address data to be split.
I don't know about other countries, but U.S. organizations, to get favorable
postage rates, need to be able to print mailing labels in order by ZIP
(postal) code. Organizations in general need to be able to filter
user/customer/member data by state (or province or whatever), city, and
postal code for a variety of purposes.

It's really hard to build a parser that knows all the rules necessary for
international commerce, but in spite of your suggestion to the contrary I
think most people can be counted on to know which part of their address is
the street, which is the city, which is the state, and so on. Have you ever
heard of anybody who gave up trying to order a book from Amazon because he
wasn't sure which part of his address was the city? The only time there's
confusion is when a site that is likely to receive international visitors
doesn't anticipate them with generic labels ("State, province, etc." versus
"State"; "ZIP Code" versus "Postal Code"), provides a drop-down list for
selecting the state without providing an alternate entry method for users
from other countries, and indiscriminately applies locale-specific
validation rules for postal codes, phone numbers, and so forth.

There *are* applications where the address is entered solely for
reproduction as is, and where there is no need to extract the components of
the address. I have built such applications, and in those cases I have made
"address" a single piece of data, with a multi-line entry field.

As for people's names, there are plenty of situations where they *don't*
need to be sorted, and in those cases, again, a single data item and a
single entry field suffice. This is especially true for names of people
other than the person on whose behalf a form is being completed. These
include data with labels like "Name of Spouse", "Name of Beneficiary", "Name
of Emergency Contact", and so forth.

[Lachlan Hunt]

koray wrote:

hi everyone,

in my form i have to take some date information in dd-mm-yy format.
but i don't want user to use tabs while typing. for example s/he
should simply type 280104 but 28/01/04 must appear.

what can i do for that?
should i use three input tags? but then, how can i make the cursor
jump to the next field when typing in current field is done?
or if i use one input tag, how can i keep '/' signs in the field fixed
when user types the date?

Here's a better idea for you. Use client side script to provide a
date widget that replaces a single text field (used for the fallback)
and let the user pick the date graphically. I've started working on
scripts to do this a few weeks ago during my spare time (though I
haven't updated it for a little while). It's still very much under
development, and much of it will change and actually become functional,
but it's a reasonable demonstration of how to at least generate a date
widget.

At the moment, it uses the built in javascript date object to parse a
date in the format: D MMMM YYYY (eg. 16 July 2004), but there's the
start of a script to parse an ISO 8601 date. It then generates the
calendar and highlits the current system date, and the date in the form
contol Feel free to experement with it. and if you like, send me any
changes.

The script, example form and some documentation are available for
viewing here:

http://www.lachy.id.au/script/examples/datetime/
http://www.lachy.id.au/xhtml/examples/forms/datetime/

The individual files should not yet be considered stable, and may be
modified, renamed or removed, but these directories will contain the
latest changes as I write and publish them (when I eventually find more
time to think about doing it).

--
Lachlan Hunt
http://www.lachy.id.au/
la**********@lachy.id.au.update.virus.scanners

Remove .update.virus.scanners to email me,
NO SPAM and NO VIRUSES!!!

[Brian]

Harlan Messinger wrote:

Brian wrote...

If it's unclear how the user's name should be represented,
shouldn't there be a single name field? Let the user type it in
as they see fit.
Forms don't split up entry of people's names just for fun. The
essential need behind split entry of the user's name is to be able
to sort alphabetically on family name.

I suppose. But a database can sort on a name, whether first + last or
last only.

I think addresses would be much easier that way, too. Where does
the postal code go? After the city (and state), like in the US,
or before it, like in France?

The requirements of most applications require the address data to
be split. I don't know about other countries, but U.S.
organizations, to get favorable postage rates, need to be able to
print mailing labels in order by ZIP (postal) code.

In that case, I might go for 2 fields: a mailing label <TEXTAREA>, and
a postal code for sorting. Of course, that raises the potential
problem that people might then not put the code in the <TEXTAREA>.
It's really hard to build a parser that knows all the rules
necessary for international commerce, but in spite of your
suggestion to the contrary I think most people can be counted on to
know which part of their address is the street, which is the city,
which is the state, and so on.
My point wasn't that users would get confused. My point was twofold:
(1) users can enter their address more easily in a textarea compared
to 6 input type=text elements. (2) it's not the users who will get
confused, it's the organization. It's hard for a commerce site to know
the proper address format for the US, France, China, Tanzania, etc.
Once they collect the city and postal code in separate inputs, how
will they know how to lay them out on their mailing labels?
from other countries, and indiscriminately applies locale-specific
validation rules for postal codes, phone numbers, and so forth.

Again, for telephone numbers, one should be "liberal in what you
accept": allow 0 or 1 at the beginning, allow space and formatting
characters ()-, and allow a variable amount of digits. This assumes
international visitors. For a site restricted to a country, a more
restrictive format may be appropriate.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Harlan Messinger]

"Brian" <us*****@julietremblay.com.invalid> wrote in message
news:10*************@corp.supernews.com...

Harlan Messinger wrote:

Brian wrote...

If it's unclear how the user's name should be represented,
shouldn't there be a single name field? Let the user type it in
as they see fit.
Forms don't split up entry of people's names just for fun. The
essential need behind split entry of the user's name is to be able
to sort alphabetically on family name.

I suppose. But a database can sort on a name, whether first + last or
last only.

Except in Iceland and some other countries, the need is to sort on family
name, so first + last is inadequate, and unknown order is worse.

I think addresses would be much easier that way, too. Where does
the postal code go? After the city (and state), like in the US,
or before it, like in France?
The requirements of most applications require the address data to
be split. I don't know about other countries, but U.S.
organizations, to get favorable postage rates, need to be able to
print mailing labels in order by ZIP (postal) code.

In that case, I might go for 2 fields: a mailing label <TEXTAREA>, and
a postal code for sorting. Of course, that raises the potential
problem that people might then not put the code in the <TEXTAREA>.

Then you're asking people to enter the same information twice. And it still
leaves state and city unavailable.

It's really hard to build a parser that knows all the rules
necessary for international commerce, but in spite of your
suggestion to the contrary I think most people can be counted on to
know which part of their address is the street, which is the city,
which is the state, and so on.
My point wasn't that users would get confused. My point was twofold:
(1) users can enter their address more easily in a textarea compared
to 6 input type=text elements. (2) it's not the users who will get
confused, it's the organization. It's hard for a commerce site to know
the proper address format for the US, France, China, Tanzania, etc.

Right, and it's a two-edged sword, because the address is needed for two
basic purposes: (1) mailing, and (2) data processing. You are correct that,
given the components of arbitrary addresses around the world, it is
challenging to put them back into the correct order for mailing. And on the
other hand, if the user enters the address in a single block, it is
challenging to break it up into the needed components.
Once they collect the city and postal code in separate inputs, how
will they know how to lay them out on their mailing labels?
I *think* that fewer problems arise if a package winds up being shipped to

55 Avenue des Paradisiers
Brussels, Brabant 1160
BELGIUM

instead of

Avenue des Paradisiers, 55
1160 Brussels
BELGIUM

than arise if the software thinks 1160 is the city and Brussels is the state
and therefore never sends the requested material at all.

from other countries, and indiscriminately applies locale-specific
validation rules for postal codes, phone numbers, and so forth.

Again, for telephone numbers, one should be "liberal in what you
accept": allow 0 or 1 at the beginning, allow space and formatting
characters ()-, and allow a variable amount of digits. This assumes
international visitors. For a site restricted to a country, a more
restrictive format may be appropriate.

[Brian]

Harlan Messinger wrote:

Brian wrote...

In that case, I might go for 2 fields: a mailing label
<TEXTAREA>, and a postal code for sorting.

Then you're asking people to enter the same information twice. And
it still leaves state and city unavailable.

It's trivial to look up a city/state by zip code.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Jukka K. Korpela]

Neal <ne*****@yahoo.com> wrote:

A name field is filled in by the user with their name in their
preferred form, so one field is fine.
It depends. The point that Andreas made is a good one when further
processing requires a given name and a surname (if they exist) to be
recognized. We cannot really recognize them from a name alone, without
further information.

But quite a many forms, if not most, that prompt for a name will use it
as an atomic unit only, e.g. to be printed in an envelope, and stored
into a data base for that purpose only. (If you need to identify
customers, you really need unique customer identifiers assigned by you,
instead of unique personal names.)
Dates, though, have other uses. You might want to order things
chronologically, - -

Yes, and most use of dates requires a separation of year, month, day of
month. But how you achieve that is a different thing. Maybe I'm strange,
but I find it more comfortable to type 2004-07-15 or 2004 07 15 or
whatever needs to be typed than to type 2004 followed by 07 followed by
15 in three different fields, _even if_ there's "auto-tabbing" (i.e., the
cursor automatically moves to the second field after I have typed in four
digits into the first one) and even though I know well the idea behind
that. A date is a unit of information to me. So is my name, but I find it
much more natural to use different fields for the different components of
the name.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Harlan Messinger]

"Brian" <us*****@julietremblay.com.invalid> wrote in message
news:10*************@corp.supernews.com...

Harlan Messinger wrote:

Brian wrote...

In that case, I might go for 2 fields: a mailing label
<TEXTAREA>, and a postal code for sorting.

Then you're asking people to enter the same information twice. And
it still leaves state and city unavailable.

It's trivial to look up a city/state by zip code.

Well, that's true--if the business has invested in a postal database and
keeps it up to date--and does the same for every country from which business
might be coming in.

[Dr John Stockton]

JRS: In article <ON*****************@news-server.bigpond.net.au>, seen
in news:comp.infosystems.www.authoring.html, Lachlan Hunt <lachlan.hunt@
lachy.id.au.update.virus.scanners> posted at Thu, 15 Jul 2004 07:57:34 :

koray wrote: Also, if
your interested, and would like to use the ISO 8601 format, then use
this regex.

/([0-9]{4})[-\/]?([0-9]{2})[-\/]?([0-9]{2})/
this allows
YYYY-MM-DD
YYYY/MM/DD
YYYYMMDD
(as well as incorrect versions like YYYY/MM-DD, but that doesn't really
matter, as long as it supports the correct versions)

It is easy enough, IIRC, to use a back-reference to force the second
delimiter to match the first.

what can i do for that?
should i use three input tags? but then, how can i make the cursor
jump to the next field when typing in current field is done?

Drop-downs or multiple text fields are reasonable, perhaps desirable,
for casual visitors and/or management staff. For data-entry staff
entering multiple dates routinely, ISTM best to require the order YMD,
and to allow any delimiting whatsoever; a RegExp /(\d+)\D+(\d+)\D+(\d+)/
will pick out the fields. You could also allow /(\d\d\d\d)(\d\d)(\d\d)/
or /(\d+)(\d\d)(\d\d)/ and use whichever matches.

As may have been noted, I am not a professional typist. Yet I can enter
a date by typing 8-10 characters in about half the time I need for using
three drop-downs.

Automatic insertion of delimiters needs careful programming to allow for
backspace & pasteing.

For javascript date input and validating, see via below; note first what
the FAQ has to say on the subject.

The shortest and the fastest code are both short enough to be deployed
client-side.

P.S. If the application is not international, then it is reasonable to
stipulate the locally-preferred Y M D order, if native staff are being
used.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> JL / RC : FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[gmuldoon]

@julietremblay.com.invalid says...

It's trivial to look up a city/state by zip code.

Only if your app is purely US-centric.

street Address: 1 High Street
zip code: 2480
country: Australia

In Australia, this could end up as being any one of half a dozen
different addresses. Multiple nearby small towns or suburbs can share a
common "zip" code (postcode). There is definitely no uniqueness of
street names within a postcode.

Geoff M

[Brian]

gmuldoon wrote:

Brian says...

It's trivial to look up a city/state by zip code.
Only if your app is purely US-centric.

Or France-centric, or Germany-centric, or...
street Address: 1 High Street
zip code: 2480
country: Australia

In Australia, this could end up as being any one of half a dozen
different addresses. Multiple nearby small towns or suburbs can share a
common "zip" code (postcode). There is definitely no uniqueness of
street names within a postcode.

That's surprising, and good to know. So what does the postal code add
to addresses in Australia?

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[gmuldoon]

@julietremblay.com.invalid says...

1 High Street
zip code: 2480
country: Australia

In Australia, this could end up as being any one of half a dozen
different addresses. Multiple nearby small towns or suburbs can share a
common "zip" code (postcode). There is definitely no uniqueness of
street names within a postcode.

That's surprising, and good to know. So what does the postal code add
to addresses in Australia?

Nominates a preliminary postal distribution centre for subsequent
further manual sorting, where local staff will filter on the
city/town/suburb and then street fields.

In the above example 2480, the leading digit of the postcode indicates
the state (NSW/ACT=2, VIC=3, QLD=4, etc), the 480 takes it within NSW to
the Lismore distribution centre.

2480 can mean Lismore (city), Goonellabah (suburb of Lismore), Nimbin
(village 30km from city), Dorroughby (rural district), etc. Just
checked using link below - 72 different delivery areas! At least 3-4
High Streets that I know of in that set.

2481 will go to nearby Byron Bay distribution centre (for Byron Bay,
Suffolk Park, etc.)

See:
http://www1.auspost.com.au/postcodes/

Geoff M

[Pierre Goiffon]

"gmuldoon" <gm*************@scu.edu.au> a écrit dans le message de
news:MP************************@news.asgard.net.au

street Address: 1 High Street
zip code: 2480
country: Australia

In Australia, this could end up as being any one of half a dozen
different addresses.

In france a Zip code could also be shared by several towns, so the same
number and street name for a given zip code could possibly belong to one
town or another.

[Brian]

Pierre Goiffon wrote:

In france a Zip code could also be shared by several towns, so the same
number and street name for a given zip code could possibly belong to one
town or another.

I was about to argue with you when I remembered where you're from.
;-) But this suprised me even more than the news about Australian
codes. AIUI, each town or city gets a 2 digit code -- the first two
digits of the postal code -- and uses the last 3 digits for internal
use (e.g., divide by arrondisement). But I suppose the rural regions
are different, and share a 2 digit code among several towns?

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Claire Tucker]

On Thu, 15 Jul 2004 16:16:02 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.fi> wrote:

Yes, and most use of dates requires a separation of year, month, day of
month. But how you achieve that is a different thing. Maybe I'm strange,
but I find it more comfortable to type 2004-07-15 or 2004 07 15 or
whatever needs to be typed than to type 2004 followed by 07 followed by
15 in three different fields, _even if_ there's "auto-tabbing" (i.e., the
cursor automatically moves to the second field after I have typed in four
digits into the first one) and even though I know well the idea behind
that. A date is a unit of information to me. So is my name, but I find it
much more natural to use different fields for the different components of
the name.

Your post inspired me to try the use of CSS to present three form
fields as one. The following fragments give the gist:

..dateinput {
border: 2px inset #eeeeee;
background: #ffffff;
color: #000000;
}

..dateinput input {
border: 0;
text-align: center;
}

.....

<span class="dateinput">
<input type="text" size="4" maxlength="4"> -
<input type="text" size="2" maxlength="2"> -
<input type="text" size="2" maxlength="2">
</span>

This appears, in IE and Firefox on Windows, like a single text field
with three input parts separated by hyphens. It's a bit like the
fields Windows uses for entry of numeric IP addresses in Control
Panel. Some scripting would be necessary to implement the
"auto-tabbing" behavior.

Of course, there's no way in CSS to say "make this look like a text
field", so the specification of the dateinput class is specific to my
configuration in Windows, but I wonder if you would find this entry
more natural since it looks like one field.

(I don't necessarily recommend the above approach. It's just an
experiment.)

-Claire

[Leif K-Brooks]

Claire Tucker wrote:

Your post inspired me to try the use of CSS to present three form
fields as one. The following fragments give the gist:
<snip>

Doesn't look right in Firefox 0.9 on Fedora Core 2:
http://ecritters.biz/inputfieldthing.png

[Claire Tucker]

On Sun, 18 Jul 2004 18:59:29 -0400, Leif K-Brooks
<eu*****@ecritters.biz> wrote:

Claire Tucker wrote:

Your post inspired me to try the use of CSS to present three form
fields as one. The following fragments give the gist:
<snip>

Doesn't look right in Firefox 0.9 on Fedora Core 2:
http://ecritters.biz/inputfieldthing.png

Well, as I noted there is really no way to make it look "right" if
that means to look like a normal INPUT field would look, since CSS
doesn't allow rules to borrow style properties from other selectors.

I expected it to do odd things in some cases, since the properties I
chose to set were very limited. In order to safely re-style INPUT
fields (which is, of course, a bad idea in most cases) it's best to
override a whole tonne of different properties to ensure that no
browser has an odd rules in its user-agent stylesheet which give
unexpected results.

With that said, Firefox's rendering is quite odd. I wonder what CSS
properties made it draw the input field background over the border of
the parent...

Best regards,
-Claire

[Leif K-Brooks]

Claire Tucker wrote:

With that said, Firefox's rendering is quite odd. I wonder what CSS
properties made it draw the input field background over the border of
the parent...

Without doing any testing, my guess is that the input box has a height
greater than 1em, so its background covers the span's border.

[Pierre Goiffon]

"Brian" <us*****@julietremblay.com.invalid> a écrit dans le message de
news:10*************@corp.supernews.com

In france a Zip code could also be shared by several towns, so the
same number and street name for a given zip code could possibly
belong to one town or another.
I was about to argue with you when I remembered where you're from.
;-)

:)
I answered beacause I practice mutch this subject in my last job - I worked
4 years for www.Webcity.fr, a cultural news website for citizens, the place
where you can find what to do tonight in your town, all the concerts for the
months to come and mutch more (to summarize it's a cultural agenda and an
adressbook). So as the site at this time covered more than 80 towns in
France, the question of zip codes was pretty important in our database.
AIUI, each town or city gets a 2 digit code -- the first two
digits of the postal code -- and uses the last 3 digits for internal
use (e.g., divide by arrondisement). But I suppose the rural regions
are different, and share a 2 digit code among several towns?

Not exactly. France has a long history, and a long tradition of
administrations, so it's a bit complicated. First, there are two main
nomenclatures used in France : postal zip codes (PTT) and INSEE ones. For
adress, that's of course the first to consider.

Now, France is divided in /régions/, and then in /départements/ (not sure of
the translations sorry, and I'm afraid it is one of these "faux ami" words :
exactly the same orthography but not the same meaning at all).

So, the regions are identified by their names, and departements have an
associated unique number. For exemple I'm now writing to you from St Martin
d'Hères in the /département/ "Isère" (38), /région/ "Rhônes Alpes". The zip
code is 38400, and the first two numbers are as you can see the number of
the /département/. A few month ago I was living in the same /région/ but
another departement, "Ain" and the postal zip code begins with 01, the "Ain"
number. You can see also this /département/ number at the end of all french
car number plates (exemple 4821 WX 38).

For metropolitan France (the DOM/TOM -Guyane, St Pierre et Miquelon, ...-
have a different structure of postal zip codes I think) the 3 last numbers
are to identified the place where you leave in that /département/. Whitch is
not the /commune/ (town) neither a /groupement de communes/ (towns union),
neither a /canton/ (group of towns defined for elections). I don't know at
all the origin of this division, why some towns have the same postal zip
code... Well, must be some french postal employees that decide this a long
time ago. As for other public services, postal services are a state monopoly
in France and we're really used to these kind of situations :)

[Pierre Goiffon]

"Claire Tucker" <fa**@invalid.invalid> a écrit dans le message de
news:hj********************************@4ax.com

Your post inspired me to try the use of CSS to present three form
fields as one. The following fragments give the gist:

.dateinput {
border: 2px inset #eeeeee;
background: #ffffff;
color: #000000;
}

.dateinput input {
border: 0;
text-align: center;
}

....

<span class="dateinput">
<input type="text" size="4" maxlength="4"> -
<input type="text" size="2" maxlength="2"> -
<input type="text" size="2" maxlength="2">
</span>

For non CSS browser you should at least add signifiant labels for each input
tag. You could hide them if CSS is enabled via a display:none for exemple