New home page focus
Timothy Rue
Objective is to bring focus, though my former homepage and all links as
still accessible thru a non-java link.
http://www.mindspring.com/~timrue/
---
*3 S.E.A.S - Virtual Interaction Configuration (VIC) - VISION OF VISIONS!*
*~ ~ ~ Advancing How we Perceive and Use the Tool of Computers!*
Timothy Rue What's *DONE* in all we do? *AI PK OI IP OP SF IQ ID KE*
Email @ mailto:tim...@mindspring.com >INPUT->(Processing)->OUTPUT>v
Web @ http://www.mindspring.com/~timrue/ ^<--------<----9----<--------<
Rich
Some type of skil saw blade?
"Timothy Rue" <thre...@earthlink.net> wrote in message
news:589.734T2361T3...@earthlink.net...
bulk_trap
>
> Objective is to bring focus, though my former homepage and all links as
> still accessible thru a non-java link.
>
> http://www.mindspring.com/~timrue/
Timothy Rue
Timothy Rue
That site is crap.
I'm can't edit urls addresses (addresses external to my site) in order to
remove errors this site generates from the valid url address in my page.
Just goes to show two things.
this w3c org web page ain't worth a shit and others can use it as an
arguement to tell someone who created a web page that they are stupid.
If the page doesn't work in your browser, then get a browser that works!
I used a web page creation tool (not a wysiwyg) that is very popular.
Popular enough to know that the w3c page does not support what is more
likely standard then apparently what w3c wants to says is.
From my position, all I see is proof that the industry is really f*cked
up that it does shit that in essences try to tell the users they are
stupid.
if w3c can't tell the difference between a vaild url and html code....
Good thing browser makers and web page creation tool makers are a bit more
intelligent.
Huh?!!!
P.S. I am a bit pissed because I recall someone here using this shit as an
arguement to try and put me down. With such pathetic losers around it's no
wonder the Amiga has the history it does.
Maybe someone needs to move the MS stinky up people out of here?
Kirk Strauser
At 2001-12-04T02:01:33Z, "Timothy Rue" <thre...@earthlink.net> writes:
> I'm can't edit urls addresses (addresses external to my site) in order to
> remove errors this site generates from the valid url address in my page.
>
> Just goes to show two things.
One thing, actually - you had a broken tag somewhere in your page, and it is
throwing of the rest of the page. Sort of like forgetting a double-quote in
a program.
> this w3c org web page ain't worth a shit and others can use it as an
> arguement to tell someone who created a web page that they are stupid.
Do you know who the w3c is?
> If the page doesn't work in your browser, then get a browser that works!
If every web designer had that philosophy, NOONE would be reading pages on
their Amiga.
> I used a web page creation tool (not a wysiwyg) that is very popular.
> Popular enough to know that the w3c page does not support what is more
> likely standard then apparently what w3c wants to says is.
I can honestly say that I've *never* seen a page creation tool that
generated acceptable HTML. Our graphics guy uses Dreamweaver, and although
it's supposed to be one of the best design programs, its output is
absolutely horrid.
> if w3c can't tell the difference between a vaild url and html code....
>
> Good thing browser makers and web page creation tool makers are a bit more
> intelligent.
If it weren't for the w3c, you might not *have* a browser or creation tool.
> P.S. I am a bit pissed because I recall someone here using this shit as an
> arguement to try and put me down. With such pathetic losers around it's no
> wonder the Amiga has the history it does.
I don't think that bulk_trap was putting you down - I think he gave you a
pointer to a valuable tool.
--
Kirk Strauser
Tim
>>> Uses Javascript (will be making a decafe version in a day or so)
>>>
>>> Objective is to bring focus, though my former homepage and all
>>> links as still accessible thru a non-java link.
>>>
>>> http://www.mindspring.com/~timrue/
On 03-Dec-01 04:33:47 bulk_trap <bulk...@yahoo.com> wrote:
>> See http://validator.w3.org/
On Tue, 04 Dec 2001 02:01:33 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> That site is crap.
>
> I'm can't edit urls addresses (addresses external to my site)
> in order to remove errors this site generates from the valid
> url address in my page.
I'd hate to imagine how anybody who can't even get their English
syntax right, can code *anything* properly.
> Just goes to show two things.
>
> this w3c org web page ain't worth a shit and others can use it as an
> arguement to tell someone who created a web page that they are stupid.
Actually, it's quite good. Your coding is the problem. There's an
old saying about computer programming that just sprung to mind, and in
your case it's doubly ironic:
"Rubbish in, rubbish out."
Leaving the gibberish message content of your web site aside, for now,
and the coding of any particular web site, I'll concentrate on the
technical issue you've brought up, it's applicable to more than just
your site:
Debugging tools show up the bugs in coding. If it found bugs, then
you've got bugs.
Sometimes they're serious, other times they're not. Certain types of
coding practises still produce usable code, but they're not strictly
"correct," and may be picked up by debugging tools.
e.g. Currently, list elements /should/ be within <li> and </li> tags,
but it's not mandatory. It merely helps better interpretation of the
coding, where there may be a bit of vagueness in understanding what
was meant (particularly if other tags have also been omitted).
A debugging tool may overlook that, or it may point out that a missing
closing </li> tag is an error on the page. And it may also impinge on
the debugging tool to continue validating the page.
Most programs have difficultly in continuing to run, after
encountering one error in the data. Web browsers are moderately good
at doing so, but a program that's specifically supposed to find errors
in code, really shouldn't be expected to ignore errors, trivial or
not.
Unlike debugging some computer programs (checking the contents, when
the program is not running), where an error on one line may only show
up as that line being in error; an HTML page has to be debugged on the
whole. Not all commands, are a single line, but encompass a whole
block. The whole block has to be correct. If you miss some tags out
that may be optional, they may show up as errors in more than one
place (a miscount in opening versus closing tags, for instance).
e.g. Showing two examples of a section of a page:
--- 1 ---
<table>
<tr>
<td>one</td>
<td>two</td>
</tr>
<tr>
<td>three</td>
<td>four></td>
</tr>
</table>
--- and 2 ---
<table>
<tr>
<td>one
<td>two
</tr>
<td>three
<td>four
</table>
Are functionally the same, and would work in most browsers, but
checking the validity of the second one would (probably) result in a
string of error messages about missing closing </td> and </tr> tags.
Such error message are correct.
Further to that, there's a non-error (if you would), but an ambiguity
about how this table would render, that the author hasn't taken into
account: It may not render the same on everyone's browser, because
there's been no declaration about whether the table should have a
border ruled around it, or lines ruled between the cells.
The default action, for most browsers, would be to draw them in, but
it's by no means guaranteed that all browsers will do that. They
don't really have to.
That's another example of typical assumption made by HTML authors;
that it works for me, it should work the same elsewhere, sorry, but
that's not true. Leading to this statement:
> If the page doesn't work in your browser, then get a browser that
> works!
That's a very dumb argument. I could write HTML coding that's
completely correct, but it won't work (as it was designed to) in your
Amiga browser, and there's no Amiga browser that could do it, either.
It also wouldn't work (as designed to) in a variety of PC browsers.
Perhaps you'd also like to argue that you can do something better than
HTML, or any other current web language, and insist that everyone view
your web site with your reader client. Because that's the type of
attitude you're conveying.
> I used a web page creation tool (not a wysiwyg) that is very popular.
> Popular enough to know that the w3c page does not support what is
> more likely standard then apparently what w3c wants to says is.
"Standards," or more to the point ratified defined standards, are
what's ratified by a standards body. Not what everyone else thinks
that they can get away with. That's how Microsoft works, and we all
know how bad that attitude is.
Just as it's stupid to use a web browser (an inherently buggy piece of
software), to debug HTML coding with, particularly as it's a rendering
agent that's quite happy at accepting broken coding, without any
protest; it's equally as stupid to suggest that web code generators
can be held up as any example of how to do things.
Most HTML generators make the most diabolical code. Ranging from just
the plain bloated coding, full of all sorts of unnecessary statements;
to completely incorrect code structure.
For instance, the HTML generator that you've used has done the classic
lazy coding thing of not putting paragraphs of text inside <p> </p>
paragraph tags, but has just done a double <br> line break at the end
of each paragraph. It's not the same thing. Line breaks don't
delineate the ends of a section of text, with the same meaning. And
double tags don't have to be rendered as double tags (browsers can,
quite legitimately, render them as just a single <br> tag).
> From my position, all I see is proof that the industry is really
> f*cked up that it does shit that in essences try to tell the users
> they are stupid.
>
> if w3c can't tell the difference between a vaild url and html code....
Coding, whether to make executables, scripts, or web pages really does
require the author to code properly. i.e. Write code in the way that
code is supposed to be written, rather than in the manner that just
happens to work on what you tested it on.
There's a world of difference between the two, and this is a prime
villain:
> Good thing browser makers and web page creation tool makers are a
> bit more intelligent.
They're not. Web browser authors frequently do dire jobs of coding
their browser. Web page authors then start relying on those bugs, to
render a page in the manner that they want, then their pages render
differently for the next release of the browser.
An snippet of bad coding that will be ignored by some browsers:
<font size="+2">larger writing<p>more writing</p>still more</font>
Some browsers will incorrectly show all of that text as a larger font.
Others will only (correctly) show the first two words in a larger
font. Some may show the first four words in a larger font (closing
off the still open <font> tag at the next closing tag, rather than the
next opening tag.
Firstly, what's wrong: The font sizing tags are supposed to be
applied to a certain section of text, so to speak. Starting a new
paragraph is another section. The start of a new section closes off
all still open tags. It's a new "block" of something, it needs to be
formatted from within
How should it be interpreted? There's three sections to that little
code snippet; "larger writing," "more writing," and "still more." The
start of the *next* section, which is the opening <p> tag, will close
the end of the preceding opened tag, the <font size="+2"> tag.
Putting an end to the large font after the first two words. The
section between the two <p> </p> tags should be seen as just default
text. Then the next section after that (still more), has an erroneous
</font> tag, where there's no opening <font> tag.
This is how that should be interpreted (rendered):
<font size="+2>larger writing</font>
<p>more writing</p>
still more</font>
And the errors reported for the original source code:
A missing </font> tag after "larger writing".
A missing <font> tag before "still more".
The original coding was wrong, the interpretation was ambiguous (it's
only really obvious to the author that he wanted everything in large
writing, and we can only guess that that's what he wanted), the HTML
validator should pick up those errors, and browsers could render it in
any of the ways that I suggested.
So who's right? The browser authors who're rendering something that
they shouldn't (and which version of the incorrect rendering)? The
HTML author who says everything should be able to work out what he
wanted, despite him not coding correctly? Or the HTML validator that
pointed out that there's errors in the code, and they ought to be
fixed up?
The answer is, the HTML validator.
> P.S. I am a bit pissed because I recall someone here using this shit
> as an arguement to try and put me down. With such pathetic losers
> around it's no wonder the Amiga has the history it does.
Well, if you go publicly parading your dirty linen in public, you
really ought to expect to hear a comment. Particularly when you go on
about your coding ability, in a computing news group, to other coders,
and then give them such a terrific example to criticise.
> Maybe someone needs to move the MS stinky up people out of here?
Funny you should mention that, because you're arguing that you should
be able to code HTML, and have it work, in the same manner that
Microsoft like to badly program their applications.
You may notice that I've not used examples of coding from your web
site, beyond the mention of the <br><br> versus <p></p> business,
because I'm not about to get into debating the whole thing. Sufficed
to say, that I've used examples which show typical errors in HTML
generators and renderers, that you'd hold up as being more correct
than the "standard" HTML coding, and the validator that checks for
that (standard coding).
If you have to debate this issue, have the common sense to not go on
about your site's coding, and your right to code it as you please. I,
and many others, couldn't give a monkeys about that. But trying to
argue that the validator isn't valid, and lax software is a better
example of how to do things, just doesn't hold.
The people who argue that a debugging tool finds faults, when it does,
but that it's wrong to do so, are the people that can't code.
Timothy Rue
>"Timothy Rue" <thre...@earthlink.net> wrote
>>>> Uses Javascript (will be making a decafe version in a day or so)
>>>>
>>>> Objective is to bring focus, though my former homepage and all
>>>> links as still accessible thru a non-java link.
>>>>
>>>> http://www.mindspring.com/~timrue/
>On 03-Dec-01 04:33:47 bulk_trap <bulk...@yahoo.com> wrote:
>
>>> See http://validator.w3.org/
>On Tue, 04 Dec 2001 02:01:33 GMT,
>"Timothy Rue" <thre...@earthlink.net> wrote:
>
>> That site is crap.
>>
>> I'm can't edit urls addresses (addresses external to my site)
>> in order to remove errors this site generates from the valid
>> url address in my page.
>I'd hate to imagine how anybody who can't even get their English
>syntax right, can code *anything* properly.
Gee I wonder if a spelling checker is as smart as you are at identifying
such an error? I bet the spell checker in the web page creator I used
wouldn't have, but at least it can tell the difference between html and
other.
But for sure that validator isn't smart enough to tell the difference
between what is html and what is not. And since it can't do that then how
is anyone to trust it to find errors in html. You know, when it doesn't
even know whether something is html or not?
Pretty much makes irrealavant anything else you may have said.
And considering that I'm using a web page creator, a popular one, seems to
me that if it's important enough of an error, it should be identified in
the creation process by the creation tool.
Just think, if the w3c got everyone (tool and browser maker) to adhear to
their defined standards (regardless of the inherent ignorance of the
validator) then all html would be correct and made that way in the
creation feedback stage (where it belongs). And stupid threads like this
one wouldn't be taking up bandwidth (which also goes to show that
bandwidth use isn't really a problem, pollute it all you want.)
Guess that is why the validator is a web based product instead of a
downloadable plugin, that you can plugin to your browser or whatever other
web page creation tool you use in order to deal with errors in the typical
offline creation cycle.
Imagine that! A java language (being how common and cross platform it is
or can be - guess it could be python or perl or rebol....) based plugin or
program or library, etc -that removes any need for the browser or tool
maker to duplicate error detection coding efforts and done by the html
standards committee. And as such greatly help to establish the use of the
official standards in real life.
Oh but that would be to intelligent, requiring the committee to actually
do something more than just decide on and say what the standards are, but
to actually make it happen, by writting it down in more than just human to
human languages!
Did I mention that the validator can't tell the difference between html
and other?
If a dumb as dirt user like me knows that computers are for automating
what is repeatable, then what does that make the w3c? Dumber than dirt?
Sorry, but my living standards don't go below dirt. And neither should
yours, though they do appear to here. Are you in the dead, degeneration
and decay stage?
I don't know, but it sure feels like it from my above ground pov, when
someone trys to dump such dirt and garbage on me. But then whos dump site
am I in? Here it seems to be the html dump site run by a commitee.
No wonder it smells so bad, all the F*ckin time!
Tim
>>>>> Uses Javascript (will be making a decafe version in a day or so)
>>>>>
>>>>> Objective is to bring focus, though my former homepage and all
>>>>> links as still accessible thru a non-java link.
>>>>>
>>>>> http://www.mindspring.com/~timrue/
On 03-Dec-01 04:33:47 bulk_trap <bulk...@yahoo.com> wrote:
>>>> See http://validator.w3.org/
On Tue, 04 Dec 2001 02:01:33 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
>>> That site is crap.
>>>
>>> I'm can't edit urls addresses (addresses external to my site)
>>> in order to remove errors this site generates from the valid
>>> url address in my page.
On 04-Dec-01 06:38:34 Tim <T...@localhost.invalid> wrote:
>> I'd hate to imagine how anybody who can't even get their English
>> syntax right, can code *anything* properly.
On Tue, 04 Dec 2001 13:17:39 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> Gee I wonder if a spelling checker is as smart as you are at identifying
> such an error? I bet the spell checker in the web page creator I used
> wouldn't have, but at least it can tell the difference between html and
> other.
Normally, I couldn't be stuffed in getting involved in this sort of
thing, but in your case I'll make an exception. Gee but I wish I
could see you now, you must be throwing a real paddy, and probably
jumping up and stamping your foot. You really are such a childish
pratt.
*OBVIOUSLY*, you *cannot* tell the difference between proper and
improper HTML, nor your HTML editor, else your code wouldn't be so
full of bugs. Whether or not you used an HTML authoring program. If
you had any knowledge about how bad it was, you'd fix it.
The only person who can't see that, is you.
Assuming that you haven't overridden what your HTML creator has
generated, and done the errors yourself, there's a variety of stupid
bugs that are the fault of your HTML creator that's supposedly more
/trustworthy/ than the HTML validator. Here's just a few of them:
The character set hasn't been defined, meaning that any renderer has
to guess whether you've use Latin-1 or something else.
You've used parameters to commands that aren't valid:
* Color in a HR tag, when that's not allowed for the version
of HTML that you're using.
* Align="" in an IMG line, where there should be something in
those quotes.
* Border="" in an IMG line, where there should be something in
those quotes.
Incorrect syntax in a table:
<th> </th> table cells that aren't within any <tr> </tr> pairs.
Guess what? None of those faults are a fault in the validator.
They're a fault in your coding, however they got in there.
> But for sure that validator isn't smart enough to tell the difference
> between what is html and what is not. And since it can't do that then how
> is anyone to trust it to find errors in html. You know, when it doesn't
> even know whether something is html or not?
All software can have errors, there is no perfect software. It found
bugs on your page, real bugs. I've only bothered with quickly looking
at small sections of your code, but I've seen several that're
glaringly obvious.
But feed any debugging tool with crap, and you're going to confuse it.
Weed out the errors, and keep on doing so until it validates.
By the way, I don't supposed you noticed that it's an HTML validator,
not a JavaScript validator? Maybe it's not going to correctly parse
JavaScript. Use something else to check on your JavaScript links that
you've got in the middle of your hrefs.
> Pretty much makes irrealavant anything else you may have said.
Absolutely not.
The only one making a fool of themselves is you. And you do it so
well. We don't have to give you any help. You adhere to that oh so
common rule of; when making a fool of yourself, attract the maximum
amount of attention to yourself, while you do it.
> And considering that I'm using a web page creator, a popular one, seems to
> me that if it's important enough of an error, it should be identified in
> the creation process by the creation tool.
Has absolutely nothing to do with. There's a plethora of popular
ones, expensive ones, ones with coding teams behind them, and many of
them are just plain crap.
> Just think, if the w3c got everyone (tool and browser maker) to adhear to
> their defined standards (regardless of the inherent ignorance of the
> validator) then all html would be correct and made that way in the
> creation feedback stage (where it belongs). And stupid threads like this
> one wouldn't be taking up bandwidth (which also goes to show that
> bandwidth use isn't really a problem, pollute it all you want.)
The one "polluting" the bandwidth is you, with your continual childish
tantrums.
You've missed the point entirely, that the W3C makes the specs
publicly available to everybody. It defines what they do, how to use
them, gives technical examples, etc. They've done everything "they"
can do, and need to. The people who aren't playing ball are the
people who write bad HTML generators and renderers, and who author
crap coding.
Your HTML is crap, but do you blame yourself? No. It's someone
else's fault. (As usual.)
If you hadn't been such a hotheaded twit about it, and a long
reputation for being like that, you'd probably have got advice on how
to fix what's wrong with your page. But I seriously doubt you'll ever
get any sympathy from anyone.
Once again, that's all entirely your own fault.
> Guess that is why the validator is a web based product instead of a
> downloadable plugin, that you can plugin to your browser or whatever other
> web page creation tool you use in order to deal with errors in the typical
> offline creation cycle.
There are validators that you can install on your own computer. Just
go and find one. The concept behind a web page based one is many
fold:
* People can check pages without having to have more software on their
computer.
* People can have their pages checked by a service that actually knows
the proper code, rather than some other source which reckons they know
how things ought to be, when they don't.
* The validator can be kept current, and any bugs in it repaired, and
everybody who uses it benefits immediately. And they don't have to
keep updating some software on their own computer.
Even your own personal validator, if you have one, can make use of the
W3C web site. It can look up the DTD for the HTML version that you're
validating.
If you write HTML well, it'd start off with a line something like:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
That address points to the DTD that describes what supposed to be
valid for the version of HTML that's on your page.
It's that DTD that the validator is going to use against your page (or
whatever alternative one is applicable, if you're using a different
version of HTML).
> Imagine that! A java language (being how common and cross platform it is
> or can be - guess it could be python or perl or rebol....) based plugin or
> program or library, etc -that removes any need for the browser or tool
> maker to duplicate error detection coding efforts and done by the html
> standards committee. And as such greatly help to establish the use of the
> official standards in real life.
Aren't you a coder, why don't you write one yourself? All the data is
there for you to know how it should work. HTML isn't some secret.
There's nothing to stop your chosen HTML generator from really
checking HTML, properly, as you write it. Though they can pick up on
syntactical errors in your writing, they can't stop stupid uses of
HTML. Some brains is still required of the author.
> Oh but that would be to intelligent, requiring the committee to actually
> do something more than just decide on and say what the standards are, but
> to actually make it happen, by writting it down in more than just human to
> human languages!
Have you actually bothered to read the HTML specs? Are you yet
another of those coders, for whatever language, who doesn't believe
they need to know the language to use it?
> Did I mention that the validator can't tell the difference between html
> and other?
And other *what*? It's an HTML validator, it validates HTML. Don't
expect it to validate something else.
[snip more childish outbursts]
Timothy Rue
>At 2001-12-04T02:01:33Z, "Timothy Rue" <thre...@earthlink.net> writes:
>> I'm can't edit urls addresses (addresses external to my site) in order to
>> remove errors this site generates from the valid url address in my page.
>>
>> Just goes to show two things.
>One thing, actually - you had a broken tag somewhere in your page, and it is
>throwing of the rest of the page. Sort of like forgetting a double-quote in
>a program.
Oh, so you want me to guess from multipule choice list the validator
gives me? Where the answer might not even be on the list!!!
Let me put it this way:
Sa lon de web lookers and pitur makr spak ebonics, who da hale cars wat
da upnosed proper inglsh grammer politics say bout how speak?
you say it don't look right, something is wrong. How come I don't see
something looking wrong? maybe u in wrong browser gang. Me use biggest
gang browser, ware mo see ok, understand.
Seems to me the html commitee is telling the wrong party what the
standards are. They need to tell the computer and in a language the
machine can translate and understand and do, make happen. It's not my
problem the machine reflects their inability to adhear to and impliment
the standards they create. maybe da ought to tell computer and sho proof
of the whole concept, from defining a standard to making it reality. Like
validate what they are and do.
dat way, de cumpuetr tell me I mak wrng, not u. u not 365ź/24/7!
besides, u play guessing game. me no have 365/25/8!
eye kneed ° 2 show < $.02 dan dat!
Timothy Rue
.
.
.
>The character set hasn't been defined, meaning that any renderer has
>to guess whether you've use Latin-1 or something else.
don't tell me, tell the computer to stop speaking ebonics, then maybe
I'll learn there is actually something there to learn.
>You've used parameters to commands that aren't valid:
>* Color in a HR tag, when that's not allowed for the version
> of HTML that you're using.
I'm going to remove that first line <!DOCTYPE....
I was guessing at it based on the choices given on the validator site,
what it suppose to recognize.
The reason why I'm going to remove that first line is because of the
reason you inherently mentioned, unintentionally I'm sure.
It's not a matter of what HTML version I'm using so much as it is
apparently and obviously what html version is your browsers, the receiver
of my page, using. As such it really doesn't make any sense to say what
version the page uses (cept as a comment maybe) but rather up to the
html version of the browser to make best use of applying it's html version
to the page.
you see, as simple as it is, there is this Horizontal Rule tool in the
creation tool I use. It is of no concern to me I can use it, filling in
the options I want and then see consistant results in the creation tool
preview as well as the browser (most used - wanna guess?).
I guess what this means is that the validator page can't handle the more
currently being used version of HTML.
doesn't most used suggest "standard"?
Either the html committee can impliment the standards in a manner that can
avoid the need of duplication by browser makers and web page tool creators
by allowing them to make use of the "already done once" implimentation, or
they are nothing more than a paper pushing party that apparently the
majority don't listen to very well.
I'm not a browser maker, a web page tool maker or on the html commitee.
The only reason why I'm dealing with a f*cking guessing game is because
these three parties don't have their shit together.
So you can go tell them to tell the machine, where the machine can then
tell me when I have done something wrong. As it should be.
Otherwise they are only showing me their incompetance at understanding the
problem and complete failure to listen to the end users.
I don't need no stinking guessing game!
The wind needs to turn in the direction of those responsible for the
stink. Or have they simply gotten use to the smell?
Gary Beeton
> If the page doesn't work in your browser, then get a browser that works!
>
> I used a web page creation tool (not a wysiwyg) that is very popular.
> Popular enough to know that the w3c page does not support what is more
> likely standard then apparently what w3c wants to says is.
Taking a page out of MicroSoft's stylebook now are we? :)
--
Gary Beeton
Timothy Rue
I don't know. Is that another thing I'm suppoosed to do? or is that just
another, butt popular, version of ebonics? According to the html committee
mind you.
Ibrowse (pre javascript) shows the page ok, cept for not handeling the
javascript stuff and fully handeling the HR options.
IE (the biggest gang) shows it the way I created it.
CoffeeCup of course shows it the way I created it, sorta an inherent
thing, as the html standards should be.
So I thought I'd go off the wall and try Voyager (QNX). Ok so it's a unix
filename case sensitive system, had to edit two graphic filenames to get
them to work. But the javascript seem to work halfway - it'd open a new
window but not bring it forward (as the javascript main use here was
intended to do). And of course the HR options didn't work even as well as
they did on the older amiga browser.
but other than changing a few filenames, all three browsers show the page
pretty much the way it is intended to look. In fact even the amiga ibrowse
(pre javascript version) can be instructed to open another window.
Maybe I can eliminate the java script all together.
Anyway, it has occured to me that maybe there was genuine intent to help.
Timmy, you are missing a tag somewhere in your code and the color option
doesn't exist in version 4.01 of html of <HR>...<rolls eyes and says sorry
if any of you said something I didn't read, it's a do I have the time to
sort thru and work around the lack of logic in the html standard(s)
implimetation, or not, sorta thing mind you. Oh wait, don't look like any
of the browsers I tried even notice such a "problem".... if it looks good,
smells good and taste good, it must be good???.)>
But the real point is whether or not the message got thru, not whether the
messanger (browser) fell in the mud or not (which again is not my fault or
problem to try and guess at fixing). Granted Ibrowse (pre javascript
version) can't access the javascript url hostages. Not to worry, special
forces in logic are at work on it. The user is just gonna have to bring
the new window forward for themselves. You know, a manual thing in the
environment of automation, or should I say half-halfass automation
environment..
<shrug>
Well at least I proved I, a dumb as dirt user, can in fact automate
something, when the tools to do so are there and work. Its just to damn
f*cking bad the tools aren't there or don't work, otherwise we'd all get
a hell of a lot more done, instead of f*cking around with babling bull
shit. Or maybe the working tools aren't there because someone like IBM
have patented it and then told everone no, unless you pay them protection
money.
Anyone know why amiga.org sometimes (and when it does, it's consistant)
crash my system (Amiga/ibrowse)? I mean if I'm gonna be dumped on,
expected to fix others peoples stuff, then do it all at once so we can
get the f*ck past the shit and put responsibility where it belongs, in the
hands of those who created and control the html media in the first place.
otherwise it ain't nothing more than consumer entrapment abuse.
Which reminds me, by law, I'm supposed to get some verification that my
comment to the DOJ regarding the MS vs. DOJ case, was received and read.
I'm sure there is a long list of responses to respond to....I'm waiting
but wonder if that task can be complete before the deadline...
Considering this case is suppose to be one of protecting the "consumer",
maybe they should have given more time for the consumer to speak up, AND
be heard? Or would that give MS an infinate amount of time to continue to
do what they do?
According to the constitution, if the legal system completely fails in
it's duty, citizens can resort to guns to protect their property. It's
why there is a right to bear arms! The ultimate check and balance! Maybe
someone should remind Bill Gates of this and include the word "pie" as the
DOJ must also knows it, unless they have completely failed in their duty.
Maybe Bill sould move out of the country for his own safety?
So if I'm using MS stylebook pages, how come it's not on the lable? And
even more important, given it must be inherent, otherwise I must outright
know I'm using it, why isn't it open standard as all physical phenomenon,
natural law and abstraction is?
otherwise it ain't nothing more than consumer entrapment abuse.
John Burns
>.
>.
>.
>>The character set hasn't been defined, meaning that any renderer has
>>to guess whether you've use Latin-1 or something else.
>don't tell me, tell the computer to stop speaking ebonics, then maybe
>I'll learn there is actually something there to learn.
>>You've used parameters to commands that aren't valid:
>>* Color in a HR tag, when that's not allowed for the version
>> of HTML that you're using.
>I'm going to remove that first line <!DOCTYPE....
LOL
That won't stop your HTML from being bad, just the validator from checking it.
Oh well they do say ignorance is bliss so I'm sure your be/are very happy.
>I was guessing at it based on the choices given on the validator site,
>what it suppose to recognize.
>The reason why I'm going to remove that first line is because of the
>reason you inherently mentioned, unintentionally I'm sure.
>It's not a matter of what HTML version I'm using so much as it is
>apparently and obviously what html version is your browsers, the receiver
>of my page, using. As such it really doesn't make any sense to say what
>version the page uses (cept as a comment maybe) but rather up to the
>html version of the browser to make best use of applying it's html version
>to the page.
Your lack of knowledge again fails to astound.
>you see, as simple as it is, there is this Horizontal Rule tool in the
>creation tool I use. It is of no concern to me I can use it, filling in
>the options I want and then see consistant results in the creation tool
>preview as well as the browser (most used - wanna guess?).
As simple as it is it's obviously too complicated for you.
>I guess what this means is that the validator page can't handle the more
>currently being used version of HTML.
No it means your HTML is faulty in accordance with the version _you_ specified
that _you_ used. Tim when I was designing and testing my HTML code I used an
HTML validator to check what I had hand written, (whilst referring to the
applicable w3c standard). Yes, it threw up errors, did I ignore these and blame
the validator? No, I re-read the relevent part of the standard doc and realising
_my_ error made the appropriate corrections until the validator found the document
to be correct.
>doesn't most used suggest "standard"?
No, but given your grasp of English I can see why you make this assumption.
>Either the html committee can impliment the standards in a manner that can
>avoid the need of duplication by browser makers and web page tool creators
>by allowing them to make use of the "already done once" implimentation, or
>they are nothing more than a paper pushing party that apparently the
>majority don't listen to very well.
You really don't have a clue do you?
>I'm not a browser maker, a web page tool maker or on the html commitee.
>The only reason why I'm dealing with a f*cking guessing game is because
>these three parties don't have their shit together.
Yeah, yeah. Poor old Timmy is the hapless victim yet again. Why is always
you, eh?
>So you can go tell them to tell the machine, where the machine can then
>tell me when I have done something wrong. As it should be.
The validator was telling you this but from your comments you are choosing to
ignore what it says. So who's fault is that?
>Otherwise they are only showing me their incompetance at understanding the
>problem and complete failure to listen to the end users.
You are the end user of the validation program and it is you who is failing to
listen to what it is telling you.
>I don't need no stinking guessing game!
So instead you come here and bore us with yet another of your rants in which you
have already decided you are correct irrespective of the evidence.
>The wind needs to turn in the direction of those responsible for the
>stink. Or have they simply gotten use to the smell?
Only smell is the bulls*it coming from you
Actually I downloaded your index and basic pages and ran them through both a spell
checkers and HTML validators. The spell checkers all picked up multiple errors on
both pages which have nothing to do with HTML. The validators found dozens of errors
mostly due to undefined tags etc. These checks took me approx 15 mins to run and
you could have saved yourself so much time and reputation had you bothered to do
the same.
However, as usual you do/say something and then cannot accept that you can be wrong
no matter how many people point out (politely) that you are in error.
John Burns
>>At 2001-12-04T02:01:33Z, "Timothy Rue" <thre...@earthlink.net> writes:
>>> I'm can't edit urls addresses (addresses external to my site) in order to
>>> remove errors this site generates from the valid url address in my page.
>>>
>>> Just goes to show two things.
>>One thing, actually - you had a broken tag somewhere in your page, and it is
>>throwing of the rest of the page. Sort of like forgetting a double-quote in
>>a program.
>Oh, so you want me to guess from multipule choice list the validator
>gives me? Where the answer might not even be on the list!!!
Actually the sensible way is to work through the errors in order, is that
hard to grasp as a concept. Doh, the -error- will be on the list. The
answer will be in the relevant w3c standard.
>Let me put it this way:
>Sa lon de web lookers and pitur makr spak ebonics, who da hale cars wat
>da upnosed proper inglsh grammer politics say bout how speak?
>you say it don't look right, something is wrong. How come I don't see
>something looking wrong? maybe u in wrong browser gang. Me use biggest
>gang browser, ware mo see ok, understand.
Yes I understand the moronic analogy you are trying to make, erroneous as it
is.
Using colloquialisms/slang words may be an acceptable mode of communication
within that community but is of no use when you wish to communicate with the
wider world. This is the reason why we have dictionaries (proper words) and
grammatical rules (how to apply those words correctly). The w3c standards
are similar in that they tell you the correct way to use the specifics of
HTML. If _you_ use bad HTML then you only have yourself to blame if not
every browser/program accepts it.
>Seems to me the html commitee is telling the wrong party what the
>standards are. They need to tell the computer and in a language the
>machine can translate and understand and do, make happen. It's not my
>problem the machine reflects their inability to adhear to and impliment
>the standards they create. maybe da ought to tell computer and sho proof
>of the whole concept, from defining a standard to making it reality. Like
>validate what they are and do.
From someone who claims to be a programmer this has got to be the silliest
argument ever. They define a standard, it is the responsibility of you, the
user of said standard, to follow the guidelines. If you don't then there is
no-one to blame but yourself.
Here is an example for you.
You buy an electic kettle in the US clearly marked as using a voltage 120v AC and
then bring it to the UK and it blows up when you plug it into the 220v AC which
we use, who would you blame for this event. Yourself, for not following the
defined standard (120v) or, the UK generating company for supplying 240v?
No doubt given your record it would be the latter but that wouldn't mean you were
correct..
[SNIPPED pointless text]
bulk_trap
> On 03-Dec-01 04:33:47 bulk_trap <bulk...@yahoo.com> wrote:
> >"Timothy Rue" <thre...@earthlink.net> wrote in message
> >news:<589.734T2361T3...@earthlink.net>...
> >> Uses Javascript (will be making a decafe version in a day or so)
> >>
> >> Objective is to bring focus, though my former homepage and all links as
> >> still accessible thru a non-java link.
> >>
> >> http://www.mindspring.com/~timrue/
>
> >See http://validator.w3.org/
>
> That site is crap.
>
> I'm can't edit urls addresses (addresses external to my site) in order to
> remove errors this site generates from the valid url address in my page.
>
> Just goes to show two things.
>
> this w3c org web page ain't worth a shit and others can use it as an
> arguement to tell someone who created a web page that they are stupid.
>
> If the page doesn't work in your browser, then get a browser that works!
If you write a buggy program that won't compile, do you go out and buy
a different compiler?
Tim
>> The character set hasn't been defined, meaning that any renderer has
>> to guess whether you've use Latin-1 or something else.
On Tue, 04 Dec 2001 15:30:16 GMT, "Timothy Rue"
<thre...@earthlink.net> wrote:
> don't tell me, tell the computer to stop speaking ebonics, then maybe
> I'll learn there is actually something there to learn.
Okay, so you accept that the problem with that isn't the validator,
but the software that you're using? (That's a question, because
anyone *else* would accept that, by now.)
By and large, the character set you're using doesn't cause too many
problems, even if it has to be guessed at. Until you start using some
of the characters additional to ye olde ASCII.
e.g. Like back-ticks (mirror image apostrophes). On some character
sets they're at a different position in the character table. You can
see that problem occur most often when viewing Mac generated pages on
another computer. Likewise, with accented characters.
>> You've used parameters to commands that aren't valid:
>> * Color in a HR tag, when that's not allowed for the version
>> of HTML that you're using.
> I'm going to remove that first line <!DOCTYPE....
Which won't "solve" the problem. Either changing your code (remove
the color attribute), or using a doctype that declares what your code
really is (i.e. one where using color in a HR tag was a valid part of
HTML), is the answer.
However, I wouldn't bother for that. It's not a crucial error. Most
browsers will colour the horizontal rule, even if they shouldn't do it
in HTML 4. And, those that don't, it doesn't really matter.
HTML renders differently in most different browsers. That's something
that an HTML author will just have to live with. So long as you're
not relying on something a big dodgy to make the site usable, it's not
too important if something isn't fully supported.
Having no DOCTYPE declaration at all, is also supposedly an invalid
thing to do. If you can't really work out which one to use, you're
better to use the vaguest one you can get away with.
> It's not a matter of what HTML version I'm using so much as it is
> apparently and obviously what html version is your browsers, the
> receiver of my page, using.
Generally, yes. I'd be surprised if any browser bothered to render a
page differently, depending on what HTML version the page declared
itself to be. Though, that is a possibility. For instance, the Opera
web browser certainly treats HTML differently to XML, and XHTML I
think. But it's a fair bet that they're all going to treat HTML <br>,
<hr>, <p>, etc. (the rest of the usual tags), in the same manner,
regardless of which version of HTML you're using. It's just simpler
to make one rendering engine.
> you see, as simple as it is, there is this Horizontal Rule tool in
> the creation tool I use. It is of no concern to me I can use it,
> filling in the options I want and then see consistant results in
> the creation tool preview as well as the browser (most used - wanna
> guess?).
You *were* arguing about the validator, I was deliberately avoiding
arguing about what you were doing with your pages, and concentrating o
what the validator was doing. The validator worked as expected, and
it worked as some browsers may interpret the code. What some browsers
will do with the code is anyone's guess. You can hope the invalid
code will work, and that's it.
But there's a difference between using an attribute for a command
that's not supported, and will simply be ignored by browsers that
don't want to support it, to bad syntax errors.
e.g. <hr gobbledegook="10">
Because of how HTML is supposed to work, certain unknown things are
simply ignored. Although a validator will tell you that /that/ isn't
valid, it won't mean that the page will break (unless there was
something atrociously out of place, in there). Just that the extra
bit can't be relied upon to do anything.
But, syntax errors are going to seriously screw up rendering the page
in various browsers.
e.g. You had a faulty table, it was constructed in this fashion:
<table ... yada yada yada...>
<th>table cell heading<th>
<tr>
<td>table data</td>
</tr>
</table>
When it should have been like this:
<table ... yada yada yada...>
<tr>
<th>table cell heading<th>
</tr>
<tr>
<td>table data</td>
</tr>
</table>
Table "headings" are also cells, and need to be within <tr> "table
rules" tags.
If you don't want table rule lines to be drawn in between certain
cells, then you need to code for that properly, not just bodge around
to get your browser to display what you're after. Browsers are full
of bugs, and you'd be exploiting some bug that probably only exists in
your browser.
On some browsers the table headings wouldn't show up at all, or in the
wrong place, or all the other table cells would be shuffled out of
alignment.
> I guess what this means is that the validator page can't handle the
> more currently being used version of HTML.
>
> doesn't most used suggest "standard"?
No.
Most people thought the world was flat, but it wasn't. It's a stupid
example, I know. But that's the same line of thinking.
Before we had the W3C make a big song and dance about coding to a
defined standard, we had the various browser programmers introducing
all sorts of crap tags. Tags that only worked in their browser, pages
that only worked well in certain browsers (we still have that
problem).
The validator checks your code against the version of HTML it
identifies itself to be. HTML changed over time, what was considered
valid before, has fallen out of favour. What exists now, didn't exist
before. To check for some bugs, you have to check your HTML against
what version it really is.
> Either the html committee can impliment the standards in a manner
> that can avoid the need of duplication by browser makers and web
> page tool creators by allowing them to make use of the "already
> done once" implimentation, or they are nothing more than a paper
> pushing party that apparently the majority don't listen to very well.
>
> I'm not a browser maker, a web page tool maker or on the html commitee.
> The only reason why I'm dealing with a f*cking guessing game is because
> these three parties don't have their shit together.
The ones that don't have their act together are the browser codes, and
the HTML generator coders. Not the people who ratify what's valid
code, or not. They're the ones putting a lot of thought into it.
Making sure it's done in a workable manner. Making sure it's as
compatible as it can possibly be. Making sure that past bad practises
are excised from future coding (and there's a lot of them), which is
just one reason why we can't just keep adding to HTML, keeping
everything the same as it was, as well.
> Otherwise they are only showing me their incompetance at understanding
> the problem and complete failure to listen to the end users.
The one not understanding the situation is you. You're not willing to
study and learn. You're not willing to find out the reasons why
things are done the way that they're done. You just want to do things
however you feel is the easiest for you. And rant about how everyone
else makes it hard for you to do so.
I hope you don't drive a car. I'm sure there's plenty of /stupid/
road rules that you don't want to go along with.
If you don't know how to code complex HTML, then don't code complex
HTML. Do something else. There's a structure to how it's done, it
has to be understood before trying anything fancy. And really ought
to be understood before doing anything less than fancy, too.
Tim
"Timothy Rue" <thre...@earthlink.net> wrote:
> Seems to me the html commitee is telling the wrong party what the
> standards are. They need to tell the computer and in a language
> the machine can translate and understand and do, make happen. It's
> not my problem the machine reflects their inability to adhear to
> and impliment the standards they create. maybe da ought to tell
> computer and sho proof of the whole concept, from defining a
> standard to making it reality. Like validate what they are and do.
That childish rant makes me remember when I first started programming
in BASIC, as a young child, and wondering why; when the computer could
tell me that it found a syntax error, why it couldn't fix it? It knew
it was wrong, if it knew that much, didn't it know what it should be?
Of course I learnt the answer to that, not much later. Computers
don't "think," they compute (follow instructions), they can't do
anything without first being explicitly programmed to do so.
There is no way that some computer can be told to fix my errors, and
have it do so correctly. It's already said that it didn't know what I
meant. And even I have to re-evaluate what I was trying to do, when I
encounter a bug in my coding.
The validator checks your page for validity, it doesn't make invalid
code valid. I've never yet seen any debugging tool that could do
that, and I seriously doubt I ever will.
Gary Beeton
> On 04-Dec-01 11:24:56 Gary Beeton <gbe...@shaw.ca> wrote:
> >"Timothy Rue" <thre...@earthlink.net> wrote in message
> >news:<2005.737T2925T1...@earthlink.net>...
>
> >> If the page doesn't work in your browser, then get a browser that works!
> >>
> >> I used a web page creation tool (not a wysiwyg) that is very popular.
> >> Popular enough to know that the w3c page does not support what is more
> >> likely standard then apparently what w3c wants to says is.
>
> >Taking a page out of MicroSoft's stylebook now are we? :)
>
> I don't know. Is that another thing I'm suppoosed to do?
I was referring to how in the past you have critisized MicroSoft for
ignoring industry standards in order to gain market monopoly by
forcing the end user to use their products. I believe you call it
"consumer entrapment abuse"?
But it seems you have had a change of views and now endorse that
practice. As in: "If the page doesn't work in your browser, then get
a browser that works!", and "I used a web page creation tool (not a
wysiwyg) that is very popular. Popular enough to know that the w3c
page does not support what is more likely standard then apparently
what w3c wants to says is."
Irony can be pretty ironic sometimes, eh Tim? :)
--
Gary Beeton
Timothy Rue
>"Timothy Rue" <thre...@earthlink.net> wrote in message
>news:<2005.737T2925T1...@earthlink.net>...
>> On 03-Dec-01 04:33:47 bulk_trap <bulk...@yahoo.com> wrote:
> If you write a buggy program that won't compile, do you go out and buy
>a different compiler?
Hmmm, seems to me that yoou get a score of -1 for being redundant in your
intelligence, or lack of.
Like I said, the html code looks just fine in browsers on three different
platforms, Amiga, MS and QNX.
Geee I guess you can say it compiled, huh?
Timothy Rue
>--
>Gary Beeton
using the slash dot system, you get a -1 for being redundant.
not to mention your apparent failure realize it. Oh how ironic!
perhaps the html standards committee should actually do something real.
Timothy Rue
What I'm saying is apparently beyond you ability to comprehend. For if
those in control over HTML did their job fully, then even a kid could use
a simple text editor and any browser to learn HTML and then use it in such
a manner that everyone sees the kids creation the same.
But as it is, browsers are not valid feedback devices. Imagine that!
Things aren't what they may appear to be....right?
Why am I not supprised those in the software industry don't think it's
important to honestly include the users in the feedback cycle?
Keith Blakemore-Noble
something about "Re: New home page focus"...
> The validator checks your page for validity, it doesn't make invalid
> code valid. I've never yet seen any debugging tool that could do
> that, and I seriously doubt I ever will.
*cough*
http://www.blakemore-noble.net/Software/Tidy.html - Amiga port of Dave
Raggett's HTML Tidying program. (Dave is one of the guys in the W3C,
so he knows a bit about HTML...)
It DOES make (some) invalid code valid!
It may have fixed Timmy's little table problem, for a start :)
Also does stuff like correcting
<h1>heading
<h2>subheading</h3>
to
<h1>heading</h1>
<h2>subheading</h2>
and all sorts of other stuff, as well as laying out HTML in an
easier-to-read manner.
Sorry, just thought I'd mention it :-)
Cheers,
Keith
PS Yes, I know that Tidy is no longer developed by Dave Raggett
directly, but by a group on Sourceforge - I'm there and an Amiga port
of the new releases will appear when they do.
Timothy Rue
>On 04-Dec-01 09:46:55 Tim <T...@localhost.invalid> wrote:
>>> The character set hasn't been defined, meaning that any renderer has
>>> to guess whether you've use Latin-1 or something else.
>On Tue, 04 Dec 2001 15:30:16 GMT, "Timothy Rue"
><thre...@earthlink.net> wrote:
>
>> don't tell me, tell the computer to stop speaking ebonics, then maybe
>> I'll learn there is actually something there to learn.
>Okay, so you accept that the problem with that isn't the validator,
>but the software that you're using? (That's a question, because
>anyone *else* would accept that, by now.)
hmmm, who made the software?
>...... You can
>see that problem occur most often when viewing Mac generated pages on
>another computer.
Hmmm, interesting how standard work so well.
>>> You've used parameters to commands that aren't valid:
>>> * Color in a HR tag, when that's not allowed for the version
>>> of HTML that you're using.
>> I'm going to remove that first line <!DOCTYPE....
>Which won't "solve" the problem. Either changing your code (remove
>the color attribute), or using a doctype that declares what your code
>really is (i.e. one where using color in a HR tag was a valid part of
>HTML), is the answer.
I guessed all the choices on the list, none worked. Guess it was a trick
question huh?
>However, I wouldn't bother for that. It's not a crucial error. Most
>browsers will colour the horizontal rule, even if they shouldn't do it
>in HTML 4. And, those that don't, it doesn't really matter.
Ok, what ever you say.
>HTML renders differently in most different browsers. That's something
>that an HTML author will just have to live with. So long as you're
>not relying on something a big dodgy to make the site usable, it's not
>too important if something isn't fully supported.
you mean it's not a feature?
>Having no DOCTYPE declaration at all, is also supposedly an invalid
>thing to do. If you can't really work out which one to use, you're
>better to use the vaguest one you can get away with.
can you be any vager about which one that is? how about if I just use
<HTML> to start a page and </HTML> to end the page? Don't think I can get
any vager than that.
>> It's not a matter of what HTML version I'm using so much as it is
>> apparently and obviously what html version is your browsers, the
>> receiver of my page, using.
>Generally, yes. I'd be surprised if any browser bothered to render a
>page differently, depending on what HTML version the page declared
>itself to be. Though, that is a possibility. For instance, the Opera
>web browser certainly treats HTML differently to XML, and XHTML I
>think. But it's a fair bet that they're all going to treat HTML <br>,
><hr>, <p>, etc. (the rest of the usual tags), in the same manner,
>regardless of which version of HTML you're using. It's just simpler
>to make one rendering engine.
huh? are you saying there is "one" common rendering engine being used? Or
are you suggesting it be done?
>> you see, as simple as it is, there is this Horizontal Rule tool in
>> the creation tool I use. It is of no concern to me I can use it,
>> filling in the options I want and then see consistant results in
>> the creation tool preview as well as the browser (most used - wanna
>> guess?).
>You *were* arguing about the validator, I was deliberately avoiding
>arguing about what you were doing with your pages, and concentrating o
>what the validator was doing. The validator worked as expected, and
>it worked as some browsers may interpret the code. What some browsers
>will do with the code is anyone's guess. You can hope the invalid
>code will work, and that's it.
ok, so you are saying some browsers may work like the validator. So in
essence the point of using the validator is to validate your html page
works with some browsers? Hmmmmm... I seem to be achieving that without
the validator. And being it's anyone guess as to which browsers the
validator represents.......
>But there's a difference between using an attribute for a command
>that's not supported, and will simply be ignored by browsers that
>don't want to support it, to bad syntax errors.
>e.g. <hr gobbledegook="10">
>Because of how HTML is supposed to work, certain unknown things are
>simply ignored. Although a validator will tell you that /that/ isn't
>valid, it won't mean that the page will break (unless there was
>something atrociously out of place, in there). Just that the extra
>bit can't be relied upon to do anything.
hr attributes listed in the docs with coffeecup are align="", size="",
color="", width="", noshade="", style="", id="", class="", and title=""
></table>
></table>
Geee, you know, when I first went about using, or wanting to use tables I
went to the book store and seen what I could find on them. Not much and in
fact back when I did the table I couldn't find anything on tables that was
clear and consise in showing me the vocabulary of tables and underlying
logic. Soooo, All I really had to go by was alot of guessing and having
the browser tell me if I was right or not.
in the coffeecup docs it's just as vague (if not more so) cept it
suggest using something called style sheets. This only tells me that in
all these year that still haven't figured it out well enough to document
it in an intellient manner and suggesting using a different method suggest
that they never will.
Hmmm, and to wonder, who came up with the table thing in the first place?
>> I guess what this means is that the validator page can't handle the
>> more currently being used version of HTML.
>>
>> doesn't most used suggest "standard"?
>No.
>Most people thought the world was flat, but it wasn't. It's a stupid
>example, I know. But that's the same line of thinking.
>Before we had the W3C make a big song and dance about coding to a
>defined standard, we had the various browser programmers introducing
>all sorts of crap tags. Tags that only worked in their browser, pages
>that only worked well in certain browsers (we still have that
>problem).
Glad to know they are all on the same page in supporting the users thru a
standard........
>The validator checks your code against the version of HTML it
>identifies itself to be. HTML changed over time, what was considered
>valid before, has fallen out of favour. What exists now, didn't exist
>before. To check for some bugs, you have to check your HTML against
>what version it really is.
Glad to know they have figured out how to break the users into
submission.... that they the user will never be as smart as the geniuses
that think this crap up.
>
>> Either the html committee can impliment the standards in a manner
>> that can avoid the need of duplication by browser makers and web
>> page tool creators by allowing them to make use of the "already
>> done once" implimentation, or they are nothing more than a paper
>> pushing party that apparently the majority don't listen to very well.
>>
>> I'm not a browser maker, a web page tool maker or on the html commitee.
>> The only reason why I'm dealing with a f*cking guessing game is because
>> these three parties don't have their shit together.
>The ones that don't have their act together are the browser codes, and
>the HTML generator coders. Not the people who ratify what's valid
>code, or not. They're the ones putting a lot of thought into it.
>Making sure it's done in a workable manner. Making sure it's as
>compatible as it can possibly be. Making sure that past bad practises
>are excised from future coding (and there's a lot of them), which is
>just one reason why we can't just keep adding to HTML, keeping
>everything the same as it was, as well.
LOL! Theorist theorizing they are correct and all powerful, but never
really proving it. But someday they will get their snail asses across the
mud, if they will just stop getting steped on.
>> Otherwise they are only showing me their incompetance at understanding
>> the problem and complete failure to listen to the end users.
>The one not understanding the situation is you. You're not willing to
>study and learn. You're not willing to find out the reasons why
>things are done the way that they're done. You just want to do things
>however you feel is the easiest for you. And rant about how everyone
>else makes it hard for you to do so.
your absolutely right, just learning to drive a car and getting a license
should be against the law. Everyone should have to learn how to build and
fix cars, from mining the ore to make metal and whatever it takes to learn
about rubber manufacturing and how to make gasoline, etc... before they
are issued a license. Or learn how to make a typewritter before they are
allowed to learn to type. or a computer before they are allowed to learn
how to turn it on.......
>I hope you don't drive a car. I'm sure there's plenty of /stupid/
>road rules that you don't want to go along with.
Geee, maybe I should have read ahead before typing what I did above!
>If you don't know how to code complex HTML, then don't code complex
>HTML. Do something else. There's a structure to how it's done, it
>has to be understood before trying anything fancy. And really ought
>to be understood before doing anything less than fancy, too.
Considering all the industry side problems you mention above, should it
really be of any suprise to me that you have so completely fallen on your
face in your failure to understand the most basic concept of the feedback
loop, a concept that is even used and taught in kindergarden?
If I were a teacher grading the web browser industry, I'd have no choice
but to give it an 'I' for incomplete as it seems to have missed so many
classes that it can't possibly have learned how to learn, not to mention
missing the test to find out. And what time it was in class it was being
so disruptive that it spent alot of time in the deans office being "talked
to". If the browser industry was a teacher and I the employer, they would
be on notice that I am looking for a replacement (and that there are
indeed some potential replacements such as rebol) and that if they
don't straighten their act out by the time one of these is ready to
replace them, they will be out of a job. Though I doubt they would hear
that any better than being talked to by the dean.
Timothy Rue
>Hi there Tim, on or around Wed, 05 Dec 2001 23:01:14 +1030 you wrote
>something about "Re: New home page focus"...
>> The validator checks your page for validity, it doesn't make invalid
>> code valid. I've never yet seen any debugging tool that could do
>> that, and I seriously doubt I ever will.
>*cough*
>http://www.blakemore-noble.net/Software/Tidy.html - Amiga port of Dave
>Raggett's HTML Tidying program. (Dave is one of the guys in the W3C,
>so he knows a bit about HTML...)
Take some cough medicine, you are making it sound like validator page
and the tidy program are the same thing. Clearly they are not as the
validator is web based and as such needs no porting.
>It DOES make (some) invalid code valid!
>It may have fixed Timmy's little table problem, for a start :)
you don't know? Besides the fact my name is not "timmy", that about
fixing stuff and your question "may have".
>Also does stuff like correcting
><h1>heading
><h2>subheading</h3>
>to
><h1>heading</h1>
><h2>subheading</h2>
>and all sorts of other stuff, as well as laying out HTML in an
>easier-to-read manner.
>Sorry, just thought I'd mention it :-)
Hmmm, does it help teach the user good habits and correct coding or does
it just do it for the user without notice, supporting whatever bad habits
and code errors the user has?
>Cheers,
>Keith
>PS Yes, I know that Tidy is no longer developed by Dave Raggett
>directly, but by a group on Sourceforge - I'm there and an Amiga port
>of the new releases will appear when they do.
That will be a $200 consultant fee, thank you very much. Even if this is
just an "Amiga Promise" yet never to be, release.
Bill Godfrey
> See http://validator.w3.org/
Reading the rest of this thread, there's a lot of minunderstanding
(naming no names) as to what exactly an HTML validator does.
HTML is specified by a document called a DTD. This document specifies
what elements are supported, which tags may be ommitted and the
general structure of the document.
At the start of an HTML document, you can (should) specify a DOCTYPE
declaration, declaring which DTD this HTML document has been written
to.
A validator reads both the HTML and the referenced DTD and reports
errors where the HTML does not conform to the DTD. Nothing more. Nothing
less.
If the validator reports (say) that the COLOR attribute is not allowed
in the <HR> tag, then you have many approaches available...
a. Live with the error.
b. Use a different DTD which does allow COLOR within <HR>
c. Write your own DTD to allow COLOR in <HR>
d. Fix the error by removing the COLOR attribute.
What you should not do is blame the validator. It's just a tool, and
it's done it's defined job and reported errors.
The W3C don't have a monopoly on DTD writing. The ISO have published
some. The IETF used to publish them. I've published some.
<!DOCTYPE HTML PUBLIC "-//Bill Godfrey//DTD HTML BillG 1.0//EN">
Validators only pick up errors as definined by the DTD. There are
other errors which a validator might not pick up. Tools for these
are collectively known as "linters" or "checkers", but not
validators.
Bill, valley date.
Tim
>> The validator checks your page for validity, it doesn't make invalid
>> code valid. I've never yet seen any debugging tool that could do
>> that, and I seriously doubt I ever will.
On 5 Dec 2001 19:11:32 GMT,
"Keith Blakemore-Noble" <Ke...@Blakemore-Noble.net> wrote:
> *cough*
> http://www.blakemore-noble.net/Software/Tidy.html - Amiga port of Dave
> Raggett's HTML Tidying program. (Dave is one of the guys in the W3C,
> so he knows a bit about HTML...)
>
> It DOES make (some) invalid code valid!
>
> It may have fixed Timmy's little table problem, for a start :)
>
> Also does stuff like correcting
>
> <h1>heading
> <h2>subheading</h3>
>
> to
>
> <h1>heading</h1>
> <h2>subheading</h2>
>
> and all sorts of other stuff, as well as laying out HTML in an
> easier-to-read manner.
>
> Sorry, just thought I'd mention it :-)
Worth mentioning. But fixing up silly errors, especially ones made by
an HTML generator, is really a dumb thing to *have* to do. ;-)
And while it would be possible to fairly simply fix up some errors, as
you've pointed out, there's also going to be enough that it couldn't
resolve. And therein lies the problem; people tend to rely on these
things, without due care for their limitations.
One thing that I have found out, with programs that "tidy" HTML
(re-format the source code in a "structured" way), and that they also
(usually) explain to you; is that sometimes that can cause the HTML to
render a little bit out of kilter.
e.g. Turning:
<table>
<tr><td>blah blah............</td></tr>
</table>
Into:
<table>
<tr>
<td>
blah blah............
</td>
</tr>
</table>
Can cause the first word in that table cell to be indented by one
character (all those preceding blank spaces being rendered as one
single space). That can be a problem, depending on the content of the
table cell (particularly if it's got several lines of text in it, or
it has to line up vertically with something in a cell above it).
Gary Beeton
I apologize for repeating myself, Tim. But based on your
scatter-brained reply to my original post I could only assume that you
completely missed my point. And perhaps you still don't see it since
you haven't yet refuted my claim that you are a hypocrite.
> perhaps the html standards committee should actually do something real.
They've given you all the information and tools necessary to allow you
to learn. What more do you expect? Do you want them to write your
code for you?
--
Gary Beeton
Tim
"Timothy Rue" <thre...@earthlink.net> wrote:
>>> Seems to me the html commitee is telling the wrong party what the
>>> standards are. They need to tell the computer and in a language
>>> the machine can translate and understand and do, make happen. It's
>>> not my problem the machine reflects their inability to adhear to
>>> and impliment the standards they create. maybe da ought to tell
>>> computer and sho proof of the whole concept, from defining a
>>> standard to making it reality. Like validate what they are and do.
On 05-Dec-01 08:01:14 Tim <T...@localhost.invalid> wrote:
>> That childish rant makes me remember when I first started programming
>> in BASIC, as a young child, and wondering why; when the computer could
>> tell me that it found a syntax error, why it couldn't fix it? It knew
>> it was wrong, if it knew that much, didn't it know what it should be?
>>
>> Of course I learnt the answer to that, not much later. Computers
>> don't "think," they compute (follow instructions), they can't do
>> anything without first being explicitly programmed to do so.
>>
>> There is no way that some computer can be told to fix my errors, and
>> have it do so correctly. It's already said that it didn't know what I
>> meant. And even I have to re-evaluate what I was trying to do, when I
>> encounter a bug in my coding.
>>
>> The validator checks your page for validity, it doesn't make invalid
>> code valid. I've never yet seen any debugging tool that could do
>> that, and I seriously doubt I ever will.
On Wed, 05 Dec 2001 18:02:11 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> What I'm saying is apparently beyond you ability to comprehend. For if
> those in control over HTML did their job fully, then even a kid could use
> a simple text editor and any browser to learn HTML and then use it in such
> a manner that everyone sees the kids creation the same.
The only one not comprehending things, is you. Every time you don't
understand how something is, but insist that it ought to be the way
you want it to be, you reckon that people don't comprehend what you're
saying.
What YOU do NOT comprehend is that you've got it all completely wrong.
What YOU do NOT comprehend is: The people who do control what HTML
really is (the W3C) already do everything that they can to ensure that
HTML is not some black art. The specifications are published, they're
publicly available to *everybody*, and easily obtainable (they're not
hidden anywhere, or require registering to read them), and avoiding
adhering to them is denounced by the W3C.
What YOU also fail to comprehend is that the W3C are in no position to
enforce that HTML renderers or generators adhere to the specifications
(HTML isn't a format that requires a license to use, that could
dictate the manner in which it can be used once you're licensed).
What YOU also fail to comprehend is that HTML agent programmers, be
authors, creators or renderers, are the ones who can't be stuffed to
do things properly. When writing code, the only person to blame for
errors, is the person doing the coding. If they also don't know what
they're doing, that's their fault, too.
STOP blaming everybody but the right person for what is wrong.
And stop prattling on like some demented lunatic. You always speak
like one of those deranged "new age channellers" with no brains and
lots of flowery words, blathering on about all sorts of totally
irrelevant things to whatever the topic actually is, with no grip on
reality.
Tim
>>>> The character set hasn't been defined, meaning that any renderer has
>>>> to guess whether you've use Latin-1 or something else.
On Tue, 04 Dec 2001 15:30:16 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
>>> don't tell me, tell the computer to stop speaking ebonics, then maybe
>>> I'll learn there is actually something there to learn.
On 05-Dec-01 07:52:12 Tim <T...@localhost.invalid> wrote:
>> Okay, so you accept that the problem with that isn't the validator,
>> but the software that you're using? (That's a question, because
>> anyone *else* would accept that, by now.)
On Wed, 05 Dec 2001 20:10:32 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> hmmm, who made the software?
So far as I'm aware. CoffeeCup's HTML editor, that you've mentioned
elsewhere, hasn't got anything to do with the W3C.
The problem isn't with the W3C, it's with what you're doing/using.
>> ..............................................................You can
>> see that problem occur most often when viewing Mac generated pages on
>> another computer.
> Hmmm, interesting how standard work so well.
That standard (which character set you're using) does work, when
people actually conform to the standards: Clearly identifying which
character set that you've used in your pages.
HTML, plain text, or otherwise, use a different character set on the
authoring program to the reading agent, provide no means to inform the
reader that you've used which character set, and no means to do any
conversions before rendering the text, and you'll strike the same
problem.
It's got nothing to do with the W3C, or the web. It's general
problem, and one that actually is addressed, on the web, when people
bother to do so, by specifying the character set in use.
e.g. By a line, like this, in the header:
<meta http-equiv="content-type"
content="text/html; charset=iso-8859-1">
Without a clear description of what's being used, the renderer can
only guess. Perhaps it can make a correct guess, by scanning the
contents, and looking for some known characters belonging to a certain
character set. But there's too many character codes used in different
sets, for different purposes, to be able to do it.
Often, a browser will default to its native OS character set, when it
doesn't know which one has been used (e.g. Latin-1, for the Amiga, the
Windows character set for Windows). That'll usually work fine, for
most of the standard alphanumerical symbols, but not for much else.
Including some of the common typographical symbols.
>>>> You've used parameters to commands that aren't valid:
>>>> * Color in a HR tag, when that's not allowed for the version
>>>> of HTML that you're using.
>>> I'm going to remove that first line <!DOCTYPE....
>> Which won't "solve" the problem. Either changing your code (remove
>> the color attribute), or using a doctype that declares what your code
>> really is (i.e. one where using color in a HR tag was a valid part of
>> HTML), is the answer.
> I guessed all the choices on the list, none worked. Guess it was a trick
> question huh?
No. Just a case of knowing (understanding) what you're doing.
>> Having no DOCTYPE declaration at all, is also supposedly an invalid
>> thing to do. If you can't really work out which one to use, you're
>> better to use the vaguest one you can get away with.
> can you be any vager about which one that is? how about if I just use
> <HTML> to start a page and </HTML> to end the page? Don't think I can get
> any vager than that.
e.g. Using the transitional ones. And, if you're not using any
command that only existed in a newer format of HTML, one of the DTDs
from an older version.
Gee, why not just go and read the HTML specs, and save us all this
torture?
e.g.
http://www.w3.org/MarkUp/ (HTML resources overview)
http://www.w3.org/TR/html4 (Latest version of HTML)
>>> It's not a matter of what HTML version I'm using so much as it is
>>> apparently and obviously what html version is your browsers, the
>>> receiver of my page, using.
>> Generally, yes. I'd be surprised if any browser bothered to render a
>> page differently, depending on what HTML version the page declared
>> itself to be. Though, that is a possibility. For instance, the Opera
>> web browser certainly treats HTML differently to XML, and XHTML I
>> think. But it's a fair bet that they're all going to treat HTML <br>,
>> <hr>, <p>, etc. (the rest of the usual tags), in the same manner,
>> regardless of which version of HTML you're using. It's just simpler
>> to make one rendering engine.
> huh? are you saying there is "one" common rendering engine being used? Or
> are you suggesting it be done?
No. I'm saying that any particular browser, is likely to have an
engine (within it self), that always renders HTML in the same manner.
Not that all browsers use the same engine.
i.e. Netscape is likely to render HTML 3 the same as it does HTML 4.
IE is likely to render HTML 3 the same as it does HTML 4.
But Netscape isn't likely to do it the same way as IE.
Are you really not bothering to think about what you're reading, or
going out of your way to be pedantic, just to argue about this?
>>> you see, as simple as it is, there is this Horizontal Rule tool in
>>> the creation tool I use. It is of no concern to me I can use it,
>>> filling in the options I want and then see consistant results in
>>> the creation tool preview as well as the browser (most used - wanna
>>> guess?).
>> You *were* arguing about the validator, I was deliberately avoiding
>> arguing about what you were doing with your pages, and concentrating o
>> what the validator was doing. The validator worked as expected, and
>> it worked as some browsers may interpret the code. What some browsers
>> will do with the code is anyone's guess. You can hope the invalid
>> code will work, and that's it.
> ok, so you are saying some browsers may work like the validator. So in
> essence the point of using the validator is to validate your html page
> works with some browsers? Hmmmmm... I seem to be achieving that without
> the validator. And being it's anyone guess as to which browsers the
> validator represents.......
The point of making valid HTML, or any other code, is so that it works
in as many browsers as possible.
Hopefully, browsers are designed to work right with valid code.
Using invalid code has an unknown result. You don't know what the end
results will be, and your own limited testing of your code is just
that; a limited indication of what has worked, so far. Use a
different browser, or a different version of a browser, and the
results could change.
In some cases, the results could be a serious problem in the rendering
of the page. I've seen pages where the entire file has stopped
rendering near the start (blank from then onwards), because of a
significant syntax error.
However, the page worked fine on the browser the author tested it on.
Why? Because their browser was faulty.
Browsers are a useless debugging tool.
>> But there's a difference between using an attribute for a command
>> that's not supported, and will simply be ignored by browsers that
>> don't want to support it, to bad syntax errors.
>>
>> e.g. <hr gobbledegook="10">
>>
>> Because of how HTML is supposed to work, certain unknown things are
>> simply ignored. Although a validator will tell you that /that/ isn't
>> valid, it won't mean that the page will break (unless there was
>> something atrociously out of place, in there). Just that the extra
>> bit can't be relied upon to do anything.
> hr attributes listed in the docs with coffeecup are align="", size="",
> color="", width="", noshade="", style="", id="", class="", and title=""
Firstly, not all browsers will understand some of them, regardless of
if they're valid. So it's worth remembering that.
Secondly, and this is a fault I noticed with the code CoffeeCup
generated on your page, is that when not specifying an attribute value
(because you desire to use the default value), you should not use
attribute="" (as it did) but omit the entire attribute.
Thirdly, the default value of some elements isn't the same for all
browsers.
e.g. If you just specified <hr> most browsers would draw a line
*almost* 100% across the page, and it would be centred. But not *all*
browsers will do that.
>> But, syntax errors are going to seriously screw up rendering the page
>> in various browsers.
>>
>>e.g. You had a faulty table, it was constructed in this.......
> Geee, you know, when I first went about using, or wanting to use tables I
> went to the book store and seen what I could find on them. Not much and in
> fact back when I did the table I couldn't find anything on tables that was
> clear and consise in showing me the vocabulary of tables and underlying
> logic. Soooo, All I really had to go by was alot of guessing and having
> the browser tell me if I was right or not.
If you'd read the HTML specifications, then you'd know the syntax.
They're described, in quite extreme technical detail, on the W3C site.
And in varying degrees of technicality on various other HTML help
sites (though, it has to be noted that various unofficial help sites
give out information that's so vague to be misleading, or is just
plain wrong).
> in the coffeecup docs it's just as vague (if not more so) cept it
> suggest using something called style sheets. This only tells me that in
> all these year that still haven't figured it out well enough to document
> it in an intellient manner and suggesting using a different method suggest
> that they never will.
So much for your widely used HTML generator being something of a point
of reference, regarding a standard way of doing things.
Tables are often badly implemented in HTML authoring programs. Both
in their program usage instructions, and the manner in which they let
you design them.
> Hmmm, and to wonder, who came up with the table thing in the first place?
Netscape, if I recall correctly. But that really doesn't matter.
They're also badly used, in many cases. Tables are for tabulating /
formatting data in, in a tabular form.
e.g.
Quantity Item name Item cost
1 Spanners $12.50
2 Bolts $ 1.02
Hence why the command is named "table."
They're not meant for sticking text in a certain position on the page.
Hence why that approach fails miserably, quite often. It's a misuse
of the function.
>> The validator checks your code against the version of HTML it
>> identifies itself to be. HTML changed over time, what was considered
>> valid before, has fallen out of favour. What exists now, didn't exist
>> before. To check for some bugs, you have to check your HTML against
>> what version it really is.
> Glad to know they have figured out how to break the users into
> submission.... that they the user will never be as smart as the
> geniuses that think this crap up.
What the hell has it got to do with the "users"? It's about
authoring. Until a page fails to render, a user doesn't care about
how it's coded, and they shouldn't have to, either. It's up to people
publicly publishing documents to do so in a manner that actually
works.
Before, you were moaning about how they should be ensuring that all
browsers work the same way, now you're saying that they're bad guys
for dictating people do things properly.
>>> Either the html committee can impliment the standards in a manner
>>> that can avoid the need of duplication by browser makers and web
>>> page tool creators by allowing them to make use of the "already
>>> done once" implimentation, or they are nothing more than a paper
>>> pushing party that apparently the majority don't listen to very well.
>>>
>>> I'm not a browser maker, a web page tool maker or on the html commitee.
>>> The only reason why I'm dealing with a f*cking guessing game is because
>>> these three parties don't have their shit together.
>> The ones that don't have their act together are the browser codes, and
>> the HTML generator coders. Not the people who ratify what's valid
>> code, or not. They're the ones putting a lot of thought into it.
>> Making sure it's done in a workable manner. Making sure it's as
>> compatible as it can possibly be. Making sure that past bad practises
>> are excised from future coding (and there's a lot of them), which is
>> just one reason why we can't just keep adding to HTML, keeping
>> everything the same as it was, as well.
> LOL! Theorist theorizing they are correct and all powerful, but never
> really proving it. But someday they will get their snail asses across the
> mud, if they will just stop getting steped on.
Just what the hell is that supposed to mean? Are you completely nuts,
or do you just do it part time?
>>> Otherwise they are only showing me their incompetance at understanding
>>> the problem and complete failure to listen to the end users.
>> The one not understanding the situation is you. You're not willing to
>> study and learn. You're not willing to find out the reasons why
>> things are done the way that they're done. You just want to do things
>> however you feel is the easiest for you. And rant about how everyone
>> else makes it hard for you to do so.
> your absolutely right, just learning to drive a car and getting a license
> should be against the law. Everyone should have to learn how to build and
> fix cars, from mining the ore to make metal and whatever it takes to learn
> about rubber manufacturing and how to make gasoline, etc... before they
> are issued a license. Or learn how to make a typewritter before they are
> allowed to learn to type. or a computer before they are allowed to learn
> how to turn it on.......
>> I hope you don't drive a car. I'm sure there's plenty of /stupid/
>> road rules that you don't want to go along with.
> Geee, maybe I should have read ahead before typing what I did above!
To put your misrepresentation of the analogy into proper context; if
you were building a car, yes you'd have to know about design, and a
lot of technical details about the working of it. But not as a user.
A user just has to learn how to drive the car.
You're building HTML, not reading it. You should be learning about
doing it properly.
>> If you don't know how to code complex HTML, then don't code complex
>> HTML. Do something else. There's a structure to how it's done, it
>> has to be understood before trying anything fancy. And really ought
>> to be understood before doing anything less than fancy, too.
> Considering all the industry side problems you mention above, should it
> really be of any suprise to me that you have so completely fallen on your
> face in your failure to understand the most basic concept of the feedback
> loop, a concept that is even used and taught in kindergarden?
The only one not "understanding" the situation, is you. And like some
smart arse kid in school, who'd too "up themselves" to admit that they
don't know what the hell it is that they're talking about, you try and
blame someone else for your own inadequacies.
The *only* person you're fooling is yourself.
> If I were a teacher grading the web browser industry, I'd have no choice
> but to give it an 'I' for incomplete...............
That much, you're correct.
>...................................... as it seems to have missed so many
> classes that it can't possibly have learned how to learn, not to mention
> missing the test to find out. And what time it was in class it was being
> so disruptive that it spent alot of time in the deans office being "talked
> to".
This, is yourself.
Mike Sutton
> On 05-Dec-01 00:29:46 bulk_trap <bulk...@yahoo.com> wrote:
> >"Timothy Rue" <thre...@earthlink.net> wrote in message
> >news:<2005.737T2925T1...@earthlink.net>...
> >> On 03-Dec-01 04:33:47 bulk_trap <bulk...@yahoo.com> wrote:
>
> > If you write a buggy program that won't compile, do you go out and buy
> >a different compiler?
>
> Hmmm, seems to me that yoou get a score of -1 for being redundant in your
> intelligence, or lack of.
>
> Like I said, the html code looks just fine in browsers on three different
> platforms, Amiga, MS and QNX.
>
> Geee I guess you can say it compiled, huh?
Code for which the compiler generates 100's of "warnings" for, even
though it will compile and link, is code that is not standard and very
often behaves in ways not intended or understood. It's best to
eliminate the warnings to be sure that both you and the compiler
understand exactly what you mean for the code to do.
--
Mike Sutton
Mike Sutton
> Geee, you know, when I first went about using, or wanting to use tables I
> went to the book store and seen what I could find on them. Not much and in
> fact back when I did the table I couldn't find anything on tables that was
> clear and consise in showing me the vocabulary of tables and underlying
> logic. Soooo, All I really had to go by was alot of guessing and having
> the browser tell me if I was right or not.
If it were the job of browsers to validate HTML, this would have been a
good strategy. Unfortunately, that's not what browsers are designed to
do. Browsers are designed to display as best they can, whatever trash
the author of supposedly HTML pages tells to them to display. Browsers
understand that HTML is not for kindergarten children to program, and
thus try their darndest to avoid, ignore, or otherwise work around bad,
non-standard HTML. In short, the browsers are not designed to
understand standard HTML, and only standard HTML. They're designed to
take whatever the author believes is HTML and render that as best they
can.
If you want to know how to correctly code HTML, you need to go to an
authoritative source. Browsers do not qualify. You need a validator,
and a specification of the standard. Not a browser and somebody's idea
of a how-to book.
> in the coffeecup docs it's just as vague (if not more so) cept it
> suggest using something called style sheets. This only tells me that in
> all these year that still haven't figured it out well enough to document
> it in an intellient manner and suggesting using a different method suggest
> that they never will.
As I said, HTML is not for kindergarteners. Many authors are only out
there to make money publishing something almost useful. Just because
the book says HTML on the cover doesn't means it's an authoritative
source.
> Hmmm, and to wonder, who came up with the table thing in the first place?
Irrelevant.
--
Mike Sutton
Kirk Strauser
At 2001-12-06T15:58:50Z, Tim <T...@localhost.invalid> writes:
> Worth mentioning. But fixing up silly errors, especially ones made by an
> HTML generator, is really a dumb thing to *have* to do. ;-)
Welcome to my world. I have the undesirable job of fixing code (in our
case, PHP pages) that our graphic designer loads into Dreamweaver, makes
minor tweaks to, and saves back out. It gets screwed up almost every time
(two <html> tags, multiple <body> tags, etc.). Is it his fault? Not
really. Dreamweaver seemingly randomly breaks things that don't fit into
its little worldview. Our designer is just trying to use a tool that, to
him, works pretty well and lets him do his job.
> One thing that I have found out, with programs that "tidy" HTML
> (re-format the source code in a "structured" way), and that they also
> (usually) explain to you; is that sometimes that can cause the HTML to
> render a little bit out of kilter.
>
> e.g. Turning:
>
> <table>
> <tr><td>blah blah............</td></tr>
> </table>
>
> Into:
>
> <table>
> <tr>
> <td>
> blah blah............
> </td>
> </tr>
> </table>
>
> Can cause the first word in that table cell to be indented by one
> character (all those preceding blank spaces being rendered as one single
> space).
It shouldn't. That leading whitespace should be ignored.
> That can be a problem, depending on the content of the table cell
> (particularly if it's got several lines of text in it, or it has to line
> up vertically with something in a cell above it).
Repeat after me: "HTML is not a layout language. HTML is not a layout
language. HTML is not a layout language." :)
--
Kirk Strauser
bulk_trap
> On 05-Dec-01 00:29:46 bulk_trap <bulk...@yahoo.com> wrote:
> >"Timothy Rue" <thre...@earthlink.net> wrote in message
> >news:<2005.737T2925T1...@earthlink.net>...
> >> On 03-Dec-01 04:33:47 bulk_trap <bulk...@yahoo.com> wrote:
>
> > If you write a buggy program that won't compile, do you go out and buy
> >a different compiler?
>
> Hmmm, seems to me that yoou get a score of -1 for being redundant in your
> intelligence, or lack of.
>
> Like I said, the html code looks just fine in browsers on three different
> platforms, Amiga, MS and QNX.
>
> Geee I guess you can say it compiled, huh?
The HTML validator is just an automated program to check for errors.
It's not as though the W3C assigned a human to check your web page.
So there's no need to treat the output of the validator program as
though it was some sort of personal criticism directed at you.
Keith Blakemore-Noble
something about "Re: New home page focus"...
>
> >> The validator checks your page for validity, it doesn't make
> >> invalid code valid. I've never yet seen any debugging tool that
> >> could do that, and I seriously doubt I ever will.
>
>
> On 5 Dec 2001 19:11:32 GMT,
> "Keith Blakemore-Noble" <Ke...@Blakemore-Noble.net> wrote:
>
> > *cough*
> > http://www.blakemore-noble.net/Software/Tidy.html - Amiga port of
> > Dave Raggett's HTML Tidying program. (Dave is one of the guys in
> > the W3C, so he knows a bit about HTML...)
> >
> > It DOES make (some) invalid code valid!
> >
> > It may have fixed Timmy's little table problem, for a start :)
> >
> > Also does stuff like correcting
> >
> > <h1>heading
> > <h2>subheading</h3>
> >
> > to
> >
> > <h1>heading</h1>
> > <h2>subheading</h2>
> >
> > and all sorts of other stuff, as well as laying out HTML in an
> > easier-to-read manner.
> >
> > Sorry, just thought I'd mention it :-)
>
> Worth mentioning. But fixing up silly errors, especially ones made
> by an HTML generator, is really a dumb thing to *have* to do. ;-)
Oh, I completely agree with you there!
I just couldn't resist mentioning it in light of what you said, that
was all :-)
But yeah, using it to fix errors made by crap HTML generators is not
the best use of one's time. Although it can be told to successfully
strip out the bloated pointless crap that M$ Word 2000 insists on
flooding your HTML with, which is nice.
> One thing that I have found out, with programs that "tidy" HTML
> (re-format the source code in a "structured" way), and that they also
> (usually) explain to you; is that sometimes that can cause the HTML
> to render a little bit out of kilter.
>
> e.g. Turning:
>
> <table>
> <tr><td>blah blah............</td></tr>
> </table>
>
> Into:
>
> <table>
> <tr>
> <td>
> blah blah............ </td> </tr>
> </table>
Erm, have you used Tidy?
Reason I ask is that it does NOT do what you just claimed!
I just tried the input you gave above, with the necessary HTML, HEAD
and BODY tags of course, and used the "-indent" option. The result?
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title></title>
</head>
<body>
<table>
<tr>
<td>blah blah............</td> </tr> </table>
</body>
</html>
Note that is specifically does NOT mess up the TD cell! This is quite
deliberate.
Now, you CAN force it to to that by setting indent mode to "yes" rather
than "auto", but even the docs caution against that! By setting the
indent mode to "auto" (e.g. from a config file, or on the command line
via tidy --indent auto input.html ) then it will indent but make
intelligent decisions so as not to screw up tables. Neat, huh? )
> Can cause the first word in that table cell to be indented by one
> character (all those preceding blank spaces being rendered as one
> single space). That can be a problem, depending on the content of
> the table cell (particularly if it's got several lines of text in it,
> or it has to line up vertically with something in a cell above it).
That's EXACTLY why Tidy does NOT do what you described unless you
deliberately over-ride the settings and go against the documentation's
recommendations :-)
Erm, but I digress!
Cheers,
Keith
John Burns
I don't think Tim understands irony. I think this was just a side effect of
his refusal to accept that he is in any way wrong.
Timothy Rue
>The W3C don't have a monopoly on DTD writing. The ISO have published
>some. The IETF used to publish them. I've published some.
><!DOCTYPE HTML PUBLIC "-//Bill Godfrey//DTD HTML BillG 1.0//EN">
>Validators only pick up errors as definined by the DTD. There are
>other errors which a validator might not pick up. Tools for these
>are collectively known as "linters" or "checkers", but not
>validators.
Where does one find these DTDs?
How Does one specify to the validator as to where to find the DTDs?
Do Browsers have DTDs?
(so as one might be able to know what a browser can handle and not.)
Where can someone find information on making a DTD that is acceptable to
the W3C validator?
Is there any validators, linters, checkers that are free and available for
offline use as independant applications or browser plugins?
Why aren't DTD called BVDs?
If there is going to be a commitee determination of what the standards are
going to be defined as for a given version of the standards, why does not
the commitee insure this by making the standard a plugin or such a work
that all the browser makers can make use of in such a manner that insures
they are compliant (using the very same defining work)? Even better would
be to allow a browser to be upgraded in HTML version compatabiliy by such
a plugin?
The only difference betwen writting a standard in human to human language
and human to machine, is that human to machine is going to have alot less
in interpretation variation and need less in reinvention coding. Certainly
something that for which the browser makers themselves could team up on
and save themselves each some coding time. For the sake of "standard"
Given the above, is it then not possible and intelligently viable to add
to any browser such an html (and perhaps others like javascript as plugin
extensions or what ever) coding feedback system such that the end use has
one hell of a better chance at learning good coding practices and proper
html usage?
Tim
>> Worth mentioning. But fixing up silly errors, especially ones made
>> by an HTML generator, is really a dumb thing to *have* to do. ;-)
"Keith Blakemore-Noble" <Ke...@Blakemore-Noble.net> wrote:
> Oh, I completely agree with you there!
>
> I just couldn't resist mentioning it in light of what you said, that
> was all :-)
While it's possible for some syntax errors to be corrected, there's
still plenty of HTML programming error possibilities that can't be
guessed at.
> But yeah, using it to fix errors made by crap HTML generators is not
> the best use of one's time. Although it can be told to successfully
> strip out the bloated pointless crap that M$ Word 2000 insists on
> flooding your HTML with, which is nice.
Earlier today I read an HTML page that was generated on MS Word, and
it wasn't generated badly. I was staggered! It was almost perfect.
Nothing in it that shouldn't be there. Though, I don't know if the
author tidied up the code afterwards.
>> One thing that I have found out, with programs that "tidy" HTML
>> (re-format the source code in a "structured" way), and that they also
>> (usually) explain to you; is that sometimes that can cause the HTML
>> to render a little bit out of kilter.
> Erm, have you used Tidy?
>
> Reason I ask is that it does NOT do what you just claimed!
No. I haven't tried a program called "Tidy," but I have used "tidy
up" functions in HTML editors. I said programs that "tidy" HTML (as
in ones that perform a process of "tidying" them up).
> Note that is specifically does NOT mess up the TD cell! This is quite
> deliberate.
>
> Now, you CAN force it to that by setting indent mode to "yes" rather
> than "auto", but even the docs caution against that! By setting the
> indent mode to "auto" (e.g. from a config file, or on the command line
> via tidy --indent auto input.html ) then it will indent but make
> intelligent decisions so as not to screw up tables. Neat, huh? )
I'm glad that it does function that way (though you'd expect it to,
considering it's origins), and also that they've documented the
information.
Tim
"Timothy Rue" <thre...@earthlink.net> wrote:
> Where does one find these DTDs?
Read the HTML specs at the W3C site. They list addresses for them.
On a well defined HTML document, the DTD not only says which DTD it's
coded to adhere to, but the address to load the DTD from.
e.g. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
The first line specifies which DTD applies to this document, the
second line the location for that DTD. Click on the link, and you'll
be able to read it (it's a plain text file).
A really spiffy browser could actually use that DTD to work out how
render the document. Giving some future proofing, to allow a browser
to deal with things that were invented after the browser was created.
> How Does one specify to the validator as to where to find the DTDs?
If it's a standard DTD, the validator already knows where to find it.
Most of the standard DTDs are W3C ones, they've got them stored on
their server. If it's a custom one, you provide the address, as per
my example (above).
> Do Browsers have DTDs?
> (so as one might be able to know what a browser can handle and not.)
Something similar, but more the converse of what the DTD is.
When a browser connects to a HTTP server, it informs the server about
which browser it is, and some of it's capabilities (e.g. that it
accepts text/html, text/plain, images/*, etc.).
> Where can someone find information on making a DTD that is acceptable to
> the W3C validator?
Have you bothered to visit the W3C site?
(Avoiding the temptation to just say RTFM.)
> Is there any validators, linters, checkers that are free and available for
> offline use as independant applications or browser plugins?
Not avoiding the temptation to say, use a search engine, or even read
the W3C web site - it's got links to external services (documents,
tutorials, software, etc).
> Why aren't DTD called BVDs?
DTD - document type definition (a declaration of what the document is,
that has this DTD at its head).
HTML 4.01 Specification:
http://www.w3.org/TR/REC-html40/
And on that above page, there's a link to:
3.3 How to read the HTML DTD:
http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.3
> If there is going to be a commitee determination of what the standards are
> going to be defined as for a given version of the standards, why does not
> the commitee insure this by making the standard a plugin or such a work
> that all the browser makers can make use of in such a manner that insures
> they are compliant (using the very same defining work)? Even better would
> be to allow a browser to be upgraded in HTML version compatabiliy by such
> a plugin?
The W3C ratifies HTML code, amongst other things. Plug-ins to add new
features are designed by coders to do something new. And the
interface to the browser is dictated by whomever coded the browser.
HTML specs describe how certain parts of HTML should be rendered, but
only in what the end result should be, now how the dots on the screen
should be engineered.
e.g. The <p> paragraph markers delineate that a block of text is a
paragraph, and the browser should make that visibly obvious. They
don't dictate that the paragraph be formatted as a square block, or
start indented. Either way could be done, so that's yet another
example of why not to expect your HTML to look the same for someone
else. Your own particular browser is no indication of how things will
be done, nor should be done.
> The only difference betwen writting a standard in human to human language
> and human to machine, is that human to machine is going to have alot less
> in interpretation variation and need less in reinvention coding. Certainly
> something that for which the browser makers themselves could team up on
> and save themselves each some coding time. For the sake of "standard"
They won't. They're not in it for altruistic reasons. They want to
make money out of it, and do so by eliminating their opposition.
Even the W3C's own browser/editor (it's a combination job), is less
featured than IE.
> Given the above, is it then not possible and intelligently viable to add
> to any browser such an html (and perhaps others like javascript as plugin
> extensions or what ever) coding feedback system such that the end use has
> one hell of a better chance at learning good coding practices and proper
> html usage?
A browser is a useless debugging tool. However, some browsers do have
error reporting that gives details about "why." And there is no
reason why someone couldn't develop a debugging plug-in, any less than
they could develop any other plug in, providing the browser can
supply, or accept, the data necessary for the job.
Though, you need to understand the programming language (HTML,
JavaScript, or whatever else), first.
Just the same as you can't really code "properly" in C++, Pascal,
Fortran, or any other language, without studying the language. Sure,
you could work out very simple languages by examining other people's
code, but not much more. And, most importantly, you'd probably be
copying other people's bad coding techniques, without knowing that
they were bad coding techniques.
Tim
>> One thing that I have found out, with programs that "tidy" HTML
>> (re-format the source code in a "structured" way), and that they also
>> (usually) explain to you; is that sometimes that can cause the HTML to
>> render a little bit out of kilter.
>>
>> e.g. Turning:
>>
>> <table>
>> <tr><td>blah blah............</td></tr>
>> </table>
>>
>> Into:
>>
>> <table>
>> <tr>
>> <td>
>> blah blah............
>> </td>
>> </tr>
>> </table>
>>
>> Can cause the first word in that table cell to be indented by one
>> character (all those preceding blank spaces being rendered as one single
>> space).
On Thu, 06 Dec 2001 17:30:00 GMT,
Kirk Strauser <ki...@strauser.com> wrote:
> It shouldn't. That leading whitespace should be ignored.
That's debatable.
<td>this</td>
is supposed to be regarded the same as
<td>
this
</td>
But my example has more than one white space. The specs, that I've
read (granted, that I can't remember them all), only mentioned that
the line breaks (in that situation) should be ignored.
>> That can be a problem, depending on the content of the table cell
>> (particularly if it's got several lines of text in it, or it has to line
>> up vertically with something in a cell above it).
> Repeat after me: "HTML is not a layout language. HTML is not a layout
> language. HTML is not a layout language." :)
Preaching to a person who knew that from the start, and never needed
converting. ;-)
Kirk Strauser
At 2001-12-07T13:58:38Z, Tim <T...@localhost.invalid> writes:
> That's debatable.
>
> <td>this</td>
>
> is supposed to be regarded the same as
>
> <td>
> this
> </td>
>
> But my example has more than one white space. The specs, that I've read
> (granted, that I can't remember them all), only mentioned that the line
> breaks (in that situation) should be ignored.
Y'know, I *can* almost understand T. Rue's frustration with HTML. I really
can.
> > Repeat after me: "HTML is not a layout language. HTML is not a layout
> > language. HTML is not a layout language." :)
> Preaching to a person who knew that from the start, and never needed
> converting. ;-)
That became a little more apparent when I read some of your other postings.
You're absolved. ;)
--
Kirk Strauser
Tim
Kirk Strauser <ki...@strauser.com> wrote:
> Y'know, I *can* almost understand T. Rue's frustration with HTML. I
> really can.
I'd sooner program HTML than C, or just about any other high-level
programming language. There's less to have to understand, and the
definitions are there for you to read, including the exceptions
(explained, rather than left for you to discover for yourself). The
source code structure is a lot easier, too. HTML is just tarted-up
text.
{[{(anyone for a game of count the brackets?)}[}
Bogus example, with a deliberate catch.....
At least, with real programming, when you're writing binary, you know
exactly what's going to happen. You're not at the mercy of the
compiler, or the OS. There is no OS; just CPU, memory, and I/O
(putting it very simply). And bugs are your own fault.
Rudi Chiarito
> How Does one specify to the validator as to where to find the DTDs?
That's what DOCTYPE is for, using a public or system identifier, as
specified by the SGML standard, ISO8879-1986.
> Do Browsers have DTDs?
> (so as one might be able to know what a browser can handle and not.)
They're supposed to; you ought to ask their developers about that.
> Where can someone find information on making a DTD that is acceptable to
> the W3C validator?
DTDs are a mechanism defined by SGML. Either get the official standard
from ISO or a decent SGML book (#1 candidate is Goldfarb's SGML Handbook).
> Is there any validators, linters, checkers that are free and available for
> offline use as independant applications or browser plugins?
There's plenty of standalone applications. Just use Google to find
whatever suits your needs. A browser plug-in makes little sense; it's
called _browser_ (not compiler or editor) for a reason.
> Why aren't DTD called BVDs?
Because they were created before such a thing as a "browser" even existed.
> If there is going to be a commitee determination of what the standards are
> going to be defined as for a given version of the standards, why does not
> the commitee insure this by making the standard a plugin or such a work
> that all the browser makers can make use of in such a manner that insures
> they are compliant (using the very same defining work)? Even better would
This has been always possible, using DTDs and any decent SGML
parser. Most web pages out there would simply be rejected.
> be to allow a browser to be upgraded in HTML version compatabiliy by such
> a plugin?
Not possible, as DTDs only define the syntax of elements, not their
semantics. To do that, you'd need to augment a DTD with formatting
and processing directives (stuff like CSS, XSL, DSSSL).
> Given the above, is it then not possible and intelligently viable to add
> to any browser such an html (and perhaps others like javascript as plugin
> extensions or what ever) coding feedback system such that the end use has
> one hell of a better chance at learning good coding practices and proper
> html usage?
It's not a browser's task to generate HTML documents. Browsers are
already bloated enough, thanks. HTML should be created by an authoring
tool - an editor or generator, usually. The problem is that many HTML
editors have been created by people who have no clue whatsoever about
SGML. A decent SGML-compliant editor will tell you about errors or
even refuse to insert elements where they don't belong, etc. One such
fine example is the PSGML package for Emacs.
--
"Viva i cessi, sian benedetti Viva i bagni, le toilettes e i gabinetti"
Rudi Chiarito SGML/XML, user interface, i18n Amiga Inc.
ru...@amiga.com http://amiga.com/
Timothy Rue
>On Fri, 07 Dec 2001 05:55:12 GMT,
>"Timothy Rue" <thre...@earthlink.net> wrote:
>> Where does one find these DTDs?
>Read the HTML specs at the W3C site. They list addresses for them.
>On a well defined HTML document, the DTD not only says which DTD it's
>coded to adhere to, but the address to load the DTD from.
>e.g. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
> "http://www.w3.org/TR/REC-html40/loose.dtd">
>The first line specifies which DTD applies to this document, the
>second line the location for that DTD. Click on the link, and you'll
>be able to read it (it's a plain text file).
.
.
.
>Have you bothered to visit the W3C site?
>(Avoiding the temptation to just say RTFM.)
There are some fundamental flaws in your logic.
But don't feel bad, you are not alone, W3C and even ingrained into the
html standards there are failures in logic, due to those who put them
there.
It's really quite interesting that such fundamental flaws in logic are so
wide spread in the computer industry. It may even be considered that such
flaws are obvious to some in the industry. Those who apply correct logic,
maybe out of laziness to put the extra work into making illogic work, and
as such allow logical things to work that are otherwsie defined to not
work.
Timothy Rue
On 30-Nov-01 13:03:12 Rich <rta...@nbnet.nb.ca> wrote:
>The icon on the top right of the triangle of you vic sysbol. What is that?
>Some type of skil saw blade?
>"Timothy Rue" <thre...@earthlink.net> wrote in message
>news:589.734T2361T3...@earthlink.net...
>> Uses Javascript (will be making a decafe version in a day or so)
>>
>> Objective is to bring focus, though my former homepage and all links as
>> still accessible thru a non-java link.
>>
>> http://www.mindspring.com/~timrue/
Timothy Rue
On 07-Dec-01 12:30:47 Rudi Chiarito <ru...@amiga.com> wrote:
>"Timothy Rue" <thre...@earthlink.net> writes:
>> How Does one specify to the validator as to where to find the DTDs?
>That's what DOCTYPE is for, using a public or system identifier, as
>specified by the SGML standard, ISO8879-1986.
That's really only half an answer, Open for interpretation that may be
wrongly done with incomplete information that may have been obtained from
an incomplete or faulty source that got their information from a different
version of.....
Getting above this specific tag element....
From the CoffeeCup help files:
"Where can I find a list of all the current HTML tags?
The current recommendation is XHTML 1.0, which is a reformulation of HTML
4.01 as an XML 1.0 application. HTML 4.01 is an update with minor
corrections to HTML 4.0. HTML 4 extends HTML 3.2 to include support for
frames, internationalization, style sheet, advanced tables, and more. The
new markup introduced by HTML 4 is well supported by current browsers, but
much of it can be used safely in non-supporting browsers."
I tried to find some sort of date to place this document in a proper
timeline but to no avail (but it seems to be rather current.)
Well that didn't help!!! fundamental logic is no where to be found in that
paragraph.
>> Do Browsers have DTDs?
>> (so as one might be able to know what a browser can handle and not.)
>They're supposed to; you ought to ask their developers about that.
Hmmm.
>> Why aren't DTD called BVDs?
>Because they were created before such a thing as a "browser" even existed.
It was a joke. Goes like this. What do you wear close to your ass to
protect it, covered from public view to protect them from seeing it, and
can't see the whole thing yourself while using it, but you know it has
stains on it from use?
Hmmmm, do I really want to ask the developers about them? And even more
important, should I have to?
>It's not a browser's task to generate HTML documents. Browsers are
>already bloated enough, thanks. HTML should be created by an authoring
>tool - an editor or generator, usually. The problem is that many HTML
>editors have been created by people who have no clue whatsoever about
>SGML. A decent SGML-compliant editor will tell you about errors or
>even refuse to insert elements where they don't belong, etc. One such
>fine example is the PSGML package for Emacs.
Hmmm, I decided to get Netscape onto my PC box. It's 25388KB Download.
Gonna take over two hours. Getting the whole thing, don't wanna miss
anything even though I might already have some of this like Java.
Somewhere within the first half hour (got in the shower after about 10
minutes of monitoring the download) I get a windows "red circle X",
"this program (title bar shows "Explorer") has performed an illegal
operation..." telling me I need to go as far as restarting my computer.
The little Netscape download window looks to be still downloading. Didn't
think I even had Explorer running as once the download got going I shut
down explorer (cept for this download window which has none ofthe typical
markings of MS ownership).
And now you are telling me that the show source and edit buttons aren't
editors and this netscape download ain't got no editor included?
Geee, you make it sould like it was a mircale that we had text editors
that could fit on a 360k floopy.
Seems to me what is bloated is all the other stuff, between spec definers
to implimenters that interpret the specs and the documentaion/book writers
that are as well incomplete in explaining all this bloat. So much so that
the BVDs are giving everyone wedgies or crawling up ones butt.
HTML - HyperText Markup Language!!!
It is a F*ckin interpreted language, not a gawd damn institution!
But then I suppose even that is debatable, given the reality of what is...
an institution of lower-er learning, just below that waiste (sc).
UPDATE: Got Netscape up and Running (without restarting system) and now
using it to download Opera6 (w/o Java)..... Hmmmm, that Explorer error
window vanished......Guess Explorer was trying to wipe it's ass off with
Netscapes BVDs... I anti-trust anyone trying to wipe their ass with
someone elses BVDs, like they don't trust their own BVDs, why should I!
But the question is: Why Am I Downloading these different browsers?
A: Because it's faster than dealing with the institutionally insane.
Timothy Rue
>The current recommendation is XHTML 1.0, which is a reformulation of HTML
>4.01 as an XML 1.0 application. HTML 4.01 is an update with minor
>corrections to HTML 4.0. HTML 4 extends HTML 3.2 to include support for
>frames, internationalization, style sheet, advanced tables, and more. The
>new markup introduced by HTML 4 is well supported by current browsers, but
>much of it can be used safely in non-supporting browsers."
That actually reads: .... HTML 4 is not well supported...
If you don't believe me then you can dl Coffeecup and see for yourself.
Tim
On 07-Dec-01 20:08:41 Timothy Rue <thre...@earthlink.net> wrote:
>> The current recommendation is XHTML 1.0, which is a reformulation of HTML
>> 4.01 as an XML 1.0 application. HTML 4.01 is an update with minor
>> corrections to HTML 4.0. HTML 4 extends HTML 3.2 to include support for
>> frames, internationalization, style sheet, advanced tables, and more. The
>> new markup introduced by HTML 4 is well supported by current browsers, but
>> much of it can be used safely in non-supporting browsers."
On Sat, 08 Dec 2001 01:17:42 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> That actually reads: .... HTML 4 is not well supported...
>
> If you don't believe me then you can dl Coffeecup and see for yourself.
CoffeeCup isn't a particularly brilliant program to use. And no, that
ain't a comment just because you're using it. That's the reputation
it's "earnt."
The same can be said for many HTML creator programs.
Tim
"Timothy Rue" <thre...@earthlink.net> writes:
>>> How Does one specify to the validator as to where to find the DTDs?
On 07-Dec-01 12:30:47 Rudi Chiarito <ru...@amiga.com> wrote:
>> That's what DOCTYPE is for, using a public or system identifier, as
>> specified by the SGML standard, ISO8879-1986.
On Sat, 08 Dec 2001 01:08:41 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> That's really only half an answer,
No, that's the entire answer. When you submit a page to the
validator, with a correct DTD on the page, the DTD informs the
validator where the validator can find the DTD.
You don't submit a page, and also provide a link to the DTD. You
submit a page that's got the right data on it in the first place.
DTD, HTML content, the lot.
> Open for interpretation that may be wrongly done
Only by you.
The DTD isn't open for interpretation, certainly not as you're trying
to imply, it's a "specific" definition, which spells things out
explicitly.
> From the CoffeeCup help files:
>
> "Where can I find a list of all the current HTML tags?
The current "real" HTML tags can be found on the W3C site. The extra
bogus tags, invented by browser makers is another matter. You're not
very likely to get a "current" list, or a reliable list, at all. Nor
is it worth trying to use them, you'll end up with a site that only
works as expected on particular browsers, even particular versions of
browsers.
Ignoring your poor understanding of what's the current version of
HTML, read the specifications; and you'll have your answer. But it's
an evolving language. It's not a completely feasible task to have a
absolutely up to date listing in /your/ posession. You'd be forever
updating it.
As HTML has evolved commands have been added, some have been dropped,
or "depreciated" (still currently useable, but earmarked to be
dropped). A command that's been dropped is no longer part of the
current HTML specification, but that doesn't mean that browsers don't
still accept the command. conversely, there isn't any guarantee that
any browser will accept any particular command, valid, depreciated, or
dropped. And there's certainly no guarantee that a browser will deal
with a particular command in the same was as another browser (some
commands do have more precise information about how they'll render,
others have less stringent definitions).
When debugging a page, "depreciated" commands still pass as being
valid, though they'll flag as being depreciated. The usage of
commands that have been completely dropped, with show up as invalid
commands.
> The current recommendation is XHTML 1.0, which is a reformulation of HTML
> 4.01 as an XML 1.0 application. HTML 4.01 is an update with minor
> corrections to HTML 4.0. HTML 4 extends HTML 3.2 to include support for
> frames, internationalization, style sheet, advanced tables, and more. The
> new markup introduced by HTML 4 is well supported by current browsers, but
> much of it can be used safely in non-supporting browsers."
>
> I tried to find some sort of date to place this document in a proper
> timeline but to no avail (but it seems to be rather current.)
Stop reading the garbage that's included with your HTML authoring
program (whatever one you might be using), and start reading the
proper HTML specifications. Not only do they list the commands, give
examples, and explain them. They also explain the current status of
what is HTML. They have links to particular versions of HTML, and
links to whatever the current version is (i.e. a link that always goes
to the current version, taking into account when it changes). And it
would have answered *all* of the questions you've asked, so far.
Second and third hand guides are just that. Someone else's
interpretation of how it's done. Things go astray in the
interpretation.
If you're asking what's the current version of "HTML" then it's 4.01.
If you want to know what you can do with it, you read the HTML 4.01
documentation, and use it by itself. You don't read the HTML 4.01
docs for the new information, then refer back to older documentation
for stuff that it's inherited.
The current recommendation of what to use for authoring web pages, is
another matter. "XHTML" is being proposed. It's not "HTML," it's the
/next/ change to HTML. It's compatible, in a wide variety of
situations, but not all of them (though, that situation even applies
to just HTML).
But that's like the computer gaming industry. Pushing the limits,
coding for what's not around yet, to force it into wider existence.
Capitalism, if you like...
HTML 4 is the most widely currently supported version of HTML, simply
because of the sheer number of browsers that can use it. Stick to the
most currently supported language, to get the maximum compatibility
with the widest audience.
HTML 3.2 is ancient now. It's a much smaller market share. HTML 4
has been around for quite some time, that even most of the less
specced browsers have caught up to it, by now. Much of HTML 4 is the
same as HTML 3.2, so older browsers will generally cope with it okay.
>> It's not a browser's task to generate HTML documents. Browsers are
>> already bloated enough, thanks. HTML should be created by an authoring
>> tool - an editor or generator, usually. The problem is that many HTML
>> editors have been created by people who have no clue whatsoever about
>> SGML. A decent SGML-compliant editor will tell you about errors or
>> even refuse to insert elements where they don't belong, etc. One such
>> fine example is the PSGML package for Emacs.
> Hmmm, I decided to get Netscape onto my PC box.......[snip]......
>
> And now you are telling me that the show source and edit buttons aren't
> editors and this netscape download ain't got no editor included?
No-one said that. He said that it's not the browsers task (it's not
it's fundamental purpose, for those that can't understand what they've
been told).
For what it's worth. Netscape's HTML composer is quite dire. Just
like Microsoft's "FrontPage" HTML editor, it makes bad code. They're
both toys. They give people without any ability to generate HTML, the
chance to knock up a simple home page (usually one that ends up with a
huge mess of unnecessary code, and serious errors).
Taking the converse example of what Rudi said, and agreeing with him
in the process, these editors allow people to write code in a bad
manner. They don't do anything to prevent the person from writing bad
code.
They're mostly a macro type of system (even if disguised). They
bracket the text, that you're typing and what formatted in some
special way, with the HTML codes that it thinks should be used to
format that particular text, but taking no account of whereabouts
you're inserting them (i.e. into the middle of something else, that
they shouldn't have been inserted into). They don't examine your
entire desired document layout, and then generate the HTML codes
necessary to do the job (that behaviour is fairly rare).
> Seems to me what is bloated is all the other stuff, between spec definers
> to implimenters that interpret the specs and the documentaion/book writers
> that are as well incomplete in explaining all this bloat. So much so that
> the BVDs are giving everyone wedgies or crawling up ones butt.
You haven't a damn clue.
> HTML - HyperText Markup Language!!!
>
> It is a F*ckin interpreted language, not a gawd damn institution!
Actually, it is. In a sense.
It's a language, with syntax and grammar rules. It only works
properly when you use them. Same as other languages. Be they
English, Espanol, Deutsche, COBOL, or Java.
The difference between programming and spoken languages, is; as a
person we can make an educated guess about what someone meant when
they use our language poorly. But only because we've got a lot of
information stored in our brain.
On the other hand, a programming language has very little leeway for
poor use of the language. It's not open to much guess work. Making a
program have to know three different ways to do the same task *is*
bloat. Having to provide documentation to detail all of that, is
bloat. The way to avoid /that/ "bloat" is to have one definition, one
body that ratifies what goes into it.
Don't just think that the W3C just makes it all up by themselves.
They do see what others do that could be an improvement, and
incorporate it. They are open to reasonable suggestions. They nut
out what is practical. Without that sort of structured approach, we'd
have a shocking mess to have to deal with. HTML would have been
completely bastardised by Microsoft, and we'd all be paying dearly for
that in many different ways.
> But the question is: Why Am I Downloading these different browsers?
>
> A: Because it's faster than dealing with the institutionally insane.
I'd have thought you were used to that, by now.
You know exactly what I meant by that, and so does everyone else. It
was meant to be insulting.
Tim
"Timothy Rue" <thre...@earthlink.net> wrote:
>>> Where does one find these DTDs?
On 07-Dec-01 09:28:41 Tim <T...@localhost.invalid> wrote:
>> Read the HTML specs at the W3C site. They list addresses for them.
>>
>> On a well defined HTML document, the DTD not only says which DTD it's
>> coded to adhere to, but the address to load the DTD from.
>>
>> e.g. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
>> "http://www.w3.org/TR/REC-html40/loose.dtd">
>>
>> The first line specifies which DTD applies to this document, the
>> second line the location for that DTD. Click on the link, and you'll
>> be able to read it (it's a plain text file).
>>
>> ...[snip]...
>>
>>
>> Have you bothered to visit the W3C site?
>>
>> (Avoiding the temptation to just say RTFM.)
On Fri, 07 Dec 2001 18:06:38 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> There are some fundamental flaws in your logic.
What, that you might stop behaving like a pratt, when the information
is handed to you on a plate?
I don't know what the hell is wrong with you, but it's serious. It's
about bloody time that you stop blaming your own inadequacies on other
people.
The rest of us haven't had much trouble with fathoming out HTML, on
our own, but you seem to have very little grasp on the subject, even
with help. You don't pay attention to the answers, or don't have the
ability to understand them.
> It's really quite interesting that such fundamental flaws in logic
> are so wide spread in the computer industry.
Shocking, I'd say. But it's certainly true. And you're a great
example of that, yourself. As someone who suggests that they're some
sort of program author, you sure don't exhibit the necessary talents
for the job.
> Those who apply correct logic, maybe out of laziness to put the
> extra work into making illogic work, and as such allow logical
> things to work that are otherwsie defined to not work.
You *are* seriously nuts. You seem to like proving it, too.
Joona I Palaste
>>"Timothy Rue" <thre...@earthlink.net> wrote in message
>>news:<5237.738T1027T8...@earthlink.net>...
>>I was referring to how in the past you have critisized MicroSoft for
>>ignoring industry standards in order to gain market monopoly by
>>forcing the end user to use their products. I believe you call it
>>"consumer entrapment abuse"?
>>But it seems you have had a change of views and now endorse that
>>practice. As in: "If the page doesn't work in your browser, then get
>>a browser that works!", and "I used a web page creation tool (not a
>>wysiwyg) that is very popular. Popular enough to know that the w3c
>>page does not support what is more likely standard then apparently
>>what w3c wants to says is."
>>Irony can be pretty ironic sometimes, eh Tim? :)
> I don't think Tim understands irony. I think this was just a side effect of
> his refusal to accept that he is in any way wrong.
Timothy Rue is like SG. Both will rather die than admit they ever said
something which wasn't true. But SG's drivel is usually rather easy to
read and understand, unlike Timothy Rue's, which seems like the
babbling of a lunatic.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Hasta la Vista, Abie!"
- Bart Simpson
Timothy Rue
That must be why it's so popular.
Same sorta issues:
http://slashdot.org/article.pl?sid=01/12/07/1933215&mode=thread
Difference is that Linux is genuinely closer to the status of a real
institution than is meger HTML
Which I shall repeat, is an interpreted language, not an institution.
Timothy Rue
>On Fri, 07 Dec 2001 18:06:38 GMT,
>"Timothy Rue" <thre...@earthlink.net> wrote:
>
>> There are some fundamental flaws in your logic.
>What, that you might stop behaving like a pratt, when the information
>is handed to you on a plate?
>I don't know what the hell is wrong with you, but it's serious. It's
>about bloody time that you stop blaming your own inadequacies on other
>people.
is that what you think?
>The rest of us haven't had much trouble with fathoming out HTML, on
>our own, but you seem to have very little grasp on the subject, even
>with help. You don't pay attention to the answers, or don't have the
>ability to understand them.
Fathoming.....what an interesting word. how deep does that rabbit hole go?
right?
>> It's really quite interesting that such fundamental flaws in logic
>> are so wide spread in the computer industry.
>Shocking, I'd say. But it's certainly true. And you're a great
>example of that, yourself. As someone who suggests that they're some
>sort of program author, you sure don't exhibit the necessary talents
>for the job.
Actually I did use the validator yesterday, only to ultimately determine
that my page cannot be validated unless I remove the URLs as I did in fact
verify that the validator cannot tell the difference between HTML and a
URL. The Parse tree option was interesting and actually helped me to
verify the standard specification does fail fundamental logic.
It's a good thing all the browsers I've seen this web page (mine) on can
handle fundamental logic regardless of illogical specs of html. But Like I
said, probably because it's easier to do the logical thing than otherwise.
You know, given computer are based on logic.
How deep do they need to go?
>> Those who apply correct logic, maybe out of laziness to put the
>> extra work into making illogic work, and as such allow logical
>> things to work that are otherwsie defined to not work.
>You *are* seriously nuts. You seem to like proving it, too.
Let's think about this for a moment.
Timothy Rue
>"Timothy Rue" <thre...@earthlink.net> writes:
>>>> How Does one specify to the validator as to where to find the DTDs?
>On 07-Dec-01 12:30:47 Rudi Chiarito <ru...@amiga.com> wrote:
>
>>> That's what DOCTYPE is for, using a public or system identifier, as
>>> specified by the SGML standard, ISO8879-1986.
>On Sat, 08 Dec 2001 01:08:41 GMT,
>"Timothy Rue" <thre...@earthlink.net> wrote:
>
>> That's really only half an answer,
>No, that's the entire answer. When you submit a page to the
>validator, with a correct DTD on the page, the DTD informs the
>validator where the validator can find the DTD.
>You don't submit a page, and also provide a link to the DTD. You
>submit a page that's got the right data on it in the first place.
>DTD, HTML content, the lot.
Hmmm, why would I want to submit something to a validator to tell me
what I'd have to already know (unless I got lucky and guessed all the
right stuff and just wanted to know I got lucky)?
>> Open for interpretation that may be wrongly done
>Only by you.
>The DTD isn't open for interpretation, certainly not as you're trying
>to imply, it's a "specific" definition, which spells things out
>explicitly.
Wait a minute here, your trying to trick me into believeing all this extra
stuff you are saying here is encoded into the words Rudi used.
Hmmm, does it also include what Keith said about giving the URL?
Where can I get one of those sceret code rings that you are using? And
what is the codes I use to get what you said, and the code to get what
Keith said? IS there somewhere I can get all the codes?
Here you are responding to a quote question from a help file someone else
made, but as if I asked. And you think I'm nuts.
You have gone off the deep end. Maybe you should take this up with the
author of coffeecup docs....
Hmmmm.....
When weren't you?
-From: T...@localhost.invalid
-Subject: Re: New home page focus
-Date: 4 Dec 2001 11:38:34 GMT
-"Timothy Rue" <thre...@earthlink.net> wrote
->>> Uses Javascript (will be making a decafe version in a day or so)
->>>
->>> Objective is to bring focus, though my former homepage and all
->>> links as still accessible thru a non-java link.
->>>
->>> http://www.mindspring.com/~timrue/
-On 03-Dec-01 04:33:47 bulk_trap <bulk...@yahoo.com> wrote:
->> See http://validator.w3.org/
-On Tue, 04 Dec 2001 02:01:33 GMT,
-"Timothy Rue" <thre...@earthlink.net> wrote:
-> That site is crap.
->
-> I'm can't edit urls addresses (addresses external to my site)
-> in order to remove errors this site generates from the valid
-> url address in my page.
-I'd hate to imagine how anybody who can't even get their English
-syntax right, can code *anything* properly.
Still I cannot change the URLs so that the validator approves them, and
have them still actually work.
But that is a fact that is apparently to far down below your ego level.
And damn, you snipped the true story of the childish battle cry of MS
explorer.
Damn, the System is Still on and running fine.
The only thing this thread has done is to expose the fact upon which even
you apparently agree, and this is there is a hell of alot of crap comming
from the computer industry.
And that you think I'm nuts. Probably because I don't want to go get a Phd
in Html and make it my career so that I can post what is in essence some
simple html pages.
But did you even read the message on that page? Or are you just trying to
defend your sheepskin for an institution that shouldn't be.
Victor Ducedre
>Timothy Rue is like SG. Both will rather die than admit they ever said
>something which wasn't true. But SG's drivel is usually rather easy to
>read and understand, unlike Timothy Rue's, which seems like the
>babbling of a lunatic.
"Seems like" ?
--
Victor Ducedre Celebrating five years of filtering Tim Rue!
(vic...@netrover.com) I've killfiled him. Why haven't you?
John Burns
>>>"Timothy Rue" <thre...@earthlink.net> wrote in message
>>>news:<5237.738T1027T8...@earthlink.net>...
>>>> I don't know. Is that another thing I'm suppoosed to do?
>>>I was referring to how in the past you have critisized MicroSoft for
>>>ignoring industry standards in order to gain market monopoly by
>>>forcing the end user to use their products. I believe you call it
>>>"consumer entrapment abuse"?
>>>But it seems you have had a change of views and now endorse that
>>>practice. As in: "If the page doesn't work in your browser, then get
>>>a browser that works!", and "I used a web page creation tool (not a
>>>wysiwyg) that is very popular. Popular enough to know that the w3c
>>>page does not support what is more likely standard then apparently
>>>what w3c wants to says is."
>>>Irony can be pretty ironic sometimes, eh Tim? :)
>> I don't think Tim understands irony. I think this was just a side effect
>> of his refusal to accept that he is in any way wrong.
>Timothy Rue is like SG. Both will rather die than admit they ever said
>something which wasn't true. But SG's drivel is usually rather easy to
>read and understand, unlike Timothy Rue's, which seems like the
>babbling of a lunatic.
Agreed but I don't think Tim's a lunatic just poorly educated and lacking
intelligence.
John Burns
>>On Fri, 07 Dec 2001 18:06:38 GMT,
>>"Timothy Rue" <thre...@earthlink.net> wrote:
>>
>>> There are some fundamental flaws in your logic.
[SNIP]
>>What, that you might stop behaving like a pratt, when the information
>>is handed to you on a plate?
>>I don't know what the hell is wrong with you, but it's serious. It's
>>about bloody time that you stop blaming your own inadequacies on other
>>people.
>is that what you think?
>>You *are* seriously nuts. You seem to like proving it, too.
>Let's think about this for a moment.
No-one needs to think about it. Your every statements show it to be so.
John Burns
So let's examine the logic of your argument.
You created a couple of web pages.
You checked these with an HTML validation program.
The validator reported errors in your HTML code.
You don't accept these errors as being your fault.
Hmmm, very logical indeed.
Now go away, read the relevant HTML docs, fix your code, then come back and
apologise to everyone for being a total prat.
John Burns
>On 30-Nov-01 13:03:12 Rich <rta...@nbnet.nb.ca> wrote:
>>The icon on the top right of the triangle of you vic sysbol. What is that?
>>Some type of skil saw blade?
>>"Timothy Rue" <thre...@earthlink.net> wrote in message
>>news:589.734T2361T3...@earthlink.net...
>>> Uses Javascript (will be making a decafe version in a day or so)
>>>
>>> Objective is to bring focus, though my former homepage and all links as
>>> still accessible thru a non-java link.
>>>
>>> http://www.mindspring.com/~timrue/
It doesn't sound of anything but does read as bad english. You really do like to
display your lack of knowledge, don't you.
Tim
"Timothy Rue" <thre...@earthlink.net> wrote:
>>> There are some fundamental flaws in your logic.
On 08-Dec-01 07:51:12 Tim <T...@localhost.invalid> wrote:
>> What, that you might stop behaving like a pratt, when the information
>> is handed to you on a plate?
>>
>> I don't know what the hell is wrong with you, but it's serious. It's
>> about bloody time that you stop blaming your own inadequacies on other
>> people.
On Sat, 08 Dec 2001 19:10:22 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> Actually I did use the validator yesterday, only to ultimately determine
> that my page cannot be validated unless I remove the URLs as I did in fact
> verify that the validator cannot tell the difference between HTML and a
> URL. The Parse tree option was interesting and actually helped me to
> verify the standard specification does fail fundamental logic.
No. Wrong on two counts.
1. It follows logic very well. It works in progressive, logical,
procedure. Put a mistake somewhere in a page, and it has an effect on
everything following it. It's a simple syntax parser. Start with
fixing the errors at the top of the page, and re-validate; wash,
rinse, repeat, style.
2. What it was choking on, was "your" URIs, not "URIs" (how you've
written them). Because, you've unencoded ampersands, in the
addresses.
e.g. The following link also generates a similar error:
<a href="http://www.example.com/images?test&word">test</a>
But this URI does work, and does validate properly:
<a href="http://www.example.com/images?test&word">test</a>
And guess, what? Taking one of your JavaScript links, and encoding
all the "&" to "&" means that it now validates.
The story is, read the specs to find out what you should be doing,
test alternatives, post queries, decently, and wait for someone who's
familiar with the problem to post a reply. Or, learn more about what
you're doing, and find the answer for yourself. This situation was
covered pretty early in the specs, too.
And, now the answer: (for those too lazy to educate themselves)
-------------------
As soon as the validator's parser (and any other parser may behave the
same way) encountered the characters &images in your URI, it
returned an error mesage of: Error: unknown entity "images"
In HTML, various things (entities) are represented by a code, opening
with an ampersand, then a keyword or code, closed with a semi-colon.
As soon as a parser encounters an ampersand symbol, it treats it and
the following characters, as a whole. Supposedly meaning something.
So, to use certain characters, you have to use equivelents.
To be able to use the ampersand as an ampersand, it has to be
represented by the entitity of &
There's some other common ones, too:
The < less-than symbol has to be written as <
The > greater-than symbol as >
It's also recommended to use " for the " quotation marks,
although that one tends to be less of a problem.
Those ones should be encoded, because they're special characters
relied upon for the coding of HTML.
Other special characters will probably need encoding, because they're
not common to all character sets.
e.g. ® to display the R surrounded by a circle, as used to
indicate a registered trademark.
That particular symbol doesn't exist in many character sets, and
exists in different places in different sets. That's yet another
reason why the character set used in a document ought to be declared
(various browsers can either switch over to use the same character
set, or transcode between yours and theirs, if they know which ones
are being used).
Any browser that displays & < or > when used directly, is broken.
Relying on a broken application to validate your HTML is in error. As
soon as someone tries to view your code on a browser that isn't
broken, it's likely to not render it.
Any HTML generator that doesn't encode characters, when it should be,
is broken, too. So much for how good CoffeeCup is. Or maybe it's
your configuration of it (look for an automatic encoding of
characters, option).
You've had plenty of time to discover this, by yourself, but you still
haven't, because you're not interested in "learning."
I had better things to do, than do this for you, and only briefly
looked at all the errors from your page. I made a quick guess that it
may be your JavaScript. Which any other person would then have made a
quick test page, and came back and said that the problem lay elsewhere
(without being an insufferable twit about it). And you'd have had the
answer fairly promptly.
But I've got sick of reading you go on and on about it, and went back
and had a second look.
Moral of the story; don't be a dickhead, Tim Rue.
Yet again, the problem was all yours, and now you've just had the
proof, again.
> It's a good thing all the browsers I've seen this web page (mine) on can
> handle fundamental logic regardless of illogical specs of html. But Like I
> said, probably because it's easier to do the logical thing than otherwise.
> You know, given computer are based on logic.
You obviously don't know the meaning of the word logic, or logical.
Tim
>> CoffeeCup isn't a particularly brilliant program to use. And no, that
>> ain't a comment just because you're using it. That's the reputation
>> it's "earnt."
>>
>> The same can be said for many HTML creator programs.
On Sat, 08 Dec 2001 17:46:18 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> That must be why it's so popular.
Windows is also "popular" (has a large population), but doesn't make
it a good thing, though. Lots of people make badly coded web sites,
and doesn't make it a good thing, either. Being "popular" isn't a
really good indicator. Lot of programs might be downloaded by lots of
people, that doesn't mean that the program's good, so web stats aren't
any reliable indicator, also.
> Same sorta issues:
> http://slashdot.org/article.pl?sid=01/12/07/1933215&mode=thread
>
> Difference is that Linux is genuinely closer to the status of a real
> institution than is meger HTML
>
> Which I shall repeat, is an interpreted language, not an institution.
I don't know why you've brought in something unrelated (Linux) into
the arena, other than your usual ploy.
If you can apply the word "institution" to something that's well
established, as opposed to a building or organisation, HTML can make a
similar claim to being an institution as Linux can.
Most "languages" can lay claim to being an institution.
Tim
>>>>> How Does one specify to the validator as to where to find the DTDs?
On 07-Dec-01 12:30:47 Rudi Chiarito <ru...@amiga.com> wrote:
>>>> That's what DOCTYPE is for, using a public or system identifier, as
>>>> specified by the SGML standard, ISO8879-1986.
On Sat, 08 Dec 2001 01:08:41 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
>>> That's really only half an answer,
On 08-Dec-01 07:51:17 Tim <T...@localhost.invalid> wrote:
>> No, that's the entire answer. When you submit a page to the
>> validator, with a correct DTD on the page, the DTD informs the
>> validator where the validator can find the DTD.
>>
>> You don't submit a page, and also provide a link to the DTD. You
>> submit a page that's got the right data on it in the first place.
>> DTD, HTML content, the lot.
On Sat, 08 Dec 2001 19:10:28 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> Hmmm, why would I want to submit something to a validator to tell me
> what I'd have to already know (unless I got lucky and guessed all the
> right stuff and just wanted to know I got lucky)?
A lot of people use the validator as yet another check that they're
code is working (check it on as many different things as possible,
validators, different browsers, etc.).
Do you really need an explanation of why someone would use the
validator, or are you just ranting for the sake of it?
>>> Open for interpretation that may be wrongly done
>> Only by you.
>>
>> The DTD isn't open for interpretation, certainly not as you're trying
>> to imply, it's a "specific" definition, which spells things out
>> explicitly.
> Wait a minute here, your trying to trick me into believeing all this extra
> stuff you are saying here is encoded into the words Rudi used.
You really are stupid, aren't you?
You asked how do you tell the validator where to find a DTD, and you
were told that DOCTYPE does that, and even got a follow-up answer,
when you still didn't understand (that the DOCTYPE says which DTD is
to be used, and can even include the address of where to find it).
Everyone else could follow what was said, why couldn't you? It didn't
need any decoding.
>>> From the CoffeeCup help files:
>>>
>>> "Where can I find a list of all the current HTML tags?
>> The current "real" HTML tags can be found on the W3C site....[snip]...
> Here you are responding to a quote question from a help file someone else
> made, but as if I asked. And you think I'm nuts.
Yes, and so do most people. You behave like a fool. You have only
yourself to blame for that.
This is how public forums work. People post questions and answers,
and various people respond.
Most people understand that. You've been around for long enough,
haven't you learnt that yet?
I'll leave that block quoted intact, it's better that way.
The one off the deep end has always been you.
You posted something, clearly showing that had no understanding of the
situation, and had the situation explained to you. Think yourself
lucky that anybody bothers to reply to your postings.
>>> But the question is: Why Am I Downloading these different browsers?
>>>
>>> A: Because it's faster than dealing with the institutionally insane.
>> I'd have thought you were used to that, by now.
>>
>> You know exactly what I meant by that, and so does everyone else. It
>> was meant to be insulting.
> When weren't you?
By and large, I avoid it, but in your case I'm happy enough not to.
My usual rule is to treat people in the same manner as they treat you
or others, and deserve.
You are an ignorant and annoying twerp. You carry on like a spoilt
brat, and then try and behave all doe-eyed when someone treats you in
the manner that you deserve.
Pot calling the kettle black, is a term that springs to mind. Your
favourite games when refusing to acknowledge that you were wrong, are
to throw the conversation out of kilter, bring in nonsensical matters,
misquote, and insult people.
My replies have been "suitably" scathing (when it was appropriate).
If you'd just learn to shut up, and find out about something, before
shooting off and letting the whole world know for certain that you're
a fool, you wouldn't get treated this way.
You don't just ask for clarification, when you haven't understood
something, you go straight into attack mode. Expect a reply in kind.
> And that you think I'm nuts. Probably because I don't want to go get a Phd
> in Html and make it my career so that I can post what is in essence some
> simple html pages.
Everyone thinks you're nuts, because you act like you're nuts. That's
all *entirely* your own doing.
a. You don't need some degree in HTML to write HTML, but a bit of
common sense, and reading instructions would help a lot.
b. If you were trying to make simple pages, it would have worked, but
you're not coding "simple" pages. You're trying to code things beyond
your own understanding. Know your own limits.
c. If you'd simply posted that you had a problem validating your
pages, instead of venting your frustration at the validator, you might
have actually got some help. You'd also have to not have a past
history of behaving that way too.
Shutup, and just read the news groups for a while. Read the other
messages. See how other people behave. See how other people say that
they're having a problem with something, without being a jerk. And
see how they get help.
Joona I Palaste
your HTML code does not validate under a standard HTML validator, that
means the validator is buggy? Do you think you are some Grand Deity who
is always infallible? If so, you're the biggest doofus I have ever seen.
Grow up or leave this newsgroup, please.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I am not very happy acting pleased whenever prominent scientists overmagnify
intellectual enlightenment."
- Anon
Keith Blakemore-Noble
wrote something about "Re: New home page focus"...
> Timothy Rue, you are an arrogant idiot. Do you really believe that if
> your HTML code does not validate under a standard HTML validator,
> that means the validator is buggy? Do you think you are some Grand
> Deity who is always infallible?
You forget, Joona, that Rue has previously, in this newsgroup, declared
himself to be Christ.
I think that answers your question!
Joona I Palaste
And in a thread about a dream _I_ had, too. This caused William T.
Maddock to sprout message after message of Christian propaganda, to
which I have noticed you respond with anti-Christian propaganda...
Geez guys! It was only a simple dream! Nothing to get worked up about!
Keith Blakemore-Noble
wrote something about "Re: New home page focus"...
> Keith Blakemore-Noble <Ke...@blakemore-noble.net> scribbled the
> following:
> > Hi there Joona I Palaste, on or around 9 Dec 2001 17:15:37 GMT you
> > wrote something about "Re: New home page focus"...
> >> Timothy Rue, you are an arrogant idiot. Do you really believe that
> >> if your HTML code does not validate under a standard HTML
> >> validator, that means the validator is buggy? Do you think you are
> >> some Grand Deity who is always infallible?
>
> > You forget, Joona, that Rue has previously, in this newsgroup,
> > declared himself to be Christ.
>
> > I think that answers your question!
>
> And in a thread about a dream _I_ had, too.
Oh, he has made the claim that he is Christ in the past too, waaaay
before your dream, Joona!
Timothy Rue
>Hi there Joona I Palaste, on or around 9 Dec 2001 17:15:37 GMT you
>wrote something about "Re: New home page focus"...
>> Timothy Rue, you are an arrogant idiot. Do you really believe that if
>> your HTML code does not validate under a standard HTML validator,
>> that means the validator is buggy? Do you think you are some Grand
>> Deity who is always infallible?
So Joona, you think it's too much for me to expect such a validator to
know the difference between HTML and URLs. Between what is the markup
language and what it is marking up?
>You forget, Joona, that Rue has previously, in this newsgroup, declared
>himself to be Christ.
>I think that answers your question!
There is plenty of proof of claims that I did such a thing, but you'll be
hard pressed to find such a claim being made by me. I have however said
that the saviour is not comming because he does not want to take the self
esteem away from the people who are perfectly capable of "doing things on
earth, as they are done in heaven". For that is the way things are done in
heaven, by everyone, and also the only way the saviour can feel like part
of the family rather than an outcast slave taking care of a bunch of
spoiled self-esteem-less brats.
Let me suggest that such claims about me are suggestive of the desires of
those who make them.
Timothy Rue
http://www.webopedia.com/TERM/U/URI.html
*Uniform Resource Identifier*
Key work being *Uniform*
>e.g. The following link also generates a similar error:
> <a href="http://www.example.com/images?test&word">test</a>
> But this URI does work, and does validate properly:
> <a href="http://www.example.com/images?test&word">test</a>
>And guess, what? Taking one of your JavaScript links, and encoding
>all the "&" to "&" means that it now validates.
Javascript is almost (more in a moment) completely irrelavant here.
As you can run the validator on the non-javascript version and get
exactly the same result.
However, and as you can probably see in your newsreader (certainly in
thor), the modified version you created above.....well, it won't get you
there.
Not only does my version of the URL work here, but in all the browsers
I've tried and even in the two web page editors I've mentioned.
>The story is, read the specs to find out what you should be doing,
>test alternatives, post queries, decently, and wait for someone who's
>familiar with the problem to post a reply. Or, learn more about what
>you're doing, and find the answer for yourself. This situation was
>covered pretty early in the specs, too.
>And, now the answer: (for those too lazy to educate themselves)
>-------------------
>As soon as the validator's parser (and any other parser may behave the
>same way) encountered the characters &images in your URI, it
>returned an error mesage of: Error: unknown entity "images"
In TidyHTML it says unescaped & or unknown entity &images.
>In HTML, various things (entities) are represented by a code, opening
>with an ampersand, then a keyword or code, closed with a semi-colon.
>As soon as a parser encounters an ampersand symbol, it treats it and
>the following characters, as a whole. Supposedly meaning something.
>So, to use certain characters, you have to use equivelents.
>To be able to use the ampersand as an ampersand, it has to be
>represented by the entitity of &
Except for when it is used within a URL apparently.
Which would be logical as the real life parsers only need to identify the
beginning and end of a URL (the matching quotes) as it simple sends on
what all it finds inbetween them. It's not the browser parsers job to
determine if the URL is a valid one, but rather it's ultimately the
external network to determine if the URL can be reached "at this time".
And if there is additional layer(s) between then, such as javascript, then
it's still the html parsers job to pass the URL to that layer, for that
layer to then pass on.
>There's some other common ones, too:
>The < less-than symbol has to be written as <
>The > greater-than symbol as >
>It's also recommended to use " for the " quotation marks,
>although that one tends to be less of a problem.
Hey, there is one URL that even on the Javascript page I don't have it
enclosed in a javascript function.
http://www.law.duke.edu/pd/papers/Coase's_Penguin.pdf
And the reason I don't is because of the single quote mark -> ' <-
(apostrophe) used in the URL. I tried numerious things from a special
character list but to no avail (that is of getting the URL to work). If
there is one, I can't seem to find it. Odd because I know that for using
quotes within quotes, the way you generally do it is with these two
different ways of quoting ("---" or '--', so "something 'quoted' inside
quotes") and as such this is a rather obvious character to need to have
an excape sequence to use.
The reason removing it from javascript works is because of reducing the
quoting level to below maximum (max being just two levels), as javascript
results in max.
TidyHTML removes the apostrophe without any warning or other notice to the
user, to let them know it has broken a link or even that TidyHTML thought
there was a problem. Removes it without saying anything.
Who knows, maybe that apostrophe is the reason why that paper didn't make
it into the "all papers" collection?
>Those ones should be encoded, because they're special characters
>relied upon for the coding of HTML.
>Other special characters will probably need encoding, because they're
>not common to all character sets.
>e.g. ® to display the R surrounded by a circle, as used to
>indicate a registered trademark.
>That particular symbol doesn't exist in many character sets, and
>exists in different places in different sets. That's yet another
>reason why the character set used in a document ought to be declared
>(various browsers can either switch over to use the same character
>set, or transcode between yours and theirs, if they know which ones
>are being used).
>Any browser that displays & < or > when used directly, is broken.
>Relying on a broken application to validate your HTML is in error. As
>soon as someone tries to view your code on a browser that isn't
>broken, it's likely to not render it.
>Any HTML generator that doesn't encode characters, when it should be,
>is broken, too. So much for how good CoffeeCup is. Or maybe it's
>your configuration of it (look for an automatic encoding of
>characters, option).
That explains why 1stPage doesn't do such conversions?
And I can't seem to find any such option.
>You've had plenty of time to discover this, by yourself, but you still
>haven't, because you're not interested in "learning."
How much time do I have Tim? It's a simple page Tim!
>I had better things to do, than do this for you, and only briefly
>looked at all the errors from your page. I made a quick guess that it
>may be your JavaScript. Which any other person would then have made a
>quick test page, and came back and said that the problem lay elsewhere
>(without being an insufferable twit about it). And you'd have had the
>answer fairly promptly.
>But I've got sick of reading you go on and on about it, and went back
>and had a second look.
>Moral of the story; don't be a dickhead, Tim Rue.
>Yet again, the problem was all yours, and now you've just had the
>proof, again.
>> It's a good thing all the browsers I've seen this web page (mine) on can
>> handle fundamental logic regardless of illogical specs of html. But Like I
>> said, probably because it's easier to do the logical thing than otherwise.
>> You know, given computer are based on logic.
>You obviously don't know the meaning of the word logic, or logical.
You want me to believe that *Uniform* doesn't mean Uniform but something
else?
Uniform - *1.* Identical, as from example to example, place to place, or
moment to moment *2.* without variations in detail *3.* consistant;
unvarying
Perhaps the industry really just misspelled it from:
unform (unformed) - *1.* not definately shaped; shapeless or formless
*2.* undeveloped; crude *3.* not formed; not created
Or at least that's the most logical conclusion I can come to, for it
certainly seem the W3C have left out "I" the end user.
And considering the only place the URLs seem to be having a problem is
in the stuff from the W3C (validator and tidyHTML) it is apparently not me
who is the "Dick Head" but rather you and the W3C. And that sounds nasty.
Timothy Rue
Show me.
Or is resorting to name calling is evidence of having no valid arguement.
Tim
"Timothy Rue" <thre...@earthlink.net> wrote:
>>> Actually I did use the validator yesterday, only to ultimately determine
>>> that my page cannot be validated unless I remove the URLs as I did in fact
>>> verify that the validator cannot tell the difference between HTML and a
>>> URL.
On 09-Dec-01 09:55:42 Tim <T...@localhost.invalid> wrote:
>> What it was choking on, was "your" URIs, not "URIs" (how you've
>> written them). Because, you've unencoded ampersands, in the
>> addresses.
On Sun, 09 Dec 2001 23:01:02 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> http://www.webopedia.com/TERM/U/URI.html
>
> *Uniform Resource Identifier*
>
> Key work being *Uniform*
URI / URL, so what. I'm not getting into that debate. We're both
talking about the same thing.
>>e.g. The following link also generates a similar error:
>>
>> <a href="http://www.example.com/images?test&word">test</a>
>>
>> But this URI does work, and does validate properly:
>>
>> <a href="http://www.example.com/images?test&word">test</a>
>>
>> And guess, what? Taking one of your JavaScript links, and encoding
>> all the "&" to "&" means that it now validates.
> Javascript is almost (more in a moment) completely irrelavant here.
> As you can run the validator on the non-javascript version and get
> exactly the same result.
Yes, I know, but I was making the comment about (many of) the
addresses you've used links you've used JavaScript with. If I
remember correctly, you've got some plain links too. They were
composed in a different manner, and didn't have a problem.
I took one of your JavaScript links, which happened to have &image
somewhere in the address, and ran tests on it.
> However, and as you can probably see in your newsreader (certainly in
> thor), the modified version you created above.....well, it won't get you
> there.
Actually, they did work. Not those particular www.example.com
examples, because they're faked, but the scheme of encoding the
ampersands in your links (they validate, and also work as links in
browsers). I did actually test it (on three different browsers).
I modified your web page, in that manner (changed the ampersands in
the addresses to &), and tested that too. And, if this newsgroup
allowed attachments, I'd have posted it here (embedding it in the
message would have probably mangled it). The end result of re-coding
your page, was just two errors:
1. The color attribute in the hr tag, which can be safely ignored.
2. A background in a table, which can also be ignored.
They're both insignificant, and will work in some browsers, and do
nothing in any others, but shouldn't cause anything to "break."
Getting back to your URI comment. To be particular, looking at an
address, like the above samples, and some of the ones used in your
site. There's three parts to them:
e.g. http://www.example.com/images?test&word
1111 2222222222222222222222 333333333
1. The protocol.
2. The address (URI, URL, whatever).
3. Parameters.
Special symbols (e.g. the ampersand), aren't allowed in "addresses,"
but they can be encoded, and passed as part of arguments to the
server, where it should decode and act upon them.
> Not only does my version of the URL work here, but in all the browsers
> I've tried and even in the two web page editors I've mentioned.
As has been said many times. Browsers are buggy, and badly coded
devices, they are no indication of what is correct.
>> As soon as the validator's parser (and any other parser may behave the
>> same way) encountered the characters &images in your URI, it
>> returned an error mesage of: Error: unknown entity "images"
> In TidyHTML it says unescaped & or unknown entity &images.
Same thing, virtually.
It's found an un-escaped &. The ampersand hasn't been encoded to be
used (seen) as an ampersand, so it thinks it's the beginning of an
entity code. And, on top of that, it thinks you're trying to use some
entity called &images; (even though the closing semi-colon is
missing), and rightly complains that &images; isn't a real entity.
>> In HTML, various things (entities) are represented by a code, opening
>> with an ampersand, then a keyword or code, closed with a semi-colon.
>>
>> As soon as a parser encounters an ampersand symbol, it treats it and
>> the following characters, as a whole. Supposedly meaning something.
>>
>> So, to use certain characters, you have to use equivelents.
>>
>> To be able to use the ampersand as an ampersand, it has to be
>> represented by the entitity of &
> Except for when it is used within a URL apparently.
I've seen debate about this, elsewhere. The consensus was, that on
the browsers it didn't work on, it's the browsers at fault. Anything
on/in the page (HTML "file"), should be encoded.
When clicking on the link, the browser should send the data in an
appropriate manner, to the server.
> Which would be logical as the real life parsers only need to identify the
> beginning and end of a URL (the matching quotes) as it simple sends on
> what all it finds inbetween them. It's not the browser parsers job to
> determine if the URL is a valid one, but rather it's ultimately the
> external network to determine if the URL can be reached "at this time".
> And if there is additional layer(s) between then, such as javascript, then
> it's still the html parsers job to pass the URL to that layer, for that
> layer to then pass on.
The problem is, that browser (or whatever else), *does* have to parse
the contents between the quotes of an URI. Because, sometimes
addresses have to use characters that aren't directly useable, or
might fail due to character set problems.
Your own links, using ampersands are one example. Other examples
would be paths and filenames (after the domain), using foreign
characters.
How would the browser know whether you're using & directly, or are
using an &entity-code; equivalent? It can't, not without 100%
certainty. Ampersands should be encoded, to be certain.
>> It's also recommended to use " for the " quotation marks,
>> although that one tends to be less of a problem.
> Hey, there is one URL that even on the Javascript page I don't have it
> enclosed in a javascript function.
>
> http://www.law.duke.edu/pd/papers/Coase's_Penguin.pdf
>
> And the reason I don't is because of the single quote mark -> ' <-
> (apostrophe) used in the URL. I tried numerious things from a special
> character list but to no avail (that is of getting the URL to work). If
> there is one, I can't seem to find it. Odd because I know that for using
> quotes within quotes, the way you generally do it is with these two
> different ways of quoting ("---" or '--', so "something 'quoted' inside
> quotes") and as such this is a rather obvious character to need to have
> an excape sequence to use.
Generally speaking, any HTML attribute that works in this manner:
attribute="value"
Uses quotation marks ("). But it's permissible to use single marks,
if needed (because the value needed to use quotes).
e.g. <meta name="description" content='Help for "HTML" authoring'>
Apostrophes, and back ticks (the mirror image of an apostrophes), can
be used directly (on the page) without encoding. Quotes often can,
too, but it's a recommendation to encode them (outside of attributes).
e.g. Directly: <a href="./page.html">a link</a>
Encoded: <p>"CoffeeCup" is a program that....
The recommendation doesn't seem to be as strong, though, as the
instruction that ampersands, less-thans, and greater-thans, should be
encoded. Possibly, because they're not used as the *start* of a
command sequence, so are less prone to accidental misinterpretation.
You encode things that you don't want to get parsed as being something
else.
>> Any HTML generator that doesn't encode characters, when it should be,
>> is broken, too. So much for how good CoffeeCup is. Or maybe it's
>> your configuration of it (look for an automatic encoding of
>> characters, option).
> That explains why 1stPage doesn't do such conversions?
> And I can't seem to find any such option.
The difficulty lies in determining when it's appropriate to convert.
Various HTML editors, although being a WYSIWYG editor, still allow you
to type HTML commands directly into the editor (so you can do things
that it doesn't know about). You wouldn't want them to be encoded.
>> You've had plenty of time to discover this, by yourself, but you still
>> haven't, because you're not interested in "learning."
> How much time do I have Tim? It's a simple page Tim!
In between bothering to argue about this at length.
> You want me to believe that *Uniform* doesn't mean Uniform but something
> else?
It means a common addressing scheme. How you give it the information
doesn't have to be common.
All systems, Windows, Mac, Linux, Amiga, are to use addresses in the
same manner: They all use two slashes where they should, they all use
forward slashes, and other things, that means they all specify the
address in the same style (rather than they're own).
At: http://www.w3.org/TR/REC-html40/intro/intro.html#h-2.1.1
------- begin paste ------
2.1.1 Introduction to URIs
Every resource available on the Web -- HTML document, image, video
clip, program, etc. -- has an address that may be encoded by a
Universal Resource Identifier, or "URI".
URIs typically consist of three pieces:
The naming scheme of the mechanism used to access the resource.
The name of the machine hosting the resource.
The name of the resource itself, given as a path.
Consider the URI that designates the current HTML specification:
http://www.w3.org/TR/REC-html40/
This URI may be read as follows: There is a document available via the
HTTP protocol (see [RFC2068]), residing on the machine www.w3.org,
accessible via the path "/TR/REC-html4/". Other schemes you may see in
HTML documents include "mailto" for email and "ftp" for FTP.
Here is another example of a URI. This one refers to a user's mailbox:
...this is text...
For all comments, please send email to
<A href="mailto:j...@someplace.com">Joe Cool</A>.
Note. Most readers may be familiar with the term "URL" and not the
term "URI". URLs form a subset of the more general URI naming scheme.
------- end paste ------
Just above:
http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.2.3
There's mention about how various characters can be represented by
equivalent codes.
e.g. double-quotes " by "' or "
single quotes ' by '
And, just below that address, a bit more of a brief introduction to
3.2.3 Character references
Character references are numeric or symbolic names for characters that
may be included in an HTML document. They are useful for referring to
rarely used characters, or those that authoring tools make it
difficult or impossible to enter. You will see character references
throughout this document; they begin with a "&" sign and end with a
semi-colon (;).
------- end paste ------
Which has a link just below to more details about the equivalent codes
for certain characters.
Which gives the background information about what I'm about to say.
That a URI can be specified directly.
Or, using the equivalent character codes, and it's still a URI, it's
still specifying the same thing.
e.g. In this /fashion/: http://&xx;&xx;&xx; and so on, where each
letter in the address was specified using a numerical code for it (I
can't be stuffed working what number is used for the letter "w," but
you should be able to visualise the approach being used).
There's also another way to specify characters, than the &xx; manner,
with a %xx style, instead (you've probably seen blank spaces encoded
as %20 in some links).
Even when typed as www.example.com you're not really sending the
letters and characters w w w . e x (etc., etc.), you're sending codes
for each of them. This is just a different code.
The addressing scheme is still the same (uniform), just the characters
codes used to specify the address are different.
Timothy Rue
>On Sat, 08 Dec 2001 19:10:22 GMT,
>"Timothy Rue" <thre...@earthlink.net> wrote:
>
>>>> Actually I did use the validator yesterday, only to ultimately determine
>>>> that my page cannot be validated unless I remove the URLs as I did in
>>>> fact verify that the validator cannot tell the difference between HTML
>>>> and a URL.
>On 09-Dec-01 09:55:42 Tim <T...@localhost.invalid> wrote:
>
>>> What it was choking on, was "your" URIs, not "URIs" (how you've
>>> written them). Because, you've unencoded ampersands, in the
>>> addresses.
>On Sun, 09 Dec 2001 23:01:02 GMT,
>"Timothy Rue" <thre...@earthlink.net> wrote:
>
>> http://www.webopedia.com/TERM/U/URI.html
>>
>> *Uniform Resource Identifier*
>>
>> Key work being *Uniform*
>URI / URL, so what. I'm not getting into that debate. We're both
>talking about the same thing.
You think I presented that for debate?
Actually I was verifying and clairifying what we were talking about and
pointing out the word and work of *Uniform*
but this you seem to have skipped over, sidetracked from, ducked out of or
whatever you want not to call it.
and here is what you clipped at the tail end, the conclusion of my post.
-You want me to believe that *Uniform* doesn't mean Uniform but something
-else?
-Uniform - *1.* Identical, as from example to example, place to place, or
-moment to moment *2.* without variations in detail *3.* consistant;
-unvarying
-Perhaps the industry really just misspelled it from:
-unform (unformed) - *1.* not definately shaped; shapeless or formless
-*2.* undeveloped; crude *3.* not formed; not created
-Or at least that's the most logical conclusion I can come to, for it
-certainly seem the W3C have left out "I" the end user.
-And considering the only place the URLs seem to be having a problem is
-in the stuff from the W3C (validator and tidyHTML)......
But detouring from the real issues is something the professionals in the
computer industry seem to be good at.
Such skill in the industry is describe metaphorically in terms of the
movie the matrix, as the story Morpheus tells Neo about having seen many
fight the agents and lose, that no one has yet beaten them and that anyone
can become one of them agents.
But in real life what you have done above is nothing more than what there
are plenty of examples to see in the industry skirting around real issues
with babel, often getting the innocent ignorant to follow.
Perhaps you'd just like to point us all to the double speak dictionary, so
that we all can use it? But then if you did that, it wouldn't be of any
use to you.
But I must ask, what is your definition of *uniform*? Black suit and tie,
with white shirt, polished shoes, sunglasses and redish brown hair?
John Burns
>wrote:
>>Hi there Joona I Palaste, on or around 9 Dec 2001 18:06:53 GMT you
>>wrote something about "Re: New home page focus"...
>>> Keith Blakemore-Noble <Ke...@blakemore-noble.net> scribbled the
>>> following:
>>> > Hi there Joona I Palaste, on or around 9 Dec 2001 17:15:37 GMT you
>>> > wrote something about "Re: New home page focus"...
>>> >> Timothy Rue, you are an arrogant idiot. Do you really believe that
>>> >> if your HTML code does not validate under a standard HTML
>>> >> validator, that means the validator is buggy? Do you think you are
>>> >> some Grand Deity who is always infallible?
>>>
>>> > You forget, Joona, that Rue has previously, in this newsgroup,
>>> > declared himself to be Christ.
>>>
>>> > I think that answers your question!
>>>
>>> And in a thread about a dream _I_ had, too.
>>Oh, he has made the claim that he is Christ in the past too, waaaay
>>before your dream, Joona!
>Show me.
>Or is resorting to name calling is evidence of having no valid arguement.
ROTFLMAO
Probably let's look at one of your own examples.
A few weeks back you called me a liar when I mentioned that you had claimed
that aliens were living on earth. I re-posted the relevant posts and asked
you for an apology for calling me a liar and your proof to substantiate the
claim. Unsurprisingly, you left the thread after this without replying.
You are a sad little man whose ego far exceeds his abilities. I just wish
that instead of surfing the net and posting to newsgroups you would try and
get some real education. Knowledge itself is not dangerous only that little
bit which you have.
Tim
"Timothy Rue" <thre...@earthlink.net> wrote:
> detouring from the real issues is something the professionals in the
> computer industry seem to be good at.
It doesn't matter how many times you detour from the issue, nobody is
going to think that you're a professional in the computing industry.
> Perhaps you'd just like to point us all to the double speak dictionary, so
> that we all can use it? But then if you did that, it wouldn't be of any
> use to you.
Doublespeak would appear to be your native tongue. Ordinary English
certainly isn't.
> But I must ask, what is your definition of *uniform*? Black suit and tie,
> with white shirt, polished shoes, sunglasses and redish brown hair?
Idiot....
Timothy Rue
>Idiot....
Yeah I especially like your use of double speak here:
---
On 09-Dec-01 09:55:42 Tim <T...@localhost.invalid> wrote:
[snip]
>On Sun, 09 Dec 2001 23:01:02 GMT,
>"Timothy Rue" <thre...@earthlink.net> wrote:
[snip]
>> Which would be logical as the real life parsers only need to identify the
>> beginning and end of a URL (the matching quotes) as it simple sends on
>> what all it finds inbetween them. It's not the browser parsers job to
>> determine if the URL is a valid one, but rather it's ultimately the
>> external network to determine if the URL can be reached "at this time".
>> And if there is additional layer(s) between then, such as javascript, then
>> it's still the html parsers job to pass the URL to that layer, for that
>> layer to then pass on.
>The problem is, that browser (or whatever else), *does* have to parse
>the contents between the quotes of an URI. Because, sometimes
>addresses have to use characters that aren't directly useable, or
>might fail due to character set problems.
[snip]
---
Actually it's probably more an example of a non-seqitur. <shrug>
Tim
"Timothy Rue" <thre...@earthlink.net> wrote:
> Yeah I especially like your use of double speak here:
On Sun, 09 Dec 2001 23:01:02 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote about his usual
misunderstandings of things:
>>> Which would be logical as the real life parsers only need to identify the
>>> beginning and end of a URL (the matching quotes) as it simple sends on
>>> what all it finds inbetween them. It's not the browser parsers job to
>>> determine if the URL is a valid one, but rather it's ultimately the
>>> external network to determine if the URL can be reached "at this time".
>>> And if there is additional layer(s) between then, such as javascript, then
>>> it's still the html parsers job to pass the URL to that layer, for that
>>> layer to then pass on.
On 09-Dec-01 09:55:42, Tim <T...@localhost.invalid> wrote some
corrections to Tim Rue's misunderstandings, in reply:
>> The problem is, that browser (or whatever else), *does* have to parse
>> the contents between the quotes of an URI. Because, sometimes
>> addresses have to use characters that aren't directly useable, or
>> might fail due to character set problems.
> Actually it's probably more an example of a non-seqitur. <shrug>
The person speaking doublespeak, or gibberish, is you. You have a
weak grasp on the normal use of the English language, you rarely seem
to be able to use it normally, either in reading or writing it. And
you certainly struggle with proper technical use of the language.
You have unrealistic expectations of your own abilities, and the
internets; poor comprehension of the task at hand, and the
explanations given to you about them.
When faced with your own inabilities, you try to blame everyone else
but yourself, and try to hide it by going off on wild tangents.
Timothy Rue
Claims nothing but claims. Just because you can type a sequence of
characters and make a claim, doesn't mean the claim is based on reality.
So I'm a bad speller and my mind works quicker than I can type, sometime
resultung in missspellings, whole words droped and even in rethinking how
I say something sometimes forgetting to remove a word. Al that says is
that I never learned to type, as many internet users are like me in being
a few finger typest.
But I would like to know why you think a browser needs to parse a url
in order to find something that browser doesn't like about it, while the
internet that sent it and has to deal with it, has no problem with it.
The only thing I see as being consistant is your desire to find a problem
where there is non. As it seems the W3C validator and tidyHTML also does
this looking for a problem in the concept of "Uniform"
The solution direction of the W3C regarding the FONT problem is not a
solution at all. For the problem is stated to be one of incompatability
across browsers in dealing with variations in the <FONT> attributes. A
problem that was started by MicroSoft adding in their own attributes.
The proposed CSS doesn't solve that problem but instead makes anything
that uses <FONT> to break in a system (browser) that no longer uses
<FONT>, while creating CSS problems with anything that doesn't support
CSS.
Kinda like letting the terrorist win, via creating bigger problems in
counter measures.
Instead they should have incorporated the CSS concepts into <FONT>
attributes so that "best possible" is achieved, rather than this, that
or the other hard choice. The catagory that <FONT> is placed under in the
specification recomendation of the W3C is also wrong.
And it's clear that the specification was wrote under the mindset of theory
rather than the logic of practical application.
"Inline" and "block" concepts fail the values of streamlined "stack" usage.
Where the rule is simple, Use font attributes on top of the stack unless
font attributes of element are otherwise defined, have their own font
attribute stack. Where specifing an attribute puts it on top of the
current stack and </font> removes the last font attribute settings(s)
down to but not including the default of the current stack.
Throwing away the FONT element is going to do nothng more than break all
the work that has been created using it and that's alot of history to
throw away. http://www.archive.org while using CSS may actually contribute
to wrongful interpretation, via the question created by making it possible
to change things like emphisis, character size, etc. on a wide range of
documents..... contributing to bluring what will become history and maybe
even breaking it thru "use style sheet locate @ ......" which no longer
exist or in a currently downed part of the net. And the W3C has most
certainly complicated and broken stuff already in CSS being used.
Tim
>> The person speaking doublespeak, or gibberish, is you. You have a
>> weak grasp on the normal use of the English language, you rarely seem
>> to be able to use it normally, either in reading or writing it. And
>> you certainly struggle with proper technical use of the language.
>>
>> You have unrealistic expectations of your own abilities, and the
>> internets; poor comprehension of the task at hand, and the
>> explanations given to you about them.
>>
>> When faced with your own inabilities, you try to blame everyone else
>> but yourself, and try to hide it by going off on wild tangents.
On Thu, 13 Dec 2001 02:43:43 GMT,
"Timothy Rue" <thre...@earthlink.net> wrote:
> Claims nothing but claims. Just because you can type a sequence of
> characters and make a claim, doesn't mean the claim is based on reality.
It's about time you understood what the word "reality" means, because
you certainly don't live in it.
You've had things explained to you, by plenty of people, but you do
not understand what they've told you. You're too obsessed with trying
to jam everything else into fitting into your misunderstanding of the
situation.
> But I would like to know why you think a browser needs to parse a url
> in order to find something that browser doesn't like about it, while the
> internet that sent it and has to deal with it, has no problem with it.
You've already had it explained to you several times.
Why might a browser, or other HTML parser, need to encode certain
character?
Because certain characters have special meaning in HTML, anywhere in
HTML, no matter whereabouts in the source code that they're typed.
Whether in the middle or a paragraph of text, or in the middle of an
element (be that a HREF, NAME, SRC, or anywhere else).
Since the ampersand (for instance) has special meaning, the way to
stop the browser trying to interpret it as something else, is to use
the code that says this character is a stand-alone ampersand.
(By using &)
I've certainly encountered pages where clicking on a link with an
un-encoded ampersand has caused the link to fail. Using common (not
unusual) web page browsers.
Why might't the internet need to do the same thing? Because it's only
dealing with an address. It's not an HTML parser, it doesn't have the
same limitations to work around. It's got it's own sets of
conditions.
As a matter of fact, there are debates on whether URIs (typed in ones,
or otherwise), should be using un-encoded ampersands, or not.
Because, even in an address, they're still a significant /code/
character.
Why might you sometimes be able to get away with not encoding
characters?
* Because your browser isn't doing what it's supposed to do.
* Because your browser is able to work around the problem.
* Because some other system (than your browser) behaves likewise.
Why might it sometimes break, when using encoding.
Because your browser isn't coded properly.
> The only thing I see as being consistant is your desire to find a problem
> where there is non. As it seems the W3C validator and tidyHTML also does
> this looking for a problem in the concept of "Uniform"
The one doing that, is you. In continually whinging about having to
code HTML properly. You've been given explanations, but still won't
accept the situation.
You also have an obsession with the word, "uniform." It's a
descriptive word used in an internet computing term. You're trying to
inflict the English meaning of the word, in a situation where it's
just not "perfectly" suitable.
If anything, you should be arguing that the word is misused, not that
addresses are wrong because you don't feel that addresses are uniform
enough, for you.
Perhaps your MODEM doesn't do a "handshake" when it connects to your
server, because it doesn't have any "hands." Not all definitions can
be rigidly applied. Forget about "uniform."
> The solution direction of the W3C regarding the FONT problem is not a
> solution at all. For the problem is stated to be one of incompatability
> across browsers in dealing with variations in the <FONT> attributes. A
> problem that was started by MicroSoft adding in their own attributes.
>
> The proposed CSS doesn't solve that problem but instead makes anything
> that uses <FONT> to break in a system (browser) that no longer uses
> <FONT>, while creating CSS problems with anything that doesn't support
> CSS.
Huh? If it no-longer uses FONT, how is using FONT going to break it?
Sure enough, if you only use CSS to do your text styling, and someone
browses the page using a browser that doesn't use CSS, they're not
going to see any of your custom styling.
Likewise, FONT has to be supported by any browser trying to read a
page that used FONT in it.
That's always been the case (regarding the support of various
commands).
<FONT> is fairly good. You can specify size (absolute, or relative),
the font face (or a list or different choices), and colour.
CSS also does the same, and more. You can specify a family. e.g. Just
specify a sans-serif font should be used, and let the browser use its
preferred sans-serif font. As well as being specific. You can even
specify exact point sizes, rather than just specific "sizes." Which
can help, when including text and graphics, to keep things in
proportion.
However, specifying absolute sizes has always been a problem, for when
the reader needed to be able to change that to something more suitable
for the screen format, or eyesight.
With CSS, you can specify sizes as percentages. Which can be a much
better way of getting all the different font sizes into a sensible
range, while still allowing the reader to pick the base font size.
(Finally allowing you to get around the problem where some of the
smaller H sizes end up being smaller than the body text.)
Compatibility has, and always, will be, an issue between different
browsers, whatever the coding technique used. But CSS has more to
offer, regarding font styling. It's hardly a backward step.
> Throwing away the FONT element is going to do nothng more than break all
> the work that has been created using it and that's alot of history to
> throw away.
Because a newer HTML specification recommends changes, that doesn't
necessarily mean that browsers will stop supporting older versions of
HTML. HTML versions 2 and 3 are still quite ancient, but usually
supported, well enough, on modern browsers. I wouldn't worry about
that, for quite a while.
Anyway, any page that relies on specific styling, to be useable, has
always been a bad example of how to code for HTML. Funnily enough,
we've managed, for a heck of a long time, to get by with typewritten
documents, with every letter in the book in the same type face. And
still manage to understand what was written in them. Well, some of
us, at least.
John Burns
Given the claims you have made in the past and then refused to provide
the evidence to substantiate such I find this comment rich indeed.
>So I'm a bad speller and my mind works quicker than I can type, sometime
>resultung in missspellings, whole words droped and even in rethinking how
>I say something sometimes forgetting to remove a word. Al that says is
>that I never learned to type, as many internet users are like me in being
>a few finger typest.
By your own admission you were poorly educated in English which has nothing
at all to do with typing speed. BTW I would say that everyone can think
faster than they can type but if we are talking about coherent thought then
that's a different matter.
>But I would like to know why you think a browser needs to parse a url
>in order to find something that browser doesn't like about it, while the
>internet that sent it and has to deal with it, has no problem with it.
>The only thing I see as being consistant is your desire to find a problem
>where there is non. As it seems the W3C validator and tidyHTML also does
>this looking for a problem in the concept of "Uniform"
The only consistency is your, as always, refusal to accept that you are
wrong. You always want to blame others for your own inadequacies. You
act like a child who sticks his fingers in his ears and makes a loud noise
in order not to hear what is being said.
Come on Tim, you not that long ago still claimed you were correct in your
_wrong_ interpretation that the period in version numbers was analogous to a
decimal point despite all the information to the contrary.
Hey if ignorance is bliss what's it like living in Utopia Tim?
[SNIP]
Daniel Miller
wrote:
>Timothy Rue is like SG. Both will rather die than admit they ever said
>something which wasn't true. But SG's drivel is usually rather easy to
>read and understand, unlike Timothy Rue's, which seems like the
>babbling of a lunatic.
Hey Joona, I'll give you a tip: when confronted with babble and other
stuff you don't like, just go and read something else. It is called
free will.
I guess it is also free will if you choose to gripe and moan and fight
with TR, but it just increases the negativity level, and drives people
away from the platform.
Joona I Palaste
Well I personally have Tim Rue killfiled, but replies to his posts
still show up. What am I to do? Killfile everyone else too or demand
them to killfile Tim Rue too? I'm not fighting with Tim Rue. All I'm
doing is agreeing with everyone else that's he's a total moron.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"It sure is cool having money and chicks."
- Beavis and Butt-head
Tim
Joona I Palaste <pal...@cc.helsinki.fi> wrote:
>>> Timothy Rue is like SG. Both will rather die than admit they ever said
>>> something which wasn't true. But SG's drivel is usually rather easy to
>>> read and understand, unlike Timothy Rue's, which seems like the
>>> babbling of a lunatic.
Daniel Miller <dac...@netscape.net> scribbled the following:
>> Hey Joona, I'll give you a tip: when confronted with babble and other
>> stuff you don't like, just go and read something else. It is called
>> free will.
>>
>> I guess it is also free will if you choose to gripe and moan and fight
>> with TR, but it just increases the negativity level, and drives people
>> away from the platform.
On 14 Dec 2001 22:51:46 GMT, Joona I Palaste <pal...@cc.helsinki.fi>
wrote:
> Well I personally have Tim Rue killfiled, but replies to his posts
> still show up. What am I to do? Killfile everyone else too or demand
> them to killfile Tim Rue too? I'm not fighting with Tim Rue. All I'm
> doing is agreeing with everyone else that's he's a total moron.
Well, you could killfile against thre...@earthlink.net in the
references header, to kill any topic he participates in. Though, he
might be butting into things that you might want to read.
Ordinarily, I'd ignore the ignorant rantings of some. But when they
go blatantly insisting that something right is wrong, then go
promoting the idea of doing things wrongly; that just makes things
worse for everyone, if the uneducated just take them at face value,
and do what they suggest.
Timothy Rue
>Daniel Miller <dac...@netscape.net> scribbled the following:
>> On 8 Dec 2001 14:45:14 GMT, Joona I Palaste <pal...@cc.helsinki.fi>
>> wrote:
>>>Timothy Rue is like SG. Both will rather die than admit they ever said
>>>something which wasn't true. But SG's drivel is usually rather easy to
>>>read and understand, unlike Timothy Rue's, which seems like the
>>>babbling of a lunatic.
>> Hey Joona, I'll give you a tip: when confronted with babble and other
>> stuff you don't like, just go and read something else. It is called
>> free will.
>> I guess it is also free will if you choose to gripe and moan and fight
>> with TR, but it just increases the negativity level, and drives people
>> away from the platform.
>Well I personally have Tim Rue killfiled, but replies to his posts
>still show up. What am I to do? Killfile everyone else too or demand
>them to killfile Tim Rue too? I'm not fighting with Tim Rue. All I'm
>doing is agreeing with everyone else that's he's a total moron.
An example of an opposing weak willed person that feels a need to
announce it?
<shrug>
Joona I Palaste
> On 8 Dec 2001 14:45:14 GMT,
> Joona I Palaste <pal...@cc.helsinki.fi> wrote:
>> Well I personally have Tim Rue killfiled, but replies to his posts
>> still show up. What am I to do? Killfile everyone else too or demand
>> them to killfile Tim Rue too? I'm not fighting with Tim Rue. All I'm
>> doing is agreeing with everyone else that's he's a total moron.
> Well, you could killfile against thre...@earthlink.net in the
> references header, to kill any topic he participates in. Though, he
> might be butting into things that you might want to read.
How do I do that in tin 1.4.2 release 20000205 ("Possession")? If it's
possible I will do it ASAP, and will do it for a couple of other people
too: "Thinkit", "Deathasaurus", SG, Jai Maharaj, maybe even Brian Kilby
and David Willis...
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Outside of a dog, a book is a man's best friend. Inside a dog, it's too dark
to read anyway."
- Groucho Marx
Tim
Joona I Palaste <pal...@cc.helsinki.fi> wrote:
>>> Well I personally have Tim Rue killfiled, but replies to his posts
>>> still show up. What am I to do? Killfile everyone else too or demand
>>> them to killfile Tim Rue too? I'm not fighting with Tim Rue. All I'm
>>> doing is agreeing with everyone else that's he's a total moron.
Tim <T...@localhost.invalid> scribbled the following:
>> Well, you could killfile against thre...@earthlink.net in the
>> references header, to kill any topic he participates in. Though, he
>> might be butting into things that you might want to read.
On 15 Dec 2001 20:03:43 GMT,
Joona I Palaste <pal...@cc.helsinki.fi> wrote:
> How do I do that in tin 1.4.2 release 20000205 ("Possession")? If it's
> possible I will do it ASAP, and will do it for a couple of other people
> too: "Thinkit", "Deathasaurus", SG, Jai Maharaj, maybe even Brian Kilby
> and David Willis...
I don't know the tin program, but if it allows you to pick header
names and header contents, that's the two you want to look for
("references" and something generated by the annoying person's posting
software).
An all encompassing option is to killfile any post that has the
annoying person's details anywhere in the entire headers. That takes
care of to, from, references, message idents, etc., all in the one
kill file statement.
Of course, if you've acheived that objective, by now; you won't get to
read this message. ;-)
Bill Godfrey
> HTML - HyperText Markup Language!!!
> It is a F*ckin interpreted language, not a gawd damn institution!
Whatever it is, it isn't a programming language.
Bill, <IF cond="a==b"><THEN>Hello</THEN><ELSE>Goodbye</ELSE></IF>
Rick Hodger
> On 09-Dec-01 12:31:31 Keith Blakemore-Noble <Ke...@Blakemore-Noble.net> wrote:
> >Hi there Joona I Palaste, on or around 9 Dec 2001 17:15:37 GMT you
> >wrote something about "Re: New home page focus"...
> >> Timothy Rue, you are an arrogant idiot. Do you really believe that if
> >> your HTML code does not validate under a standard HTML validator,
> >> that means the validator is buggy? Do you think you are some Grand
> >> Deity who is always infallible?
>
> So Joona, you think it's too much for me to expect such a validator to
> know the difference between HTML and URLs. Between what is the markup
> language and what it is marking up?
Your URL errors are coming from the evil javascript popup you used.
You should be using OnClick events, not "javascript:" URLs. Javascript
is not part of the HTML specification, which is why you need your
comment tags (<!-->) inside your script tags.
Hell, for all that you're linking to, Javascript popups are a waste of
time and code. You should just be using <a href="" target="_new"></a>
tags.
Also, what's with the "color" tag in your horizontal rules? I don't
know of any browser that supports that.
> >You forget, Joona, that Rue has previously, in this newsgroup, declared
> >himself to be Christ.
>
> >I think that answers your question!
>
> There is plenty of proof of claims that I did such a thing, but you'll be
> hard pressed to find such a claim being made by me.
Took all of 3-4 seconds on Google to find. You have never directly
said that you are the messiah, but you've certainly made dozens of
implications.
http://groups.google.com/groups?selm=1011.632T2998T6496560threeseas%40earthlink.net&output=gplain
"What is a saviour to do?"
http://groups.google.com/groups?selm=5362.630T2189T7725747threeseas%40earthlink.net&output=gplain
"2000??? Come on, I'm older than that!"
> I have however said
> that the saviour is not comming because he does not want to take the self
> esteem away from the people who are perfectly capable of "doing things on
> earth, as they are done in heaven".
Yes, you have. In many trolling offtopic threads you've started on
csam about religeon.
> For that is the way things are done in
> heaven, by everyone, and also the only way the saviour can feel like part
> of the family rather than an outcast slave taking care of a bunch of
> spoiled self-esteem-less brats.
...and even here you make claims to know what Jesus' opinion on the
current world would be. You do -not- know for absoloute certain. Noone
does. Anyone who does know, is more than likely a prophet. That is, if
you believe in the bible. And while you certainly mad enough to be a
prophet, I doubt very much that you actually are.
> Let me suggest that such claims about me are suggestive of the desires of
> those who make them.
Yeah. Sure. And all women really want to be raped. And all gays want
to be beaten up.
We have two posts, if not dozens more, written by you, and in which
you implicate that you are the messiah/saviour. Noone is making
claims. You don't need to make claims when you have proof.
--
Rick Hodger
Tim
>> HTML - HyperText Markup Language!!!
>> It is a F*ckin interpreted language, not a gawd damn institution!
Ah, so that's how you pronounce the * symbol.
On 17 Dec 2001 16:32:58 +0000,
Bill Godfrey <billg-...@bacchae.f9.co.uk.invalid> wrote:
> Whatever it is, it isn't a programming language.
>
> Bill, <IF cond="a==b"><THEN>Hello</THEN><ELSE>Goodbye</ELSE></IF>
If HTML had been a compiled, not interpreted language. Us web page
viewers wouldn't have had half the problems that we do. The compiler
would have spat the dummy, causing them to fix the code before the
author uploaded it to the world. ;-)
Though, I'm told that despite HTML being human readable code, it was
*always* /intended/ to be machine generated. It's a shame that most
HTML generators are still so crap at it. And rarely do they take an
overall view of the intent of the author, before saving the typing as
an HTML file.
e.g. <FONT SIZE="+1">a</FONT><FONT SIZE="+1"> </FONT><FONT
SIZE="+1">stu</FONT><FONT SIZE="+1">pid</FONT><FONT SIZE="+1"></FONT>
<FONT SIZE="+1"> but common</FONT><FONT SIZE="+1">example</FONT>
Timothy Rue
>"Timothy Rue" <thre...@earthlink.net> wrote in message
>news:<1774.743T1201T9...@earthlink.net>...
>> On 09-Dec-01 12:31:31 Keith Blakemore-Noble <Ke...@Blakemore-Noble.net>
>> wrote:
>> >Hi there Joona I Palaste, on or around 9 Dec 2001 17:15:37 GMT you
>> >wrote something about "Re: New home page focus"...
>> >> Timothy Rue, you are an arrogant idiot. Do you really believe that if
>> >> your HTML code does not validate under a standard HTML validator,
>> >> that means the validator is buggy? Do you think you are some Grand
>> >> Deity who is always infallible?
>>
>> So Joona, you think it's too much for me to expect such a validator to
>> know the difference between HTML and URLs. Between what is the markup
>> language and what it is marking up?
>Your URL errors are coming from the evil javascript popup you used.
Gee Rick, given all your programming knowledge and experience about FTP,
I'd think you'd know better then to make such an erronious comment.
Iggy Drougge
:> Well, you could killfile against thre...@earthlink.net in the
:> references header, to kill any topic he participates in. Though, he
:> might be butting into things that you might want to read.
: How do I do that in tin 1.4.2 release 20000205 ("Possession")? If it's
: possible I will do it ASAP, and will do it for a couple of other people
: too: "Thinkit", "Deathasaurus", SG, Jai Maharaj, maybe even Brian Kilby
: and David Willis...
^K should do the trick.
--
En ligne avec Tin 1.4.
Joona I Palaste
I know about ^K. But it only lets me killfile according to name or
subject. Or does it allow message-ID also?
BTW, have you checked ATT lately? Are Brian Kilby and David Willis
still the same assholes as they were when I left?
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Show me a good mouser and I'll show you a cat with bad breath."
- Garfield