Actually, it doesn't have to be a blockquote...but I'm at my wits'
end: I want to make bold several lines of text which have a pair of
<br /tags between them...seems like the <b></bdo not "carry over"
when there are <br /tags involved...???

I've tried using <p style="font-weight: bold;"></p>, I've tried
<blockquote></blockquote>...I just can't figure how I'm supposed to
get the <b></btags to work for all the lines! Surely there must be
another way than having to apply <b></btags to each sentence???

TIA

Prisoner at War wrote:

Actually, it doesn't have to be a blockquote...but I'm at my wits'
end: I want to make bold several lines of text which have a pair of
<br /tags between them...seems like the <b></bdo not "carry over"
when there are <br /tags involved...???
>
I've tried using <p style="font-weight: bold;"></p>, I've tried
<blockquote></blockquote>...I just can't figure how I'm supposed to
get the <b></btags to work for all the lines! Surely there must be
another way than having to apply <b></btags to each sentence???
>

Must be more going on than what you have post, hence a URL is *always*
useful. If you have not done something else to override it,

p { font-weight: bold; }

will make your paragraphs bold even with embedded <br>s


--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

In article
<6e4a700f-d9ca-4d48-9b90-300d3625c06d@k13g2000hse.googlegroups.com>,
Prisoner at War <prisoner_at_war@yahoo.comwrote:

Actually, it doesn't have to be a blockquote...but I'm at my wits'
end: I want to make bold several lines of text which have a pair of
<br /tags between them...seems like the <b></bdo not "carry over"
when there are <br /tags involved...???
>
I've tried using <p style="font-weight: bold;"></p>, I've tried
<blockquote></blockquote>...I just can't figure how I'm supposed to
get the <b></btags to work for all the lines! Surely there must be
another way than having to apply <b></btags to each sentence???
>

<http://dorayme.890m.com/alt/offerToEatHat.html>

--
dorayme

dorayme wrote:

In article
<6e4a700f-d9ca-4d48-9b90-300d3625c06d@k13g2000hse.googlegroups.com>,
Prisoner at War <prisoner_at_war@yahoo.comwrote:
>

>
<http://dorayme.890m.com/alt/offerToEatHat.html>
>

Careful, unless you prefer a diet of felt. Disabled style or user
stylesheet could be a play ;-)

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

In article <10209$48b7780f$40cba7c6$20794@NAXS.COM>,
"Jonathan N. Little" <lws4art@central.netwrote:

dorayme wrote:

>
Careful, unless you prefer a diet of felt. Disabled style or user
stylesheet could be a play ;-)

True, I better take a small precaution, like cook a nice chocolate hat.

--
dorayme

Prisoner at War wrote:

Actually, it doesn't have to be a blockquote...but I'm at my wits'
end: I want to make bold several lines of text

Stop wanting that. It makes a poor impression. People will feel bad when
looking at a block of bold text, and some of them will even realize why.
Find a better way of emphasis, like change in font size, colored background,
border around, or a combination of methods.

which have a pair of
<br /tags between them...seems like the <b></bdo not "carry over"
when there are <br /tags involved...???

They do "carry over" <br /of course. The <br /markup is text-level. You
are not revealing us the real problem you have created.

I've tried using <p style="font-weight: bold;"></p>,

It's not wise, but technically it bolds the text, other things being equal.
So either other things aren't equal (e.g., some external stylesheet prevents
bolding) or you don't see that the text _is_ bold. (It's sometimes difficult
to see for some appearances of text, especially when ridiculously small font
sizes are used.)

Actually, your sample element has empty content. I, for one, have
difficulties in distinguishing between a normal empty string and a bold
empty string.

Yucca

dorayme wrote:

In article <10209$48b7780f$40cba7c6$20794@NAXS.COM>,
"Jonathan N. Little" <lws4art@central.netwrote:
>

>
True, I better take a small precaution, like cook a nice chocolate hat.
>

Good plan!

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Jonathan N. Little wrote:

dorayme wrote:

>
Careful, unless you prefer a diet of felt. Disabled style or user
stylesheet could be a play ;-)

No worries. She could always style spun sugar to look like a hat and eat
that. Of course, with stylesheets disabled, it wouldn't look like a hat.

"dorayme" <doraymeRidThis@optusnet.com.auwrote in message
news:doraymeRidThis-D6E46A.13515729082008@web.aioe.org...

In article
<6e4a700f-d9ca-4d48-9b90-300d3625c06d@k13g2000hse.googlegroups.com>,
Prisoner at War <prisoner_at_war@yahoo.comwrote:
>

May I suggest that the normal convention with quotes is either the use of
italics, &quot; marks or indented block. Personally I prefer to combine all
of the above, but I am told this is not quite the convention either.

Having said this, the w3c validator doesn't recognise any nesting within the
blockquote element a blockquote element is recognised inside or outside
block elements. However, inline elements inside a blockquote element are
reported as invalid unless the blockquote element is nested inside a block
element such as <p></p>, <h3></h3>, <div></div>, etc, and if this is the
case, no text outside the inline elements but within the nested blockquote
element is validated. I don't know if it is a bug or not, but the validator
does validate normally when block elements such as <p></p& <h3></h3>, etc
appear inside the blockquote element and no inline elements appear inside
the blockquote element but outside the block element it contains.

The blockquote element adds a redundant level of complexity to the
inline/block model of Hermetic (IE "well-formed") mark-up. When indenting a
block quotation, I prefer to subclass the paragraph <p></pblock element in
CSS as

p.QT {margin-left:49px; margin-right:49px;}

with <p class="QT">...</pcontaining my block quotations in the html
instead of the blockquote element. Notice how the use of CSS to define my
own class of block element gives me more control of that element. I can
equalise left *and* right indentation as I've done at
http://literature.timothycasey.info and browsers don't appear to have any
problem differentiating inline elements within the p.QT element - even when
these inline elements are broken by the <brelement as with the Zoroastrian
Maxim from the Dedistan Denig quotation on this page. This would allow you
to include the font-weight in the CSS as

p.QT {margin-left:49px; margin-right:49px;font-weight: bold;}

in your CSS. The page also validates both for HTML strict and CSS so you can
rely on this technique for some time to come across a wide range of
browsers.

Good Luck!

--
Timothy Casey GPEMC! Conditions apply. See www.fieldcraft.biz/GPEMC
Essays: http://timothycasey.info; http://speed-reading-comprehension.com
Software: http://fieldcraft.biz; Scientific IQ Test, Web Menus, Security.
Science & Technical: http://geologist-1011.com; http://web-design-1011.com

Number Eleven - GPEMC! wrote:

May I suggest that the normal convention with quotes is either the
use of italics, &quot; marks or indented block. Personally I prefer
to combine all of the above, but I am told this is not quite the
convention either.

It's a bad idea to combine them, and surely not normal by any reputable
style guide. Moreover, &quot; is bad practice, since the ASCII quotation
mark " (which is what &quot; means) is not a recommended quotation mark in
any normal human language. (Besides, using &quot; instead of " is pointless
and just confusing and makes text look like... what should I say, Perl
code?)

For block quotations, indentation is normal rendering. Using italics for
blocks of text might be fashionable in some circles, but it makes the text
less readable.

None of this is really an HTML issue. In HTML you use <blockquotefor block
quotations, and that's it. You change the rendering in CSS, if desired.

Having said this, the w3c validator doesn't recognise any nesting
within the blockquote element

Huh? What are you talking about? Of course it does. Most nested blockquotes
are, of course, misguided authoring practices where <blockquoteis used in
a command-like manner, with the intended meaning of "indent!" But nested
blockquotes are as such allowed and adequately parsed by validators.

a blockquote element is recognised
inside or outside block elements.

Of course, but what has this got to do with the topic, or anything?

However, inline elements inside a
blockquote element are reported as invalid unless the blockquote
element is nested inside a block element such as <p></p>, <h3></h3>,
<div></div>, etc,

It seems that you are trying to say something about HTML syntax. Please
learn it first. You are just confusing yourself, and maybe some other
novices as well. (Inline elements are not allowed as children of blockquote
_in the Strict version_. No version of HTML allows blockquote inside p or
h3.)

p.QT {margin-left:49px; margin-right:49px;}

You should also learn the basics of CSS from a decent book before giving
advice on CSS. Any decent book tells you why you should not use the px unit
in a context like that. And this is an HTML group, not CSS.

p.QT {margin-left:49px; margin-right:49px;font-weight: bold;}

So you're saying that instead of proper markup for a blockquote, a p element
with a cryptic class be used, and in addition to using such margins, the
text should be bold.

Sounds like trolling, really.

Yucca

"Jukka K. Korpela" <jkorpela@cs.tut.fiwrote in message
news:xZswk.61413$_03.47661@reader1.news.saunalahti .fi...

Number Eleven - GPEMC! wrote:
>

>
It's a bad idea to combine them, and surely not normal by any reputable
style guide. Moreover, &quot; is bad practice, since the ASCII quotation
mark " (which is what &quot; means) is not a recommended quotation mark in
any normal human language. (Besides, using &quot; instead of " is

pointless

and just confusing and makes text look like... what should I say, Perl
code?)
>
For block quotations, indentation is normal rendering. Using italics for
blocks of text might be fashionable in some circles, but it makes the text
less readable.

Actually, it is not confusing although it can limit your options.

>
None of this is really an HTML issue. In HTML you use <blockquotefor

block

quotations, and that's it. You change the rendering in CSS, if desired.
>

>
Huh? What are you talking about? Of course it does. Most nested

blockquotes

are, of course, misguided authoring practices where <blockquoteis used

in

a command-like manner, with the intended meaning of "indent!" But nested
blockquotes are as such allowed and adequately parsed by validators.

Try parsing the statements in full...

>

>
Of course, but what has this got to do with the topic, or anything?

It does, but you need to read the paragraph as a whole...

>
It seems that you are trying to say something about HTML syntax. Please
learn it first. You are just confusing yourself, and maybe some other
novices as well. (Inline elements are not allowed as children of

blockquote

_in the Strict version_. No version of HTML allows blockquote inside p or
h3.)

Then the w3c validator has a bug or two but at the end of the day, it still
flags blockquotes inside block elements via what I was talking about. Block
elements inside the blockquote element actually do validate as HTML strict;
as do any inline elements within the block elements within the blockquote
element - I checked first.

>
You should also learn the basics of CSS from a decent book before giving
advice on CSS. Any decent book tells you why you should not use the px

unit

in a context like that. And this is an HTML group, not CSS.

HTML without CSS is like CSS without markup; rather limited! I've also read
why px *is* used in this context - specification reduces ambiguity; and it
both validates and works interoperably so who cares!

>
So you're saying that instead of proper markup for a blockquote, a p

element

with a cryptic class be used, and in addition to using such margins, the
text should be bold.

The original poster wanted bold, so here it is by this method; and it
validates...

--
Timothy Casey GPEMC! Conditions apply. See www.fieldcraft.biz/GPEMC
Essays: http://timothycasey.info; http://speed-reading-comprehension.com
Software: http://fieldcraft.biz; Scientific IQ Test, Web Menus, Security…
Science & Technical: http://geologist-1011.com; http://web-design-1011.com

Number Eleven - GPEMC! wrote:

Try parsing the statements in full...

I do, and a combination of nonsensical sentences still does not make a full
statement any more sensible.

>
Then the w3c validator has a bug or two but at the end of the day, it
still flags blockquotes inside block elements via what I was talking
about.

This, too, makes no sense. You claim that the validator has a bug without
giving any evidence. I simply corrected incorrect statements you made, and
you quoted it and made that foolish statement and then continue babbling,
based on a misunderstanding of yours on _another_ issue, one that I already
corrected.

Block elements inside the blockquote element actually do
validate as HTML strict;

That was never under dispute, and it's also true in Transitional.

as do any inline elements within the block
elements within the blockquote element - I checked first.

No you didn't. If the inner block element is a blockquote, then it may not
have inline elements as children in Strict. Besides, the statement you made
is also irrelevant to the topic.

HTML without CSS is like CSS without markup; rather limited!

This group is still an HTML group.

I've
also read why px *is* used in this context - specification reduces
ambiguity; and it both validates and works interoperably so who cares!

Apparently you don't care about learning CSS or HTML.

The original poster wanted bold, so here it is by this method;

And an _appropriate_ answer also tells why bolding large pieces of text is a
bad idea, as well as points out that when desired, bolding is best made
using CSS, which is off-topic in this group.

and it validates...

Quite irrelevant.

Please keep using your "funny" forged From field as long as you remain
clueless.

Yucca

I checked out your tip regarding ASCII character 34 (the " character
straight from the keyboard), instead of &quot; - and it works and validates,
so thanks, I agree it's much easier to use - but it is a pain to discuss!

"Jukka K. Korpela" <jkorpela@cs.tut.fiwrote in message
news:xSwwk.61564$_03.11888@reader1.news.saunalahti .fi...

Number Eleven - GPEMC! wrote:

[SNIP]

>
That was never under dispute, and it's also true in Transitional.
>

>
No you didn't. If the inner block element is a blockquote, then it may not
have inline elements as children in Strict.

[SNIP]

Now I said:

"Block elements inside the blockquote element actually do validate as HTML
strict; as do any inline elements within the block elements within the
blockquote element - I checked first."

So let's take a closer look at

"inline elements
inside
block elements
inside
the
blockquote element."
As per my original statement. Check this out:
http://web-design-1011.com/blockquot...d-inline.shtml

That's my web design site with a special page dedicated to this just this
topic; namely those "inline elements within the block elements within the
blockquote element". IE relevant HTML without the text it embellishes:

<p>
<acronym>
</acronym>
<acronym>
</acronym>
</p>
<blockquote>
<h2>
<big>
</big>
</h2>
<p>
<acronym>
</acronym>
<strong>
</strong>
<em>
</em>
</p>
</blockquote>
<h2>
</h2>

This refers to nested inline elements such as the big, strong, and emphatic
elements shown above; more importantly to accessibility features such as the
acronym element that also appears indirectly nested within the blockquote
above.

As you will have seen after following the link, neither page functionality
is degraded nor is there any malfunction of the blockquote which I know you
are not disputing - but those inline elements inside the block elements
inside the blockquote I specified above, both validate and function
correctly. Those were the points I was making before you entered this
discussion. There is a HTML validation button at the left of the footer at:
http://web-design-1011.com/blockquot...d-inline.shtml
Following that link will verify what I am saying here. Take a peek at the
source. Firefox has a fantastic source display (on the "View" Menu).

And I did check first. I modified a live page with the right features and
after validation changed it back. I check every technique I'm not familiar
with this way before proceeding with it because a surprising number of
techniques documented by reputable sources are complete duds (eg. techniques
that depend to an unreasonable degree on security holes in visitor browsers,
techniques that are not interoperable, & techniques that simply do not work
at all).

Finally, did I say anything personal at all about you in this response?

--
Timothy Casey GPEMC! Conditions apply. See www.fieldcraft.biz/GPEMC
Essays: http://timothycasey.info; http://speed-reading-comprehension.com
Software: http://fieldcraft.biz; Scientific IQ Test, Web Menus, Security…
Science & Technical: http://geologist-1011.com; http://web-design-1011.com

In article <48c39b5a$0$4449$afc38c87@news.optusnet.com.au>,
"Number Eleven - GPEMC!" <eleven_is_the_number@timothycasey.info>
wrote:
[... long post ...]

Finally, did I say anything personal at all about you in this response?

Only in the final moment when you - quite reasonably, mind you - ask
this question. <g>

--
dorayme

"Jukka K. Korpela" <jkorpela@cs.tut.fiwrote in message
news:xSwwk.61564$_03.11888@reader1.news.saunalahti .fi...

Number Eleven - GPEMC! wrote:

[SNIP]

>
This, too, makes no sense. You claim that the validator has a bug without
giving any evidence.

[SNIP]

This arrangement I am talking about is also something I tested. IE:

....<body>
<p>
<blockquote>
&gt; You claim that the validator has a bug without <br>
&gt; giving any evidence.
</blockquote>
</p>
....</body>

I did this test yesterday, explained the conditions and outcomes, so given
that anyone can test this bug, I've provided all the evidence necessary.
Here are some examples...

See: http://web-design-1011.com/blockquote-bug.shtml
http://web-design-1011.com/blockquote-bug2.shtml

As you can see, it doesn't matter how simple the test becomes, the validator
does not flag the improper nesting, but makes statements about the code that
are demonstrably false (such as missing start tags that are present in the
source view). Although this hints at the real problem, another information
management approach may assume that the bug was indicative of problems
relating either, objectives to specification or specification to standard.
In terms of risk management, this represents a higher probability of
unannounced code behaviour changes as a flow-on from misinterpretation and
correction in other areas. This is highly relevant to HTML authoring in
general because of the fact that browser interpretation of given standards
changes so often. The CSS modified paragraph I demonstrated as a substitute
for the blockquote element provides a pathway via known methods that lack
such questions, and is thus less prone to being broken by quirks in browser
evolution.

You see, relevant or not, communication conventions such as language and
coding syntax evolve and change in line with social evolution. Languages
that do not change to meet community needs die like Latin and Esperanto,
Cobol and Fortran. This behaviour dictates that no book on coding standards
in a persistent language is ever as reliable as inductive reasoning from the
evidence provided by a direct and immediate test, such as those I conducted
yesterday and repeated today.

--
Timothy Casey GPEMC! Conditions apply. See www.fieldcraft.biz/GPEMC
Essays: http://timothycasey.info; http://speed-reading-comprehension.com
Software: http://fieldcraft.biz; Scientific IQ Test, Web Menus, Security…
Science & Technical: http://geologist-1011.com; http://web-design-1011.com

Number Eleven - GPEMC! wrote:

I did this test yesterday, explained the conditions and outcomes, so
given that anyone can test this bug, I've provided all the evidence
necessary. Here are some examples...

You have demonstrated nothing but your ignorance of the basics of HTML.

To demonstrate a bug, you need to provide
a) a citation of a relevant specification
b) a specific case of software behavior that violates the cited
specification
c) identification of the exact way in which that case shows that the
software violates the specification.

You are playing with code like

<p>
<blockquote>
&gt; You claim that the validator has a bug without <br>
&gt; giving any evidence.
</blockquote>
</p>

without understanding _why_ it is invalid. If a validator's message does not
help you, then the reason is that those messages are useful only to people
who know the markup language used (and even something about formalized
syntax). If you asked politely, maybe someone would then explain to you that
by HTML rules (prior to XHTML), the start tag <blockquoteimplicitly closes
an open <pelement, etc. Well, this has been explained so often, that it's
probably in the W3C validator FAQ...

Yucca

On 2008-09-07, Number Eleven - GPEMC! <eleven_is_the_number@timothycasey.infowrote:

"Jukka K. Korpela" <jkorpela@cs.tut.fiwrote in message
news:xSwwk.61564$_03.11888@reader1.news.saunalahti .fi...

[SNIP]

[SNIP]
>
This arrangement I am talking about is also something I tested. IE:
>
...<body>
<p>
<blockquote>
&gt; You claim that the validator has a bug without <br>
&gt; giving any evidence.
</blockquote>
</p>
...</body>
>
I did this test yesterday, explained the conditions and outcomes, so given
that anyone can test this bug, I've provided all the evidence necessary.
Here are some examples...
>
See: http://web-design-1011.com/blockquote-bug.shtml
http://web-design-1011.com/blockquote-bug2.shtml
>
As you can see, it doesn't matter how simple the test becomes, the validator
does not flag the improper nesting, but makes statements about the code that
are demonstrably false (such as missing start tags that are present in the
source view).

I think the validator's output makes more sense when you realize that
there are three different problems with the markup here.

<blockquote>hello</blockquote>

is invalid because blockquote has to contain at least one block-level
element (or a SCRIPT). If you try the above you get the same errors:
"character data not allowed here" for hello (it's expecting <por <div>
or something block-level) and "end tag for blockquote which is not
finished"-- it's not finished because it doesn't have that required
block-level element inside it.

Now if you try:

<p>
<blockquote>hello</blockquote>

That's invalid for the same reasons, and you get the same two errors
reported. There's nothing wrong with the <pin front of the
blockquote-- the </pis optional, so this is just an empty paragraph
followed by a blockquote.

And this:

<p>
<blockquote>
<div>hello</div>
</blockquote>

is therefore perfectly valid.

This:

<p>
<blockquote>
<div>hello</div>
</blockquote>
</p>

Will tell you you're closing a <pyou didn't open-- the first <pwas
considered closed by the blockquote.

So for:

<p>
<blockquote>
character data
</blockquote>
</p>

You get all three errors reported, which is not unreasonable. I
certainly don't think it could be called a bug.

I was quite surprised myself that a blockquote has to contain at least
one block-level element or SCRIPT, but that's what the DTD says.

"Ben C" <spamspam@spam.eggswrote in message
news:slrngc80gb.31m.spamspam@bowser.marioworld...

On 2008-09-07, Number Eleven - GPEMC!

<eleven_is_the_number@timothycasey.infowrote:

without

given

validator

that

the

>
I think the validator's output makes more sense when you realize that
there are three different problems with the markup here.

[SNIP]

I'm aware of the DTD. However my original point was that although the error
is flagged it is misidentified. You are right, it makes more sense if you
already know what the validator is supposed to be telling you - but the
reason I am bringing this up is because this doesn't work for everyone. Not
everyone knows HTML like you or I do.

I was quite surprised myself that a blockquote has to contain at least
one block-level element or SCRIPT, but that's what the DTD says.

As was I. However, the validator does occasionally misidentify errors as it
does by misreporting incorrectly nested blockquotes as missing tags.

--
Timothy Casey GPEMC! Conditions apply. See www.fieldcraft.biz/GPEMC
Essays: http://timothycasey.info; http://speed-reading-comprehension.com
Software: http://fieldcraft.biz; Scientific IQ Test, Web Menus, Security.
Science & Technical: http://geologist-1011.com; http://web-design-1011.com

"Jukka K. Korpela" <jkorpela@cs.tut.fiwrote in message
news:9_Qwk.62071$_03.50952@reader1.news.saunalahti .fi...

Number Eleven - GPEMC! wrote:
>

>
You have demonstrated nothing but your ignorance of the basics of HTML.

Care to elaborate on how someone who has "nothing but ignorance of the
basics of HTML" can hand code pages like:
http://web-design-1011.com/blockquote-bug.shtml
http://web-design-1011.com/blockquote-bug2.shtml

???

Care to demonstrate that degree of superiority of knowledge that gives you
the right to personally attack the expertise of people you disagree with?

Can you for instance, tell us how the drop down menus in the pages in
question function even when the page is listed in the browser as a
restricted site?
OR
Perhaps you can tell us from a functional perspective why those menus are
made from classed tables instead of classed lists?

Perhaps you'd like to tell us all why you prefer to attack the person
instead of the argument? Surely you understand that your style of argument
reflects on you and these days, everyone knows that personal attacks are
diversionary tactics. What are you diverting people's attention from?

To demonstrate a bug, you need to provide
a) a citation of a relevant specification
b) a specific case of software behavior that violates the cited
specification
c) identification of the exact way in which that case shows that the
software violates the specification.

To demonstrate a bug, you need only show a deviation from goal in the
program behaviour. The relevant specification is not in question here: we
are not disagreeing that the test bed comprises an improperly nested
blockquote. We both know that the object of the validator is twofold; to
flag validation errors, and correctly identify validation errors. There is
no need to prove what we both already understand. It also goes without
saying that the validator was not intended to mislead people and therefore
factual errors in validator output are automatically bugs. In this context
it is only necessary to show the misidentification of an error. That I have
done.

You are playing with code like

[sic.]

>
<p>
<blockquote>
&gt; You claim that the validator has a bug without <br>
&gt; giving any evidence.
</blockquote>
</p>
>
without understanding _why_ it is invalid.

Untrue - I already know that this blockquote is improperly nested. As a
software developer, I also know that the objective of an error message is to
correctly identify the error generated, and therefore if an error message
misidentifies the error then there is a bug in the error handler. This is
universal regardless of specification, unless you are writing for the black
hats.

What I just showed you was the validator misattributing the incorrect
nesting of the blockquote and paragraph to missing tags - which a review of
the code demonstrates are not actually missing.

Whether the validator's message helps me or not, the deviation of it's
behaviour from it's explicit objective constitutes a bug and once again, my
experience in software development is that this will be unhelpful for many
of those trying to use the scientific method to learn HTML.

I don't mean to get too personal, but I find it interesting that at least on
this thread, you consistently defer to argumentum ad homenim. This is a form
of false argument, and although formally it proves nothing
(http://en.wikipedia.org/wiki/Fallacy), some people will take it to say
something about the sort of human being you are. If I was the sensitive
sort, I might think that you are trying to bully me. However,experience has
taught me that more than 90% of the time when people use a fallacy, it is
because they have no better argument to make than a false argument
(http://science.geologist-1011.net). If you do some reading (a lot of
reading actually) you might even discover one single solitary thesis that
combines both a fallacy and a conclusion that just happens to be true. So
from the perspective of inductive reasoning, it is not unreasonable to
discount an argument as soon as a fallacy is identified. This reflects on
what you have to say, and raises the question of why you choose to undermine
or otherwise discredit your own point of view like this?

--
Timothy Casey GPEMC! Conditions apply. See www.fieldcraft.biz/GPEMC
Essays: http://timothycasey.info; http://speed-reading-comprehension.com
Software: http://fieldcraft.biz; Scientific IQ Test, Web Menus, Security…
Science & Technical: http://geologist-1011.com; http://web-design-1011.com

On 2008-09-09, Number Eleven - GPEMC! wrote:

"Jukka K. Korpela" <jkorpela@cs.tut.fiwrote in message
news:9_Qwk.62071$_03.50952@reader1.news.saunalahti .fi...

>
Care to elaborate on how someone who has "nothing but ignorance of the
basics of HTML" can hand code pages like:
http://web-design-1011.com/blockquote-bug.shtml

Would you care to elaborate on how a HTML expert can produce a
page that has 3 errors and 5 warnings and looks like this:
<http://cfaj.freeshell.org/testing/bq.jpg>?

http://web-design-1011.com/blockquote-bug2.shtml
>
???
>
Care to demonstrate that degree of superiority of knowledge that gives you
the right to personally attack the expertise of people you disagree with?

Learn to ignore Jukka's rudeness; he can't help it. Concentrate
instead on the information he provides; it is almost always spot
on.

--
Chris F.A. Johnson <http://cfaj.freeshell.org>
================================================== =================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

"Chris F.A. Johnson" <cfajohnson@gmail.comwrites:

Would you care to elaborate on how a HTML expert can produce a
page that has 3 errors and 5 warnings and looks like this:
<http://cfaj.freeshell.org/testing/bq.jpg>?

LOL! The "interoperability, accessibility, compliance..." tag line is
especially funny. Oh, the irony...

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

On 2008-09-09, Number Eleven - GPEMC! <eleven_is_the_number@timothycasey.infowrote:

"Jukka K. Korpela" <jkorpela@cs.tut.fiwrote in message

[...]

To demonstrate a bug, you need only show a deviation from goal in the
program behaviour. The relevant specification is not in question here: we
are not disagreeing that the test bed comprises an improperly nested
blockquote. We both know that the object of the validator is twofold; to
flag validation errors, and correctly identify validation errors.

Yes but there's more than one correct way to identify errors, especially
when the input contains several.

What the validator does is start barfing at the first error it comes to.
The <pon its own is not an error, so it just skips past that. The </p>
is so that's the one it complains about.

A bit counter-intuitive perhaps but OK. What if the markup was a bit
more complicated-- the author might have intended a self-closing
paragraph further up and accidentally put </pin further down. Then
he'd complain "but it's not a NESTING error!"

Better for the validator to stick to what it's good at which is not
guessing what people meant.

On 10 Sep, 00:45, "Number Eleven - GPEMC!"
<eleven_is_the_num...@timothycasey.infowrote:

"Ben C" <spams...@spam.eggswrote in message
>
news:slrngc80gb.31m.spamspam@bowser.marioworld...
>

>

[...]

>

[...]

>

validator

that

the

>

>
[SNIP]
>
I'm aware of the DTD. However my original point was that although the error
is flagged it is misidentified.

No errors is misidentified.

You are right, it makes more sense if you
already know what the validator is supposed to be telling you - but the
reason I am bringing this up is because this doesn't work for everyone. Not
everyone knows HTML like you or I do.

Not everyone knows HTML like Ben C. If you or they don't know, you or
they have to learn. If you or they don't understand the error
messages, you and they could read a beginner guide to HTML. Even the
W3C's HTML recommendation is spelling this out.

"The P element represents a paragraph. It cannot contain block-level
elements (including P itself)."

"BLOCKQUOTE is for long quotations (block-level content)"

If the author of the beginner guide can't explain this, you should try
to find another beginner guide. You really need one.

>
As was I. However, the validator does occasionally misidentify errors as it
does by misreporting incorrectly nested blockquotes as missing tags.

Can you show one example where the validator is misidentifying an
error?

In your first link <http://web-design-1011.com/blockquote-bug.shtml>
you say:

The blockquote is not nested inside an p element, but inside the body
element.

The content within the blockquote isn't valid in HTML 4.01 strict:

"BLOCKQUOTE is for long quotations (block-level content)..."

"<!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- long quotation -->"

<http://www.w3.org/TR/html401/struct/text.html#edef-BLOCKQUOTE>