Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Numeric character references in W3C HTML 5.2?

15 views
Skip to first unread message

David E. Ross

unread,
Apr 6, 2018, 11:08:28 AM4/6/18
to
On 4/6/2018 5:57 AM, Stefan Ram wrote:
> I have a document titled:
>
> W3C
> HTML 5.2
> Editor’[sic]s Draft, 29 December 2016
>
> (»[sic]« was inserted by me above - S. R.)
>
> . I was searching for these five strings in that document:
>
> numeric en
> numeric ch
> numerical en
> numerical ch
> &#
>
> . All gave no hits.
>
> Does this mean, there are no numeric character references in
> HTML 5.2? So, one cannot use »A« to insert an »A« into
> the document text?
>

You are trying to use numeric character references. PLEASE DO NOT, even
if you use Unicode code point numbers (which you are not).

Instead, use named character references (formerlly known as entity
references). See
<https://www.w3.org/TR/2017/REC-html51-20171003/syntax.html#named-character-references>.
While that chart does show Unicode code points, HTML does not support
all code points.

See also my <http://www.rossde.com/malaprops/writing_internet.html>.

--
David E. Ross
<http://www.rossde.com/>

First you say you do, and then you don't.
And then you say you will, but then won't.
You're undecided now, so what're you goin' to do?
From a 1950s song
That should be Donald Trump's theme song. He obviously
does not understand "commitment", whether it is about
policy or marriage.

Jukka K. Korpela

unread,
Apr 6, 2018, 11:52:09 AM4/6/18
to
David E. Ross wrote:

> You are trying to use numeric character references. PLEASE DO NOT, even
> if you use Unicode code point numbers (which you are not).

The only example mentioned was &#65; for “A”. It surely uses a Unicode
code point number.

> Instead, use named character references

They are pseudo-mnemonic in an often misleading way, they do not add any
expressive power, they do not exist except for a fraction of the set of
Unicode characters, they appear in different sets in different versions
of HTML and have had varying browser support, and their meanings have
even changed from one version to another-

> See
> <https://www.w3.org/TR/2017/REC-html51-20171003/syntax.html#named-character-references>.

Why are you referring to HTML 5.1 edition 8, when HTML 5.2 is a W3C
recommendation?

> While that chart does show Unicode code points, HTML does not support
> all code points.

Whatever you mean by that, it is most probably wrong.
Well, there you recommend HTML 4.01, but most of the page appears to be
about HTML in “newsgroups”. The comp.infosystems.www.authoring.html
newsgroup, one of the few Usenet groups left with some meaningful
traffic, in about HTML authoring for the World Wide Web, where numeric
character references have worked well since the 1990s.

--
Yucca, http://jkorpela.fi

Eli the Bearded

unread,
Apr 6, 2018, 2:15:19 PM4/6/18
to
In comp.infosystems.www.authoring.html,
David E. Ross <nob...@nowhere.invalid> wrote:
>> Does this mean, there are no numeric character references in
>> HTML 5.2? So, one cannot use »&#65;« to insert an »A« into
>> the document text?
> You are trying to use numeric character references. PLEASE DO NOT, even
> if you use Unicode code point numbers (which you are not).

65 is a valid Unicode codepoint for LATIN LETTER CAPITAL A. Do you have
any reson for asking people not to use codepoints for encoind? I churn
out thousands per day, and until there is a way to name every character
in Unicode I'm likely to continue doing so.

> Instead, use named character references (formerlly known as entity
> references). See

That list is pitifully small compared to the full size of Unicode. Where
is the Braille? The chess pieces? The emojis? The Ogham?

> While that chart does show Unicode code points, HTML does not support
> all code points.
> See also my <http://www.rossde.com/malaprops/writing_internet.html>.

That says:
In any case, while code-numbers in the 8000 range are part of the
Unicode standard, they are not part of the HTML specification. This
further supports my position that character references (based on
code-numbers) should not be used.

Your position seems to be based on WAH-WAH-WAH-I-DON'T-SEE-IT-IT'S-NOT-REAL.

https://www.w3.org/TR/html5/syntax.html#character-references

In certain cases described in other sections, text may be mixed with
character references. These can be used to escape characters that
couldn't otherwise legally be included in text.

Which has three subheadings:

Named character references
Decimal numeric character reference
Hexadecimal numeric character reference

And then says:

The numeric character reference forms described above are allowed to
reference any Unicode code point other than U+0000, U+000D,
permanently undefined Unicode characters (noncharacters), surrogates
(U+D800--U+DFFF), and control characters other than space
characters.

Read that again "any Unicode code point".

Elijah
------
&#x1F595;

Thomas 'PointedEars' Lahn

unread,
Apr 6, 2018, 3:37:29 PM4/6/18
to
Jukka K. Korpela wrote:

> David E. Ross wrote:
>> You are trying to use numeric character references. PLEASE DO NOT, even
>> if you use Unicode code point numbers (which you are not).
>
> The only example mentioned was &#65; for “A”. It surely uses a Unicode
> code point number.
^^^^^^
The proper term is “code point _value_”. Otherwise yes, 65 is the *decimal*
code point value for that Unicode character, U+0041 LATIN CAPITAL LETTER A.

Perhaps the underlying reason for the David E. Ross’ claim is this:

It is a common misconception that Unicode characters would only be
"characters that are not contained in 8-bit character sets" such as
ISO(/IEC)-8859-1. When in fact the Unicode character set is,
intentionally, by characters (not necessarily also by code point
value) a superset of all other character sets.

<http://www.unicode.org/faq/basic_q.html>
<http://www.unicode.org/charts/PDF/U0000.pdf>

>> Instead, use named character references
>
> They are pseudo-mnemonic
^^^^^^^^^^^^^^^^^^^^^^^^ (meaningless; “mnemonic” is _not_ an adjective)

> in an often misleading way,
^^^^^ ^^^^^^^^^^ (According to whom, for whom?)
(How often?)

<https://en.wikipedia.org/wiki/Weasel_word>

> they do not add any expressive power,

IBTD. Sometimes they do as not all (monospace) fonts are equally suited to
display certain Unicode characters in a text editor.

Sometimes it is even syntactically necessary to use them, for example
“&amp;” instead of a standalone “&” in a “href” attribute value.

> they do not exist except for a fraction of the set of Unicode characters,

True. Although the subset in HTML 5.x is larger than in HTML 4.01/XHTML
1.x, one can surmise that in both cases named character references have only
been *predefined* for the most used Unicode characters, including those that
would conflict with HTML and XML syntax rules.

> they appear in different sets in different versions of HTML and have had
> varying browser support, and their meanings have even changed from one
> version to another-

Cite evidence.

>> See
>> <https://www.w3.org/TR/2017/REC-html51-20171003/syntax.html#named-character-references>.
>
> Why are you referring to HTML 5.1 edition 8, when HTML 5.2 is a W3C
> recommendation?

He was _not_ referring to “HTML 5.1 edition 8”, but to HTML 5.1 _2nd_
Edition, _§ (section)_ 8.

Probably he was not aware of HTML 5.2; it became a W3C Recommendation fairly
recently, on 2017-12-14.

>> While that chart does show Unicode code points, HTML does not support
^^^^^^^^^^^^^^^^^^^^^
>> all code points.
^^^^^^^^^^^^^^^
> Whatever you mean by that, it is most probably wrong.

The last part of their sentence is *definitely* wrong:

<https://www.w3.org/TR/2017/REC-html52-20171214/infrastructure.html#unicode-code-point>

,-<https://www.w3.org/TR/html/references.html#biblio-unicode>
|
| The Unicode Standard. URL: https://www.unicode.org/versions/latest/

What can be said with certainty is that not all *fonts* support all Unicode
code points (regardless whether they are used for display in a text editor
or in Web browsers), so authors may need to provide the user with suitable
fonts if they use unusual characters, such as Egyptian hieroglyphs (this is
easier to accomplish now with Web fonts). But that has nothing to do with
HTML directly.

>> See also my <http://www.rossde.com/malaprops/writing_internet.html>.
>
> Well, there you recommend HTML 4.01, but most of the page appears to be
> about HTML in “newsgroups”.

The author also appears to be blissfully unaware of character encodings and
typography.

As is obvious from my postings (which I write under GNU+Linux), the issue on
"UNIX platforms" is _not_ the use of “smart quotes”, "smart apostrophes",
and "smart single quotes" written under Micro$~1 Windows – those are just
*typographical* quotation marks and apostrophes, and usually the *correct*
way to write text¹ – but the bug in the software producing them not to
declare the corresponding character encoding, the bug in the software
displaying them not to support declared and IANA-registered character
encodings, or the problem of the user not to choose fonts that support
those proper characters.

As always, if the encoding declaration is missing, that leaves the user
agent (software) to guess the character encoding, and even educated guesses
can easily be wrong in this context.

(All of this is equally true for clueless non-Windows users and buggy
non-Windows software.)

_______
¹ Note the difference in my postings when I use "scare quotes" (straight
quotation marks) instead of “smart quotes” (typographical quotation
marks).

> The comp.infosystems.www.authoring.html
> newsgroup, one of the few Usenet groups left with
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (Of which set of newsgroups?)

> some meaningful traffic,
^^^^ ^^^^^^^^^^^^^^^^^^ (According to whom, for whom?)
(How much?)

> in about HTML authoring for the World Wide Web, where numeric
^^^^^^^^^^^^^^^^^^^^^^ _not_ *only*

> character references have worked well since the 1990s.
^^^^^^^^^^^ (According to whom, for whom?)

Unfortunately, that is only your typical weasel-word argument again.

JFTR: IBTD.

However, as a matter of *fact*, HTML 4.01 is a Superseded Recommendation
since 2018-03-27:

,-<https://www.w3.org/TR/2018/SPSD-html401-20180327/>
|
| HTML 4.01 Specification
|
| W3C Recommendation 24 December 1999
| superseded 27 March 2018
|
| […]
|
| This specification is a Superseded Recommendation. A newer specification
| exists that is recommended for new adoption in place of this
| specification. New implementations should follow the latest version
| <https://www.w3.org/TR/html/> of the HTML specification.

Thus, HTML 4.01 and previous versions of HTML (e.g., HTML 3.2) that were not
already “obsolete” or “historic” (e.g. HTML 2.0), have been superseded by
HTML 5.2+.


PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286...@94.75.214.39>

David E. Ross

unread,
Apr 6, 2018, 3:42:20 PM4/6/18
to
On 4/6/2018 8:52 AM, Jukka K. Korpela wrote [in part]:
> I previously wrote [also in part]:
>
>> See
>> <https://www.w3.org/TR/2017/REC-html51-20171003/syntax.html#named-character-references>.
>
> Why are you referring to HTML 5.1 edition 8, when HTML 5.2 is a W3C
> recommendation?

I could not get the HTML 5.2 named character references to display
correctly. This might have been caused by some of my browser settings.
However, I had other tasks to do and could not take time to resolve that
problem. Thus, I chose the page that I could display.

David E. Ross

unread,
Apr 6, 2018, 3:52:54 PM4/6/18
to
On 4/6/2018 11:15 AM, Eli the Bearded wrote [in part]:
> I previously wrote [also in part]:
>> You are trying to use numeric character references. PLEASE DO NOT, even
>> if you use Unicode code point numbers (which you are not).
>
> 65 is a valid Unicode codepoint for LATIN LETTER CAPITAL A. Do you have
> any reson for asking people not to use codepoints for encoind? I churn
> out thousands per day, and until there is a way to name every character
> in Unicode I'm likely to continue doing so.

Too often, I see unreadable garbage because someone has composed HTML
using Unicode code points instead of named character references. Most
often, this is a result of faulty or inconsistent <head> declarations.
Even with such faulty declarations, the amount of garbage may be reduced
by using named character references, especially since they do not depend
on any charset attribute.

Generally, the garbage appears in HTML-formatted E-mail and newsgroup
messages. However, I also see this on Web pages.

Eli the Bearded

unread,
Apr 6, 2018, 4:59:35 PM4/6/18
to
In comp.infosystems.www.authoring.html,
David E. Ross <nob...@nowhere.invalid> wrote:
> On 4/6/2018 11:15 AM, Eli the Bearded wrote [in part]:
> > 65 is a valid Unicode codepoint for LATIN LETTER CAPITAL A. Do you have
> > any reson for asking people not to use codepoints for encoind? I churn
> > out thousands per day, and until there is a way to name every character
> > in Unicode I'm likely to continue doing so.
> Too often, I see unreadable garbage because someone has composed HTML
> using Unicode code points instead of named character references. Most
> often, this is a result of faulty or inconsistent <head> declarations.

Numerical encodings are ALWAYS to Unicode code points. If you have an
ISO-8859-1 document numerical encoding is the only way to include Farsi
(eg). Faulty or inconsistent declarations elsewhere are a separate issue
and not related to &#NUMBER; problems.

> Even with such faulty declarations, the amount of garbage may be reduced
> by using named character references, especially since they do not depend
> on any charset attribute.

Numerical encodings are ALWAYS to Unicode code points. They do not
depend on any charset, character set, or character encoding.

> Generally, the garbage appears in HTML-formatted E-mail and newsgroup
> messages. However, I also see this on Web pages.

Ah, why no love for "newsgroup messages"? "E-mail" and "Web" get capitals.

(ten line sig snipped)

Elijah
------
does not use a .sig

John W Kennedy

unread,
Apr 6, 2018, 11:00:29 PM4/6/18
to
On 4/6/18 3:37 PM, Thomas 'PointedEars' Lahn wrote:
> Jukka K. Korpela wrote:
>
>> They are pseudo-mnemonic
> ^^^^^^^^^^^^^^^^^^^^^^^^ (meaningless; “mnemonic” is _not_ an adjective)

Yes it is. That’s not even open for debate. OED s.v. “mnemonic”, B. 1.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

Thomas 'PointedEars' Lahn

unread,
Apr 7, 2018, 7:43:12 PM4/7/18
to
John W Kennedy wrote:

> On 4/6/18 3:37 PM, Thomas 'PointedEars' Lahn wrote:
>> Jukka K. Korpela wrote:
>>> They are pseudo-mnemonic
>> ^^^^^^^^^^^^^^^^^^^^^^^^ (meaningless; “mnemonic” is _not_ an
>> adjective)
>
> Yes it is. That’s not even open for debate. OED s.v. “mnemonic”, B. 1.

I stand corrected (see also Wiktionary, ODE, Merriam-Webster): it means
“related to mnemonics” (now that you mention it, the title “Johnny Mnemonic”
[Alliance Comm., 1995] comes to mind), and mnemonics is “the study of
techniques for remembering anything more easily”.

However, based on that definition, how do you define the *adjective*
“mnemonic” *in this context* then, and what is “pseudo-mnemonic” *in this
context* supposed to *mean*?

ISTM it is *still* a weasel-word argument.


PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14

Stan Brown

unread,
Apr 9, 2018, 9:54:58 PM4/9/18
to
On 6 Apr 2018 12:57:09 GMT, Stefan Ram wrote:
>
> I have a document titled:
>
> W3C
> HTML 5.2
> Editor?[sic]s Draft, 29 December 2016
>
> (»[sic]« was inserted by me above - S. R.)
>

Why? Do you have reason to believe that the draft was prepared by
more than one editor?

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://BrownMath.com/
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://preview.tinyurl.com/WhyWont

dorayme

unread,
Apr 11, 2018, 7:00:11 PM4/11/18
to
In article <MPG.3535e37dc...@news.individual.net>,
Stan Brown <the_sta...@fastmail.fm> wrote:

> On 6 Apr 2018 12:57:09 GMT, Stefan Ram wrote:
> >
> > I have a document titled:
> >
> > W3C
> > HTML 5.2
> > Editor?[sic]s Draft, 29 December 2016
> >
> > (»[sic]« was inserted by me above - S. R.)
> >
>
> Why? Do you have reason to believe that the draft was prepared by
> more than one editor?

I am looking at 5 editors listed for an intro to HTML 5.2
W3C Recommendation, 14 December 2017, and perhaps Stefan sees the same
or similar for what he was looking at?

--
dorayme

Jukka K. Korpela

unread,
Apr 12, 2018, 1:58:54 AM4/12/18
to
“Editor’s Draft” is a term used by the W3C, as described in the Process
Document >https://www.w3.org/Consortium/Process/>. The term is used
independently of the number of editors.

--
Yucca, http://jkorpela.fi

Jukka K. Korpela

unread,
Apr 13, 2018, 5:10:38 PM4/13/18
to
Stefan Ram wrote:

> What English requires:
>
> 0027 39 APOSTROPHE, APOSTROPHE-QUOTE

You are mistaken. This is the “vertical apostrophe”, introduced in
Remington typewriters, later adopted into the ASCII character set. It
was never part of the writing system of English, or any other human
languages, though it is part of many coding systems called “programming
languages” or “markup languages” (ObHTML: such as HTML).

> . What was there:
>
> 2019 8217 RIGHT SINGLE QUOTATION MARK, SINGLE COMMA QUOTATION MARK

That was the correct apostrophe, as defined by the centuries-old
tradition and by English-language style guides.

--
Yucca, http://jkorpela.fi

Thomas 'PointedEars' Lahn

unread,
Apr 13, 2018, 8:05:27 PM4/13/18
to
Jukka K. Korpela wrote:

> Stefan Ram wrote:
>> What English requires:
>>
>> 0027 39 APOSTROPHE, APOSTROPHE-QUOTE
>
> You are mistaken. This is the “vertical apostrophe”, introduced in
> Remington typewriters, later adopted into the ASCII character set. It
> was never part of the writing system of English, or any other human
> languages, […]

As usual, hasty generalization:

<https://en.wikipedia.org/wiki/Apostrophe#As_a_glottal_stop>

<https://en.wikipedia.org/wiki/Apostrophe#As_a_mark_of_palatalization_or_non-palatalization>

<https://en.wikipedia.org/wiki/Apostrophe#To_separate_morphemes>

<https://en.wikipedia.org/wiki/Apostrophe#Miscellaneous_uses_in_other_languages>

Stan Brown

unread,
Apr 14, 2018, 10:24:57 AM4/14/18
to
On 13 Apr 2018 18:16:36 GMT, Stefan Ram wrote:
> English rules require an apostrophe in front of »[sic]«,
>

Not any English rule that I've ever heard of.

John W Kennedy

unread,
Apr 14, 2018, 10:00:08 PM4/14/18
to
On 4/13/18 8:05 PM, Thomas 'PointedEars' Lahn wrote:
> Jukka K. Korpela wrote:
>
>> Stefan Ram wrote:
>>> What English requires:
>>>
>>> 0027 39 APOSTROPHE, APOSTROPHE-QUOTE
>>
>> You are mistaken. This is the “vertical apostrophe”, introduced in
>> Remington typewriters, later adopted into the ASCII character set. It
>> was never part of the writing system of English, or any other human
>> languages, […]
>
> As usual, hasty generalization:
>
> <https://en.wikipedia.org/wiki/Apostrophe#As_a_glottal_stop>
>
> <https://en.wikipedia.org/wiki/Apostrophe#As_a_mark_of_palatalization_or_non-palatalization>
>
> <https://en.wikipedia.org/wiki/Apostrophe#To_separate_morphemes>
>
> <https://en.wikipedia.org/wiki/Apostrophe#Miscellaneous_uses_in_other_languages>

The top of that article defines an apostrophe as being either ' or ’.
That makes it completely useless for discussing the distinction between
the two.

Thomas 'PointedEars' Lahn

unread,
Apr 14, 2018, 11:01:34 PM4/14/18
to
John W Kennedy wrote:

> The top of that article defines an apostrophe as being either ' or ’.

Irrelevant. Follow the references that I posted.

> That makes it completely useless for discussing the distinction between
> the two.

No, the straight apostrophe is particularly used *properly* when it does
_not_ serve to indicate an omission and a genitive construction.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>

John W Kennedy

unread,
Apr 15, 2018, 12:18:57 PM4/15/18
to
On 4/14/18 11:01 PM, Thomas 'PointedEars' Lahn wrote:
> John W Kennedy wrote:
>
>> The top of that article defines an apostrophe as being either ' or ’.
>
> Irrelevant. Follow the references that I posted.
>
>> That makes it completely useless for discussing the distinction between
>> the two.
>
> No, the straight apostrophe is particularly used *properly* when it does
> _not_ serve to indicate an omission and a genitive construction.

Given that the article uses typewriter punctuation, it cannot be used as
evidence on the point at all. Find a real book that uses real typography
on the subject.

Thomas 'PointedEars' Lahn

unread,
Apr 15, 2018, 12:57:29 PM4/15/18
to
John W Kennedy wrote:

> On 4/14/18 11:01 PM, Thomas 'PointedEars' Lahn wrote:
>> John W Kennedy wrote:
>>> The top of that article defines an apostrophe as being either ' or ’.
>> Irrelevant. Follow the references that I posted.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> That makes it completely useless for discussing the distinction between
>>> the two.
>>
>> No, the straight apostrophe is particularly used *properly* when it does
>> _not_ serve to indicate an omission and a genitive construction.
>
> Given that the article uses typewriter punctuation, it cannot be used as
> evidence on the point at all. Find a real book that uses real typography
> on the subject.

Given that you cannot read, you are not in a position to recommend one.


PointedEars
--
When all you know is jQuery, every problem looks $(olvable).

Jukka K. Korpela

unread,
Apr 15, 2018, 4:17:33 PM4/15/18
to
HTML scrawler wrote:

> On Fri, 6 Apr 2018 08:08:25 -0700, "David E. Ross"
> <nob...@nowhere.invalid> wrote:
[...]
>> You are trying to use numeric character references. PLEASE DO NOT, even
>> if you use Unicode code point numbers (which you are not).
>>
>> Instead, use named character references (formerlly known as entity
>> references). ....
>
> Hold on, are you saying that we shouldn't be using UNICODE in our HTML
> documents?

Or that we should not use PROSE in our texts? Please ignore the
nonsense, as well as the trolling by Lahn. There is ignorance, and there
is worse; ignore both if you can.

> I routinely use &#38; to put ampersands into text, e.g. "I went to the
> A&#38;P store and bought some tea." Are you saying that that shouldn't
> be done?

That’s a completely different issue. The reference &#38; denotes the
Ascii apostrophe, which should never be used in English prose. It does
not matter how you enter it. It’s just a wrong character. And there was
never any reason to use the reference &#38; for it in text content (only
in attribute values). So if your content has an expression in a markup
language or a programming language, use their apostrophe (') as such
without obscuring it. But don’t use it in prose, still less in poetry.

> I also tend to put in &#160; instead of &nbsp; for a non-breaking
> space.

They are completely equivalent. Whether you use one of them instead of
the no-break space character itself depends on the authoring
environment. If your authoring tools can show no-break space differently
from a normal space (say, using a colored rectangle), then why would you
obscure things by not using the character itself?

> There are other UNICODE uses as well, including &#8212; which
> puts a long hyphen in text.

It’s not a long hyphen. It’s the em dash “—” used as punctuation
character in some styles in English (mainly in the US) and in some other
languages. Here, too, things depend on the authoring environment. If it
can handle “—” well, there is no reason to obscure it, any more than we
obscure the letter “A” in data by representing it as &#x41;.

--
Yucca, http://jkorpela.fi

Thomas 'PointedEars' Lahn

unread,
Apr 15, 2018, 5:50:38 PM4/15/18
to
Jukka K. Korpela wrote:

> […] Please ignore the nonsense, as well as the trolling by Lahn. […]

Typical. The record shows: When *you* have no reasonable arguments,
*you* throw insults.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

Gloops

unread,
Jul 12, 2018, 6:41:45 AM7/12/18
to
Le 06/04/2018 à 21:42, David E. Ross a écrit :
> On 4/6/2018 8:52 AM, Jukka K. Korpela wrote [in part]:
>> I previously wrote [also in part]:
>>
>>> See
>>> <https://www.w3.org/TR/2017/REC-html51-20171003/syntax.html#named-character-references>.
>>
>> Why are you referring to HTML 5.1 edition 8, when HTML 5.2 is a W3C
>> recommendation?
>
> I could not get the HTML 5.2 named character references to display
> correctly. This might have been caused by some of my browser settings.
> However, I had other tasks to do and could not take time to resolve that
> problem. Thus, I chose the page that I could display.
>
>

Well, I had a look, they put us some U+00nn in all directions, just to
say us the format to insert a character is the same as with the previous
version.

For a quotation mark, character 22 in hexadecimal :

&#x22;

You can also give it in decimal :

&#34;


--
Besoin d'un autre système, pas d'un autre gouvernement.
0 new messages