HTML isn't a series of commands executable by anything

Well, it's a muddy issue but the long and short of it is that you're the one that's going to end up dirty if you take that stance. Given what we do, we tend to have very specific ideas of what words like "executable" should mean. Broader definitions exist, though, than the technical ones we are most comfortable with. For instance, you can think of an <h1> tag as a "command" to a "browsing device" to start rendering text as a level one header. The end tag, </h1> can similarly be thought of as a command to stop rendering text as a level one header. And so forth.

Our predisposition to think of things like "commands" as being part of "programming languages" and to think of "programming languages" as usually being Turing complete is, it turns out, more a matter of jargon than anything. Try debating with an intelligent but non-technical person about whether HTML is a programming language or not. It's not an easy debate to win.

Dennis Ritchie didn't have anything to do with this patent, by the way.

-sauoq
"My two cents aren't worth a dime.";

For instance, you can think of an <h1> tag as a "command" to a "browsing device" to start rendering text as a level one header. The end tag, </h1> can similarly be thought of as a command to stop rendering text as a level one header. And so forth.

There's only one problem with that - HTML tags are requests, not commands. And, no, I'm not thinking in terms of Turing completeness. I'm thinking in terms of the difference between a command and a markup tag. A command (which may or may not be part of a Turing-complete language) is not a request or an option. It's a requirement. If the recipient of an "executable command" does not perform the action in a well-defined manner (that is not implementation-dependent), then the recipient is broken.

HTML, on the other hand, is completely optional and implementation-dependent. Yes, we have certain expectations of how a standard browser on a standard computer is going to behave and we would definitely consider IE or FF buggy if it displayed h3 tags as bigger than h1 tags. However, go watch a blind guy on the Net for a few hours and watch how his browser handles tags. Half are ignored and the other half are rendered in speech emphasis, not upon the screen. And, what about mobile devices?

The gist is that HTML is a format for specifying how to optionally decorate plaintext. It has nothing to do with commands, executables, or anything else of the sort.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

I want to make it abundantly clear here that I'm really playing devil's advocate in arguing with you. From a technical standpoint, I agree with you completely because the distinctions you are making are useful from that standpoint. Those distinctions, however, aren't so necessary or even so easy to make outside of a technical discussion.

There's only one problem with that - HTML tags are requests, not commands.

There's no such thing as "requesting" that a computer does something because a computer doesn't have free will. Its behavior is well-defined and predictable.^† How a browser implements the specification isn't the issue; those choices have already been made by the browser developers.

Also, the issue isn't whether all computers do exactly the same thing with the input. But, that should be obvious. Give C source to two different compilers and you probably aren't going to get the same output (even on the same platform.)

The distinction between data and code is blurry. Which, for instance, is a perl script? It isn't machine code, but it does contain strings of symbols that, when fed to a perl interpreter, determine the behavior of that interpreter. Perl itself is written in C. C isn't machine code either, but it does contain strings of symbols that, when fed to a compiler, determine the behavior of that compiler. And HTML isn't machine code, but it does contains strings of symbols that, when fed to a browser, determine the behavior of that browser.

By the way, I had this argument with a college professor once (and he, as I, played devil's advocate and argued the side I am now.) It was a little more specific in that the question was "is HTML a programming language?" At one point I decided to appeal to higher authority and I wrote email to Guy Steele, Bjorne Stroustrup, and one or two other famous names. The only reply I got was from Stroustrup. His reply was that, yes, a case can be made for calling HTML a programming language. I've been looking for that email, but I guess I no longer have a copy. In any case, his response shocked me into a more flexible point of view. While I do agree with you from a technical standpoint, I understand completely why your argument won't hold up in court.

† Predictable to someone and in theory (ignoring implementation errors.)

-sauoq
"My two cents aren't worth a dime.";

HTML tags are requests, not commands.

Actually, they are neither. HTML tags delimit HTML elements, for instance in:

    <H1>This is an example</H1>
[download]

the tags <H1> and </H1> delimit a first level header element, whose content is This is an example (which has type PCDATA).

HTML, on the other hand, is completely optional and implementation-dependent

There's little implementation dependent in HTML. You have of course your choice of DTD, but that's about it.

Yes, we have certain expectations of how a standard browser on a standard computer is going to behave and we would definitely consider IE or FF buggy if it displayed h3 tags as bigger than h1 tags.

I'd consider a browser buggy if it showed me the tags at all. It should show me the data - not the tags. It should use the tags to know what kind of data the document contains, and use that to decide how it should be rendered, but it should not show the tags.

However, go watch a blind guy on the Net for a few hours and watch how his browser handles tags. Half are ignored and the other half are rendered in speech emphasis, not upon the screen.

I've some close friends who are blind. They all use IE to browse the web. They do use a screen reader to know what IE displays though.

And, what about mobile devices?

Yes, what about them? I'd consider any HTML processing device, whether it's mobile or not, broken if it "ignored tags". Just like I'd consider a (Perl) compiler broken if it ignored double quotes.

The gist is that HTML is a format for specifying how to optionally decorate plaintext.

Eh, no. HTML is a format to specify what is plaintext or not. Or what's a header, a list or a link. Neither tags, nor elements are commands or request. They are just that, structural parts of a document. They just exist, they do not act.
Perl --((8:>*

A known way of improving the quality of images derived from text-based systems is to add formatting commands or instructions to data strings. These instructions control operations of a receiver, such that the signals are processed in such a receiver, to ensure that the transmitted signals are processed in such a way as to generate a high quality video image that is capable of being displayed at a requesting client's terminal.

In addition to improving the quality of displayed images, such an approach also facilitates an improvement in system compatibility. Thus, the incoming control signals are executed by a receiver's terminal in a way that is compatible with the receiving system. Thus, the output signals may be considered as executable instructions that cause operations to be performed upon the viewable data in accordance with the local constraints.

So it appears to be claiming patent over anything that generates html on the fly.