Re: nobr tag

[Andreas Prilop]

On Fri, 4 Jul 2008, fidokomik wrote:

I tried to ask in other group

Which?

but without answer so I try to ask again here.

I think <news:comp.infosystems.www.authoring.htmlis better suited.

I found at W3C web that tag <nobris not valid in HTML 4.01
specification.
Can anybody help me to find a way to substitute this tag?

This is discussed in detail at
http://www.cs.tut.fi/~jkorpela/html/nobr.html

For example central-european date format is "20.01.2008".

There is no such thing as a "Central European date format".
On the contrary, International Standard ISO 8601 has been
adopted as European Standard EN 28601.
http://www.w3.org/QA/Tips/iso-date

Your sample date should be written 2008-01-20. To prevent
a line break, you might write the non-breaking hyphen ‑
instead of the ASCII hyphen.

--
In memoriam Alan J. Flavell
http://groups.google.com/groups/sear...Alan.J.Flavell

[Dr J R Stockton]

In comp.infosystems.www.authoring.html message <Pine.GSO.4.63.0807041606
24*******@s5b004.rrzn.uni-hannover.de>, Fri, 4 Jul 2008 16:16:14,
Andreas Prilop <pr********@trashmail.netposted:

>

>For example central-european date format is "20.01.2008".

There is no such thing as a "Central European date format".
On the contrary, International Standard ISO 8601 has been
adopted as European Standard EN 28601.

The dotted DMY format is commonly used demotically in central Europe.
Get out of your ivory tower and see what is used by ordinary
Hanoverians. It would be naive to assume that only standardised forms
are used ; IIRC, YYYY-MM-DD is in a US Federal standard, for example.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/- w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/- see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Stan Brown]

Fri, 4 Jul 2008 23:23:46 +0100 from Dr J R Stockton
<jr*@merlyn.demon.co.uk>:

IIRC, YYYY-MM-DD is in a US Federal standard

It may be a US Federal standard, or it may not.

But it *is* an ISO standard, number 8601 to be exact. (And I am
amazed that I remember that number.)

reference: http://www.cl.cam.ac.uk/~mgk25/iso-time.html

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

[fidokomik]

On 5 Èec, 00:23, Dr J R Stockton <[e-mail]:

In comp.infosystems.www.authoring.htmlmessage <Pine.GSO.4.63.0807041606
[e-mail]>, Fri, 4 Jul 2008 16:16:14,
Andreas Prilop <[e-mail]:

For example central-european date format is "20.01.2008".

There is no such thing as a "Central European date format".
On the contrary, International Standard ISO 8601 has been
adopted as European Standard EN 28601.

The dotted DMY format is commonly used demotically in central Europe.
Get out of your ivory tower and see what is used by ordinary
Hanoverians. *It would be naive to assume that only standardised forms
are used ; IIRC, YYYY-MM-DD is in a US Federal standard, for example.

I'm not in ivory tower but DMY date is our National language standard.
This is
not technical but ortography problem. By me pages for human must keep
ortography, right? The same date ortography is defined for Germans,
Austrians
and Slovaks.
For example official name of my country is "Czech Republic" in
english
laguage, but "Ceská republika" in czech language. Yes, right
ortography is
lower "r" at begin of "republika".
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your
mail from another non-spammer site please.)

[Jukka K. Korpela]

Scripsit Dr J R Stockton:

In comp.infosystems.www.authoring.html message
<Pine.GSO.4.63.0807041606 24*******@s5b004.rrzn.uni-hannover.de>,
Fri, 4 Jul 2008 16:16:14, Andreas Prilop <pr********@trashmail.net>
posted:

>>

>>For example central-european date format is "20.01.2008".

There is no such thing as a "Central European date format".
On the contrary, International Standard ISO 8601 has been
adopted as European Standard EN 28601.

I vaguely remember having read that EN 28601 has been withdrawn (though
this would be a technical matter, related to the oddities of European
standardization).

The dotted DMY format is commonly used demotically in central Europe.

Also in Northern Europe, and in Finland it is a national standard, but
without leading zeros.

Get out of your ivory tower and see what is used by ordinary
Hanoverians. It would be naive to assume that only standardised forms
are used ;

And everyone hopefully realizes that _any_ date notation using digits
(instead of month names or abbreviations) is ambiguous in the real
world. The ISO 8601 format is the best shot, but it should always be
used with a four-digit year; notations like 08-07-09 actually occur in
packages...

This all has very little to do with HTML, however. The answer to the
question about preventing line breaks is that <nobr>...</nobris
safest. For other approaches, check my page that Andreas mentioned.

The interesting question is: under which circumstances would a browser
(which?) break a string like 20.01.2008?

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Ben C]

On 2008-07-05, Jukka K. Korpela <jk******@cs.tut.fiwrote:
[...]

And everyone hopefully realizes that _any_ date notation using digits
(instead of month names or abbreviations) is ambiguous in the real
world. The ISO 8601 format is the best shot, but it should always be
used with a four-digit year; notations like 08-07-09 actually occur in
packages...

I once had a cheque sent back because I'd used an ISO date with a four
digit year.

Since the cheque was for a completely unfair fine I wrote back enclosing
a print-out of United Nations Recommendation 7 "Numerical Representation
of Dates, Time, and Periods of Time" and asked them if they disregarded
all UN recommendations as a matter of policy.

The idea was to waste their time and also to imply they belonged in the
same general category as Saddam Hussein.

Several weeks later they wrote a long letter back apologizing and
explaining that the cheque had been rejected in error.

[Sherman Pendley]

Ben C <sp******@spam.eggswrites:

I once had a cheque sent back because I'd used an ISO date with a four
digit year.

Was this in the US? (Given the spelling, I suspect not.) I once worked
at a bank here, and I was told in training that the date on a check is
not legally binding. If you wrote a check and dated it 2020-08-09, a
US bank will cash it today.

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Ben C]

On 2008-07-05, Sherman Pendley <sp******@dot-app.orgwrote:

Ben C <sp******@spam.eggswrites:

>I once had a cheque sent back because I'd used an ISO date with a four
digit year.

Was this in the US? (Given the spelling, I suspect not.) I once worked
at a bank here, and I was told in training that the date on a check is
not legally binding. If you wrote a check and dated it 2020-08-09, a
US bank will cash it today.

In the UK, but it wasn't the bank who were complaining about the
cheque-- they would have known better-- but the thugs who were trying to
fine me.

[Dr J R Stockton]

In comp.infosystems.www.authoring.html message <MPG.22d8891f1cad184a98b6
[e-mail]>, Fri, 4 Jul 2008 20:23:51, Stan Brown
<th************@fastmail.fmposted:

>Fri, 4 Jul 2008 23:23:46 +0100 from Dr J R Stockton
<jr*@merlyn.demon.co.uk>:

>IIRC, YYYY-MM-DD is in a US Federal standard

It may be a US Federal standard, or it may not.

But it *is* an ISO standard, number 8601 to be exact. (And I am
amazed that I remember that number.)

I was rather assuming that we would all expect us all to realise that,
if only by reading the article to which I was responding. See via sig.

>reference: http://www.cl.cam.ac.uk/~mgk25/iso-time.html

That's somewhat dated; it seems to imply that 8601:2004 is not available
for download.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/- w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/- see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[fidokomik]

On 5 Èec, 17:15, "Jukka K. Korpela" <[e-mail]:

This all has very little to do with HTML, however. The answer to the
question about preventing line breaks is that <nobr>...</nobris
safest. For other approaches, check my page that Andreas mentioned.

Yes I'm using <nobr>...</nobrbut it is mentioned in HTML 4.01 as
invalid (not exists) tag ;-)

The interesting question is: under which circumstances would a browser
(which?) break a string like 20.01.2008?

Maybe in IE 5x or not updated IE6.0. When I'm testing it today it work
well,
but I had some problems few months or years ago. Maybe my example is
wrong but a well example (bad wrapping) is "Temperature is 10 deg.C in
country".
In some cases it is wrapped as

Temperature is 10
deg.C in country.

but should be
Temperature is
10 deg.C in
country.
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your
mail from another non-spammer site please.)

Please reply to <petr AT practisoft DOT cz>

[Jukka K. Korpela]

Scripsit fidokomik:

Yes I'm using <nobr>...</nobrbut it is mentioned in HTML 4.01 as
invalid (not exists) tag ;-)

It's not mentioned in HTML 4.01 at all. It's still a better supported
method than any of the alternatives.

>The interesting question is: under which circumstances would a
browser (which?) break a string like 20.01.2008?

Maybe in IE 5x or not updated IE6.0.

I'm not saying that it's impossible, but I'm pretty sure I would have
observed it if it actually had occurred. I suppose you have observed
some similar effect and expect that IE could break after periods as
well.

Turning now to page 273 in my book "Unicode Explained", we learn that
the period (formally in Unicode: FULL STOP) belongs to line breaking
class IS, infix separator, which means (flip to p. 278 for a quick
summary) that no break is allowed between a digit and a period (even if
spaces intervene) or between a period and a digit (unless a space
intervenes). IE does not follow the Unicode line breaking rules except
partially, but usually when it does odd things in line breaking, it does
so because of its partial attempts at following those rules. Hence it
would be rather unexpected if it broke a string like 20.01.2008.

Maybe my example is
wrong but a well example (bad wrapping) is "Temperature is 10 deg.C in
country".

That's a different issue and involves line breaking issues of two kinds.

In some cases it is wrapped as

Temperature is 10
deg.C in country.

but should be
Temperature is
10 deg.C in
country.

The rules for expressing quantities say that a line break between a
number and a unit symbol is not permitted. General line breaking rules
and formatting algorithms cannot deal with such cases, since they
operate at lower "protocol levels". An author needs to take care of the
problem, and in this special case, you could use the no-break space,
writing it as such or as entity reference &nbsp;, which works fine, so
you would not need the <nobrmarkup.

However, there's a different issue with the unit symbol. The notation
"deg.C" does not comply with standards. The standard symbol for degrees
Celsius is °C, and if you don't have a handy keyboard setting where you
can type the degree sign ° conveniently, you can use the entity
reference &deg;.

So far so good: you could write
10&nbsp;&deg;C
and this would mostly work fine. However, by the Unicode rules, the
degree sign is in line breaking class PO, postfix (numeric), which means
that there is a direct break opportunity (i.e., line break is allowed
even if no spaces intervene) between it and e.g. an alphabetic character
after it. So when a suitable - or, rather, unsuitable - situation
arises, the expression might get broken as
10 °
C
which is really bad, and that's why I recommend
<nobr>10 &deg;C</nobr>

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Jukka K. Korpela]

Scripsit Andreas Prilop:

- - International Standard ISO 8601 has been
adopted as European Standard EN 28601.

EN 28601 has been withdrawn. (I can't check the exact date, but it was
in 2006 or earlier.)

Your sample date should be written 2008-01-20. To prevent
a line break, you might write the non-breaking hyphen ‑
instead of the ASCII hyphen.

This is a tricky issue, and actually HTML related too.

Checking ISO 8601:2004, available via
http://isotc.iso.org/livelink/liveli...nodeid=4021199
we can find that the standard does not quite exactly define the
characters used in notations, but fairly well. It clearly distinguishes
"hyphen", "minus", and "hyphen-minus" (i.e., the ASCII hyphen) as
different characters. The character to be used in a notation like
2008-01-20 is called hyphen, so in conjunction with the distinction I
mentioned, we can conclude that character is U+2010 HYPHEN, though it
may be replaced by U+002D HYPHEN-MINUS. The standard allow the
replacement "in an environment where use is made of a character
repertoire based on ISO/IEC 646", which is standardese for "ASCII-based
contexts", but I think we can interpret the "based on" part liberally so
that the replacement is allowed whenever MINUS cannot be used (e.g.,
when a document's encoding is ISO 8859).

Thus, I think we can conclude that U+2011 NON-BREAKING HYPHEN is not
permitted by the ISO 8601 standard. It is compatibility equivalent to
U+2010, but this does not mean identity. Thus, to prevent line breaks in
an ISO 8601 date notation, you would need to use higher-level protocols,
such as markup (<nobr>...</nobr>) or markup with CSS, i.e.
<span class="date">2008-01-20</span>
with
..date { white-space: nowrap; }

This isn't really as surprising as it may sound. ISO 8601 notations are
primarily meant for use in data interchange and as coded representations
rather than normal text (plain or marked-up), though they surely have
their usefulness in a multilingual context where any other notation
would be ambiguous or non-neutral.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/