knowing what and when to feature test

[Thomas 'PointedEars' Lahn]

You seem to have created a nice little RPG world there full of ad hoc
rules.

It is important that Recommendation is written with a capital `R' here
because it is not just any recommendation but a proper name that has a
certain meaning.

Is downloadable content available?

Check the W3C Process Document, and referring specifications.

<http://www.wssn.net/WSSN/listings/links_international.html>

Idiot. The W3C is even an ISOC member. To deny that they are making Web
standards is as if you denied that the IESG made the Internet Standard
[RFC (3)977] that allows you to post that nonsense in the first place.

So you read blogs and stuff. Good for you.

Contrary to others, I know what I am talking about when it comes to
organizations like the W3C.

I suppose you mean I should use the results of random Google searches to
educate myself; while I appreciate this insight in your process of
knowledge acquisition, I’d rather stick to consulting relevant
resources.

Your "relevant resources" are insufficient to make the proper assessment.


PointedEars

 

[Garrett Smith]

[snip]

Contrary to others, I know what I am talking about when it comes to
organizations like the W3C.

A few days ago, you were quite certain that HTML 4 defined clear
expectations for nonstandard HTML. In response to what I wrote:-

| Code that uses malformed, nonconformant HTML is expecting nonstandard
| behavior.

- you replied:-

| Nonsense. The API Specification does not say how implementations
| should behave there. While there is indication that it would be
| unwise to rely on implicit type conversion, that is certainly not
| based on an expectation of nonstandard behavior.

The reason the conversation is at this leg is due to your incorrect
argumentation in response to my correct statements. You made several
other wrong statements in your message.

 

[Garrett Smith]

[snip]
| Code that uses malformed, nonconformant HTML is expecting nonstandard
| behavior.

- you replied:-

| Nonsense. The API Specification does not say how implementations
| should behave there. While there is indication that it would be
| unwise to rely on implicit type conversion, that is certainly not
| based on an expectation of nonstandard behavior.

Ah, sorry, that was another incorrect argument of yours, posted in that
same message you wrote. The pertinent incorrect argument of yours was:

| Nonsense. The HTML standard makes recommendations as to how parsers
| are supposed to handle invalid markup. But again, it is not wise to
| rely on that as those are only recommendations.

That statement is a wrong statement and harmful advice to anyone trying
to learn html and javascript.

 

[Thomas 'PointedEars' Lahn]

Eric Bednarz wrote:

[snip]

Contrary to others, I know what I am talking about when it comes to
organizations like the W3C.

A few days ago, you were quite certain that HTML 4 defined clear
expectations for nonstandard HTML.

First of all, that previous discussion has nothing to do with my statement
of fact that the W3C makes Web standards, and with my knowledge about
organizations about the W3C contrary to certain others people's.

Second, what you describe is _not_ what I said. Instead, I said that HTML
4 made certain recommendations as to what to do with invalid markup, so
that (quote Garrett) "Code that uses malformed, nonconformant HTML is
expecting nonstandard behavior" is obviously a fallacy; but, since those
recommendations are only that (with non-capital `r') it would be unwise to
rely on them.

Third, the section of my reply that you have quoted now,

| Nonsense. The API Specification does not say how implementations
| should behave there. While there is indication that it would be
| unwise to rely on implicit type conversion, that is certainly not
| based on an expectation of nonstandard behavior.

has nothing to do with the W3C or HTML 4. Instead, it has to do with the
W3C DOM API Specification, and is very far from being wrong in any sense.
With a technical specification, only a not fullfilled requirement not to do
a certain thing under any circumstances (an explicit or implied MUST NOT)
can be considered a violation of that specification, and, if that
specification is considered a standard, a non-standard thing.

So much for your disdain of straw man arguments.


PointedEars

 

[Thomas 'PointedEars' Lahn]

| Nonsense. The HTML standard makes recommendations as to how parsers
| are supposed to handle invalid markup. But again, it is not wise to
| rely on that as those are only recommendations.

That statement is a wrong statement and harmful advice to anyone trying
to learn html and javascript.

No, it *evidently* is not.


PointedEars

 

[John G Harris]

No, it *evidently* is not.

The key parts of HTML 4.01 Appendix B1 are :

"However, to facilitate experimentation and interoperability between
implementations of various versions of HTML, we recommend the following
behavior:

.... user agent encounters an element it does not recognize
.... user agent encounters an attribute it does not recognize
.... user agent encounters an attribute value it doesn't recognize
.... it encounters an undeclared entity
....
Since user agents may vary in how they handle error conditions, authors
and users must not rely on specific error recovery behavior."

It doesn't mention the kind of mess that is found in so many web pages.
Thus Garrett is right.

John

 

[Lasse Reichstein Nielsen]

No, it *evidently* is not.

Since you are asserting the positive, it wouldn't cost you a lot to, say,
post a link to the part of the HTML standard that you are referring to.
Not for whoever you are arguing with (since he has an interest, he can
check it himself), but for everybody else who are reading this from the
sidelines.

/L 'http://www.w3.org/TR/html4/appendix/notes.html#notes-invalid-docs'

 

[Garrett Smith]

No, it *evidently* is not.

No, your statement is incomplete. As I stated: Code that uses
malformed, nonconformant HTML is expecting nonstandard behavior. That is
correct advice.

 

[Garrett Smith]

Eric Bednarz wrote:
Eric Bednarz wrote: [snip]

Contrary to others, I know what I am talking about when it comes to
organizations like the W3C.

A few days ago, you were quite certain that HTML 4 defined clear
expectations for nonstandard HTML.

First of all, that previous discussion has nothing to do with my statement
of fact that the W3C makes Web standards, and with my knowledge about
organizations about the W3C contrary to certain others people's.

It's a long chain of your pointless thread-destroying pedantry. The only
point of that seemed to be to prove that I was incorrect.

Second, what you describe is _not_ what I said. Instead, I said that HTML
4 made certain recommendations as to what to do with invalid markup, so
that (quote Garrett) "Code that uses malformed, nonconformant HTML is
expecting nonstandard behavior" is obviously a fallacy;

No, what I wrote is a true statement and correct advice.

You are free to make your own false expectations from invalid markup. If
you such false expectations here, they will probably be corrected.

 

[Thomas 'PointedEars' Lahn]

No, your statement is incomplete. As I stated: Code that uses
malformed, nonconformant HTML is expecting nonstandard behavior. That is
correct advice.

It is gibberish to begin with. "Code that uses ... is expecting ..."?
Perhaps if you managed to post a coherent statement, a more fruitful
discussion would follow.


PointedEars

 

[Thomas 'PointedEars' Lahn]

It's a long chain of your pointless thread-destroying pedantry.

What you call "pointless thread-destroying pedantry" were necessary
corrections because you twisted my words to fit your argument, and a number
of false assumptions were made by you and other people in the process.

The only point of that seemed to be to prove that I was incorrect.

You were.

No, what I wrote is a true statement and correct advice.

It is not. It is gibberish, and if interpreted in your favor, a wrong
statement and no advice at all.

You are free to make your own false expectations from invalid markup.

Straw man.

The expections are not false, your statement is. And you are continually
ignoring (perhaps on purpose) that I am _not_ making a recommendation to
use invalid markup (which would appear to be your insinuation). I am only
saying (again) that the Specification makes provisions for invalid markup.
That this is true can be confirmed by simply reading the referred section
where there is the wording "we (the authors) recommend ..."

If you such false expectations here, they will probably be corrected.

If you learned to read and write properly, perhaps we could have some
progress here.


PointedEars