True replacement for <xmp>

[Mr. Man-wai Chang]

How could I #include a plain text file into a HTML page without the need
to escape special characters?

They said <xmp> is deprecated, and we should use <pre>. But I would need
to escape special characters in the text file.

<textarea> might be a simple solution, but I would need to count the
number of lines in the text file so that the whole file could be
displayed without vertical scroll-bar.

And I don't wanna use any Javacript, CSS nor PHP scripting.

--
@~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!!
/ v \ Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[Jukka K. Korpela]

Mr. Man-wai Chang wrote:

> How could I #include a plain text file into a HTML page without the need
> to escape special characters?

Using <xmp>.

> They said <xmp> is deprecated

Actually, they now say (in HTML5) that it is obsolete, though this is
mostly just a change of a term. But why do you care? Are you afraid of
things like “Although it may still work in some browsers, its use is
discouraged since it could be removed at any time”?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/xmp

It would be odd to remove the feature, as it would break (some) existing
pages and would not produce any benefits. But if you are worried, escape
“&” as “&amp;” and “<” as “&lt;”. These are the only escapes you need
(and even these are not necessary in all contexts, but it is easier to
do them all).

--
Yucca, http://jkorpela.fi

[Thomas 'PointedEars' Lahn]

Jukka K. Korpela wrote:

> Mr. Man-wai Chang wrote:
>> How could I #include a plain text file into a HTML page without the need
>> to escape special characters?
>
> Using <xmp>.

Not at all. The easiest and safest way that comes to mind is an “iframe”
element, with a hyperlink to the text resource as alternative content.

>> They said <xmp> is deprecated
>
> Actually, they now say (in HTML5) that it is obsolete,

And that means in this case:

,-<https://www.w3.org/TR/2014/REC-html5-20141028/obsolete.html#obsolete>
,-<https://www.w3.org/TR/html/obsolete.html#non-conforming-features>
|
| 11.2. Non-conforming features
|
| Elements in the following list are entirely obsolete, and must not be used
| by authors:
|
| […]
|
| xmp
| Use “pre” and “code” instead, and escape "<" and "&" characters as$
| "&lt;" and "&amp;" respectively.

> though this is mostly just a change of a term.

No, the choice of words *matters* because words carry *meaning*.

With regard to HTML5, there are *two* *distinct* types of obsolescence:
“Obsolete but conforming features” and “Non-conforming features”.
The “xmp” element is *evidently* of the *latter* type.

The MDN article that you have been referring to says *exactly* at this time,
at the very top:

| This feature is obsolete. Although it may still work in some browsers, its
| use is discouraged since it could be removed at any time. Try to avoid
| using it.

It *may* *still* work in *some* browsers, but *if* that is the case (which
is unknown to the authors) this state is _not_ going to last.

> It would be odd to remove the feature, as it would break (some) existing

> pages […]

Name one beside one of your own.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Mr. Man-wai Chang]

On 3/12/2017 11:07 PM, Jukka K. Korpela wrote:
>
>> They said <xmp> is deprecated
>
> Actually, they now say (in HTML5) that it is obsolete, though this is
> mostly just a change of a term. But why do you care? Are you afraid of
> things like “Although it may still work in some browsers, its use is
> discouraged since it could be removed at any time”?
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/xmp

Is it safe to say *now* that all browsers would continue to respect
"<xmp>"? :)

<pre> and <code> are definitely not a heir to <xmp>, given the need to
escape special characters. Um... I don't know why they deprecate or
obsolete <xmp> though, other than making things hard for simple tasks.

[Jukka K. Korpela]

Mr. Man-wai Chang wrote:

> Is it safe to say *now* that all browsers would continue to respect
> "<xmp>"? :)

Nobody can guarantee that – or continued support to any element for that
matter.

> <pre> and <code> are definitely not a heir to <xmp>, given the need to
> escape special characters.

Yes, they are different beasts.

(And so is <iframe>, which was mentioned by the resident troll. It is
not for inclusion but for embedding. Whether that would meet your needs
is a different issue; I was asking to what was actually asked.)

> Um... I don't know why they deprecate or
> obsolete <xmp> though, other than making things hard for simple tasks.

Theoretical considerations: <xmp> requires a special parsing mode. But
now that browsers have it, why would they remove it? (And it is rather
simple if anyone intends to write a new browser. But nobody can give any
guarantee.)

--
Yucca, http://jkorpela.fi

[Thomas 'PointedEars' Lahn]

Jukka K. Korpela wrote:

> Mr. Man-wai Chang wrote:
>> Is it safe to say *now* that all browsers would continue to respect
>> "<xmp>"? :)
>
> Nobody can guarantee that – or continued support to any element for that
> matter.

Why are you lying?

>> Um... I don't know why they deprecate or
>> obsolete <xmp> though, other than making things hard for simple tasks.
>
> Theoretical considerations: <xmp> requires a special parsing mode. But
> now that browsers have it, why would they remove it? (And it is rather
> simple if anyone intends to write a new browser. But nobody can give any
> guarantee.)

You are trying to shift the burden of proof.
Name one browser that supports it.


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)

[Mr. Man-wai Chang]

On 12/4/2017 8:44 AM, Thomas 'PointedEars' Lahn wrote:
>> Theoretical considerations: <xmp> requires a special parsing mode. But
>> now that browsers have it, why would they remove it? (And it is rather
>> simple if anyone intends to write a new browser. But nobody can give any
>> guarantee.)
>
> You are trying to shift the burden of proof.
> Name one browser that supports it.

Allow me, Master. Firefox supports "<xmp>"!

[Thomas 'PointedEars' Lahn]

Mr. Man-wai Chang wrote:

> On 12/4/2017 8:44 AM, Thomas 'PointedEars' Lahn wrote:
>>> Theoretical considerations: <xmp> requires a special parsing mode. But
>>> now that browsers have it, why would they remove it? (And it is rather
>>> simple if anyone intends to write a new browser. But nobody can give any
>>> guarantee.)
>>
>> You are trying to shift the burden of proof.
>> Name one browser that supports it.
>
> Allow me, Master. Firefox supports "<xmp>"!

Firefox ESR 52.5.0 (64-bit) on Debian/Devuan GNU+Linux does. So does
Chromium 57.0.2987.98 (64-bit). It would be mildly interesting to find out
which of the major browsers still support it.

However, the former statement needs to be quantified: The two mentioned
browsers support it *now*. Features that are listed in the latest HTML
specification (currently, HTML 5.1 2nd Edition) as “non conforming” have
a smaller probability to be supported in the future than any other HTML
feature. Keep in mind that the W3C HTML 5.x Specifications are already
snapshots of the WHATWG HTML Specification (“Living Standard”), which is
driven by invididuals representing the major browser vendors. That is,
the involved browser vendors have already decided (a long time ago) that
they are not intending to support those features in the future. For
confirmation in such a case, read <http://whatwg.org/html>.

Use non-conforming features at your own risk (and you forfeit document
validity).

IMHO, the risk is not worth it for this use-case. Keep in mind: By HTML
rules, if the “xmp” element is not supported, the start and end tag will be
ignored and that content in your case will be rendered as garbage. All of
that only because you were too lazy for search-and-replace or learning
(server-side) scripting?

BTW:

The “Mr.” is usually not contained in the From header field value. However,
it is common practice for Asian names that the family name is written in
all-uppercase so as to allow the natural name order without confusion.


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

[Jukka K. Korpela]

Mr. Man-wai Chang wrote:

> Firefox supports "<xmp>"!

Not a big surprise; all relevant browsers do. There’s a short summary at
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/xmp

It was a rather close call not to include <xmp> in HTML5, see discussion at
https://www.w3.org/Bugs/Public/show_bug.cgi?id=12235

--
Yucca, http://jkorpela.fi

[Thomas 'PointedEars' Lahn]

Jukka K. Korpela wrote:

> Mr. Man-wai Chang wrote:
>> Firefox supports "<xmp>"!
>
> Not a big surprise; all relevant browsers do. There’s a short summary at
> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/xmp

JFTR:

,-<https://caniuse.com/#search=xmp>
|
| […]
| These elements/tags are obsolete and should not be used. Because of this,
| browser support is not tracked.
| […]

> It was a rather close call not to include <xmp> in HTML5, see discussion
> at https://www.w3.org/Bugs/Public/show_bug.cgi?id=12235

As the more careful than wishful reader will find out, it has been referred
there as “tough call” by only *one* person instead, Ian 'Hixie' Hickson. By
that he referred to Henri Sivonen (somewhat miraculously) writing “Seems
like a nice convenience people for experts who use text editors and
confusion otherwise. Not sure what the right call here is.” [sic] (Sivonen
eventually agreed that it is a good idea not to standardize this element,
after spurious arguments have been brought forth in appealing the decision.
See the currently final entry.)

That was when Hickson was still the (sole) editor of the W3C HTML5
Specification, *before* he initiated the WHATWG because of reported deadlock
in the W3C HTML WG (or, as other sources have it, because he did not get his
will), and *before* (the W3C basically gave up their separate efforts and)
HTML5 was based on WHATWG HTML snapshot. It is only of historical interest
today, 6 years later, now that HTML has moved on.


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

[Mr. Man-wai Chang]

On 12/6/2017 1:14 AM, Thomas 'PointedEars' Lahn wrote:
>
> Firefox ESR 52.5.0 (64-bit) on Debian/Devuan GNU+Linux does. So does
> Chromium 57.0.2987.98 (64-bit). It would be mildly interesting to find out
> which of the major browsers still support it.
>
> However, the former statement needs to be quantified: The two mentioned
> browsers support it *now*. Features that are listed in the latest HTML

> ...

> IMHO, the risk is not worth it for this use-case. Keep in mind: By HTML
> rules, if the “xmp” element is not supported, the start and end tag will be
> ignored and that content in your case will be rendered as garbage. All of
> that only because you were too lazy for search-and-replace or learning
> (server-side) scripting?

Aren't all browsers supposed to support all versions of HTML, including
the very first edition? There are things that don't need the latest and
greatest.... ;)

> BTW:
>
> The “Mr.” is usually not contained in the From header field value. However,
> it is common practice for Asian names that the family name is written in
> all-uppercase so as to allow the natural name order without confusion.

To declare my gender, Master. Could avoid some confusion and accusation! :)

[Jukka K. Korpela]

Mr. Man-wai Chang wrote:

> Aren't all browsers supposed to support all versions of HTML, including
> the very first edition?

No. In fact, there was never any browser that supported even the first
defined HTML version ever, HTML 2.0 (!). As usual, the resident troll
will protest against this, failing to provide any testable claim about a
browser that did, as usual. Of course, this relates mostly to HTML
features that were formally part of the specification, never
implemented, and not used by authors (though some people may have tried).

A statement like “is supposed to” is rather vague. HTML specifications
contain requirements and recommendations, but even the requirements are
relative: requiring something means simply that an implementation does
not conform to the specification if it does not satisfy the requirement.
But implementors do what they want. They might produce something that
conforms to a requirement, and they might say this. In fact, they can
even claim conformance without having true conformance. Lying is not
even criminal, except in special cases.

And I don’t think I have often seen conformance claims by a browser
vendor mentioning older HTML versions. They typically claim conformance
to one of the recently new versions, often with reservations. This might
have the underlying assumption that each version is a superset of all
previous versions, which is an oversimplification.

--
Yucca, http://jkorpela.fi

[Thomas 'PointedEars' Lahn]

Mr. Man-wai Chang wrote:

> On 12/6/2017 1:14 AM, Thomas 'PointedEars' Lahn wrote:

>> Firefox ESR 52.5.0 (64-bit) on Debian/Devuan GNU+Linux does [support the
>> “xmp” element]. So does Chromium 57.0.2987.98 (64-bit). It would be

>> mildly interesting to find out which of the major browsers still support
>> it.
>>
>> However, the former statement needs to be quantified: The two mentioned
>> browsers support it *now*. Features that are listed in the latest HTML
>> ...
>> IMHO, the risk is not worth it for this use-case. Keep in mind: By HTML
>> rules, if the “xmp” element is not supported, the start and end tag will
>> be ignored and that content in your case will be rendered as garbage.
>> All of that only because you were too lazy for search-and-replace or
>> learning (server-side) scripting?
>
> Aren't all browsers supposed to support all versions of HTML, including
> the very first edition?

Of course they are not. You should learn the history of HTML before you
make such assumptions.


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>

[Mr. Man-wai Chang]

On 12/7/2017 11:17 AM, Thomas 'PointedEars' Lahn wrote:
>
> Of course they are not. You should learn the history of HTML before you
> make such assumptions.
>

Which part covers the conversion from "xmp" to "pre"? I meant the new
standard scared (!) every "xmp" user to escape special characters by
moving to "pre" ... wasting time and resources in the process. :)

[Mr. Man-wai Chang]

On 12/7/2017 3:13 AM, Jukka K. Korpela wrote:
> Mr. Man-wai Chang wrote:
>
>> Aren't all browsers supposed to support all versions of HTML,
>> including the very first edition?
>
> No. In fact, there was never any browser that supported even the first
> defined HTML version ever, HTML 2.0 (!). As usual, the resident troll
> will protest against this, failing to provide any testable claim about a
> browser that did, as usual. Of course, this relates mostly to HTML
> features that were formally part of the specification, never
> implemented, and not used by authors (though some people may have tried).

It's logical to assume that ALL browsers are to support ALL versions of
HTML standards. It's sad that it's not the case because of business
interests.

Now that we have faster CPUs and GPUs, using just "table" tags to layout
a site isn't that bad an idea.

[Thomas 'PointedEars' Lahn]

Mr. Man-wai Chang wrote:

> On 12/7/2017 11:17 AM, Thomas 'PointedEars' Lahn wrote:
>> Of course they are not. You should learn the history of HTML before you
>> make such assumptions.
>
> Which part covers the conversion from "xmp" to "pre"?

Virtually *every* text about HTML, including the (HTML5) Specification(s)
itself.

> I meant the new standard scared (!) every "xmp" user to escape special
> characters by moving to "pre" ... wasting time and resources in the
> process. :)

These are a misconception and a fallacy as argued out of (your) *ignorance*
and perhaps overconfidence in understanding induced by Jukka K. Korpelas
misleading statements.

The XMP element was first specified in HTML 2.0.¹ It was already marked as
“obsolete” in HTML 3.2 of 1997-01-14, almost 21 years ago²; however, HTML
3.2 was never implemented as such (see “browser wars”).

It was no longer specified in HTML 4.01 of 1999-12-24, almost 18 years ago³,
and markup validators pointed that out⁴, so escaping special characters in
HTML was the recommendation back then already, and numerous questions in
forums in Netnews and on the Web, in tutorials, and features to that effect
in programming languages (e.g. PHP⁵, which is one of my fields of
expertise), are evidence of it. There was/is also XHTML 1.x where you
could/can, if appropriately parsed (by declaring the proper MIME media type
and encountering a supporting parser), have such content in a CDATA section
verbatim.⁶

HTML versions before 3.2 have been obsoleted by RFC 2854 in 2000-06, more
than 17 years ago.⁷

By contrast to previous versions, and due to its closer relation to browser
vendors (as I detailed before), HTML5 (2014-10-28 and later, up to more than
3 years ago⁸) is no longer based on SGML and aims to document the status of
user agent implementations at the time of publication instead. This
includes obsolete features like the “xmp” element for which support is
implemented but whose use is recommended against because they are only
historical remnants – only there because browser vendors had no pressing
need to remove the corresponding UA code *yet*. That is, the next UA code
clean-up may be the final blow to the feature on the basis of “nobody cares
about this anymore” and “there are better ways to do this”.

So, contrary to your outlandish claims, *this has been a long time coming*.

Next time *you* will do your own homework, and carry the burden of proof for
your claims, as it should be.

BTW, in belated response to your earlier statement: This is a gender-neutral
community, at least it should be. So there is no need to “declare [your]
gender”.


HTH

PointedEars
___________
¹ <https://www.w3.org/MarkUp/html-spec/L2index.html#XMP>
² <https://www.w3.org/TR/REC-html32#body>
³ <https://www.w3.org/TR/1999/REC-html401-19991224/index/elements.html>
⁴ <http://validator.w3.org/>
⁵ <http://php.net/htmlspecialchars>
⁶ <https://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.8>
⁷ <https://tools.ietf.org/html/rfc2854>
⁸ <https://www.w3.org/TR/2014/REC-html5-20141028/>

[Jukka K. Korpela]

Mr. Man-wai Chang wrote:

> It's logical to assume that ALL browsers are to support ALL versions of
> HTML standards.

No, because browsers predate the “standards” and because the “standards”
contradict each other (mostly in minor details, but still). It would be
a different matter if it had all started with a standard, which had then
been upgraded in a manner that maintains compatibility with previous
versions. But the true story of HTML is very different.

> Now that we have faster CPUs and GPUs, using just "table" tags to layout
> a site isn't that bad an idea.

I don’t get the point here, but it probably isn’t relevant. Efficiency
hasn’t really been a key concern when some people have opposed the use
of tables for layout.

P.S. I hope you have learned to ignore Lahn’s trolling. The history and
present is complicated enough, and Lahn’s lectures just add to the
confusion.

--
Yucca, http://jkorpela.fi

[Barry Margolin]

In article <p0daau$604$1...@toylet.eternal-september.org>,

"Mr. Man-wai Chang" <toylet...@gmail.com> wrote:

> On 12/7/2017 3:13 AM, Jukka K. Korpela wrote:
> > Mr. Man-wai Chang wrote:
> >
> >> Aren't all browsers supposed to support all versions of HTML,
> >> including the very first edition?
> >
> > No. In fact, there was never any browser that supported even the first
> > defined HTML version ever, HTML 2.0 (!). As usual, the resident troll
> > will protest against this, failing to provide any testable claim about a
> > browser that did, as usual. Of course, this relates mostly to HTML
> > features that were formally part of the specification, never
> > implemented, and not used by authors (though some people may have tried).
>
> It's logical to assume that ALL browsers are to support ALL versions of
> HTML standards. It's sad that it's not the case because of business
> interests.

It's reasonable to expect that old browsers will continue to support old
HTML features, so long as there haven't been incompatible changes that
prevent it. They're not likely to remove code unnecessarily.

But if a new browser is developed, would you really expect them to go
through all the old standards, as well as all the de facto standards
that were never codified officially, so they could provide compatibility
with 1990's-era Netscape?

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Thomas 'PointedEars' Lahn]

Jukka K. Korpela wrote:

> Mr. Man-wai Chang wrote:
>> Aren't all browsers supposed to support all versions of HTML, including
>> the very first edition?
>
> No.

True. Versions of HTML prior to 3.2 are considered “obsolete” by the
IETF/IESG, and “historic” by the W3C, since 2000-06 CE, as I have explained
in my other follow-up.

> In fact, there was never any browser that supported even the first

> defined HTML version ever, HTML 2.0 (!). […]

That the XMP element was first specified in HTML 2.0, and that it is *still*
supported in the *descendants* of the browsers that existed at the time is
*evidence* that at least *some* features of HTML 2.0 were supported by at
least *one* browser.

The same is not true for HTML 3.2, though.


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>

[Mr. Man-wai Chang]

On 8/12/2017 10:29 PM, Thomas 'PointedEars' Lahn wrote:
> By contrast to previous versions, and due to its closer relation to browser
> vendors (as I detailed before), HTML5 (2014-10-28 and later, up to more than
> 3 years ago⁸) is no longer based on SGML and aims to document the status of
> user agent implementations at the time of publication instead. This
> includes obsolete features like the “xmp” element for which support is
> implemented but whose use is recommended against because they are only
> historical remnants – only there because browser vendors had no pressing
> need to remove the corresponding UA code *yet*. That is, the next UA code
> clean-up may be the final blow to the feature on the basis of “nobody cares
> about this anymore” and “there are better ways to do this”.

"xmp" is doing a fine job. I don't see any reason to drop it.

Anyway, the "guns" that love to change things are not controlled by me. :)

[Mr. Man-wai Chang]

On 9/12/2017 12:53 AM, Barry Margolin wrote:
> It's reasonable to expect that old browsers will continue to support old
> HTML features, so long as there haven't been incompatible changes that
> prevent it. They're not likely to remove code unnecessarily.
>
> But if a new browser is developed, would you really expect them to go
> through all the old standards, as well as all the de facto standards
> that were never codified officially, so they could provide compatibility
> with 1990's-era Netscape?

"xmp" is just a simple tag or element that does a job.

[Thomas 'PointedEars' Lahn]

Mr. Man-wai Chang wrote:

> On 8/12/2017 10:29 PM, Thomas 'PointedEars' Lahn wrote:
>> By contrast to previous versions, and due to its closer relation to
>> browser vendors (as I detailed before), HTML5 (2014-10-28 and later, up
>> to more than 3 years ago⁸) is no longer based on SGML and aims to
>> document the status of
>> user agent implementations at the time of publication instead. This
>> includes obsolete features like the “xmp” element for which support is
>> implemented but whose use is recommended against because they are only
>> historical remnants – only there because browser vendors had no pressing
>> need to remove the corresponding UA code *yet*. That is, the next UA
>> code clean-up may be the final blow to the feature on the basis of
>> “nobody cares about this anymore” and “there are better ways to do this”.
>
> "xmp" is doing a fine job. I don't see any reason to drop it.

AISB, because the element is non-conforming since HTML 4.01, HTML > 3.2
documents that use it are not Valid. If you use it in such a document, you
will have to deal with (W3C) Validator error messages because of this that
not only are unnecessary, but potentially obscure other, more serious errors
in your code.

For another thing, the concept of the “xmp” element is flawed as it cannot
fully be used to document itself:

<xmp>
<xmp>You do not need to escape special characters here.</xmp>
</xmp>

is garbage markup, and the first “</xmp>” will not be displayed, because it
is considered to end the content that does not need to be escaped, leaving
the second “</xmp>” without a corresponding “<xmp>” before. That is, any
sequence of “</xmp>” in the element content needs to be escaped.

So, what’s the point? Instead of making sure that such a sequence does not
occur unescaped, why not use conforming, Valid markup in the first place and
escape all special characters without any reasonable risk of failure?

See also the comments to the corresponding bug report that led to its not
being standardized in HTML5.

[Mr. Man-wai Chang]

On 9/12/2017 11:01 PM, Thomas 'PointedEars' Lahn wrote:
> AISB, because the element is non-conforming since HTML 4.01, HTML > 3.2
> documents that use it are not Valid. If you use it in such a document, you
> will have to deal with (W3C) Validator error messages because of this that
> not only are unnecessary, but potentially obscure other, more serious errors
> in your code.

> ....

Who cares about HTML standards? Why standards drop something useful and
simple? Don't speak for the standards and browsers business. Speak as a
user who just need some very simple sometimes naive HTML markup.

[Thomas 'PointedEars' Lahn]

Mr. Man-wai Chang wrote:

> On 9/12/2017 11:01 PM, Thomas 'PointedEars' Lahn wrote:
>> AISB, because the element is non-conforming since HTML 4.01, HTML > 3.2
>> documents that use it are not Valid. If you use it in such a document,
>> you will have to deal with (W3C) Validator error messages because of this
>> that not only are unnecessary, but potentially obscure other, more
>> serious errors in your code.
> > ....
>
> Who cares about HTML standards?

You should if you want your documents to work tomorrow as well, unchecked
and unchanged. As I indicated, nowadays the browser vendors essentially
write the HTML(5) standards.

> Why standards drop something useful and simple?

Because it is too simple, therefore error-prone.

> Don't speak for the standards and browsers business. Speak as a
> user who just need some very simple sometimes naive HTML markup.

It is not up to you to tell me how to speak.

I have told you my recommendation and I think I have made my point. I am
not going to argue with you about it (especially as your argument is, at
best, very weak).

“When others do a foolish thing, you should tell them it is a foolish
thing. They can still continue to do it, but at least the truth is
where it needs to be.”

—Dukhat, Babylon 5 – 4x09 “Atonement”


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Barry Margolin]

In article <p0h6hc$v3r$5...@toylet.eternal-september.org>,

"Mr. Man-wai Chang" <toylet...@gmail.com> wrote:

> On 9/12/2017 11:01 PM, Thomas 'PointedEars' Lahn wrote:
> > AISB, because the element is non-conforming since HTML 4.01, HTML > 3.2
> > documents that use it are not Valid. If you use it in such a document, you
> > will have to deal with (W3C) Validator error messages because of this that
> > not only are unnecessary, but potentially obscure other, more serious errors
> > in your code.
> > ....
>
> Who cares about HTML standards? Why standards drop something useful and
> simple? Don't speak for the standards and browsers business. Speak as a
> user who just need some very simple sometimes naive HTML markup.

In general, things are only dropped from standards when they're
considered a really bad idea, and there are better ways to accomplish
it. The reason to remove it is so that future developers won't be
burdened with having to implement redundant features -- the obsolete way
and the preferred way.

Of course, it would be a bad idea to do this with a feature that was
popular. There will be lots of web pages that use the feature, and you
don't want them to stop working in a browser that just implements the
new standard.

[Mr. Man-wai Chang]

On 10/12/2017 10:09 AM, Barry Margolin wrote:
>
> In general, things are only dropped from standards when they're
> considered a really bad idea, and there are better ways to accomplish
> it. The reason to remove it is so that future developers won't be
> burdened with having to implement redundant features -- the obsolete way
> and the preferred way.
>
> Of course, it would be a bad idea to do this with a feature that was
> popular. There will be lots of web pages that use the feature, and you
> don't want them to stop working in a browser that just implements the
> new standard.

Well, we have no idea about the kind of damage money and guns could
create! :)

[Mr. Man-wai Chang]

On 10/12/2017 6:58 AM, Thomas 'PointedEars' Lahn wrote:
>
> It is not up to you to tell me how to speak.
>
> I have told you my recommendation and I think I have made my point. I am
> not going to argue with you about it (especially as your argument is, at
> best, very weak).
>
> “When others do a foolish thing, you should tell them it is a foolish
> thing. They can still continue to do it, but at least the truth is
> where it needs to be.”
>
> —Dukhat, Babylon 5 – 4x09 “Atonement”

There are always people who don't need fancy webpages. Thank you for
your attention, Your Honor.