 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / HTML / September 2008How to Embolden A Blockquote?
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></b> do 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></b> tags to work for all the lines! Surely there must be another way than having to apply <b></b> tags to each sentence??? TIA > 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 [quoted text clipped - 5 lines] > get the <b></b> tags to work for all the lines! Surely there must be > another way than having to apply <b></b> tags 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  SignatureTake care, Jonathan ------------------- LITTLE WORKS STUDIO http://www.LittleWorksStudio.com In article <6e4a700f-d9ca-4d48-9b90-300d3625c06d@k13g2000hse.googlegroups.com>, > 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 [quoted text clipped - 5 lines] > get the <b></b> tags to work for all the lines! Surely there must be > another way than having to apply <b></b> tags to each sentence??? <http://dorayme.890m.com/alt/offerToEatHat.html> Signaturedorayme > In article > <6e4a700f-d9ca-4d48-9b90-300d3625c06d@k13g2000hse.googlegroups.com>, [quoted text clipped - 10 lines] > > <http://dorayme.890m.com/alt/offerToEatHat.html> Careful, unless you prefer a diet of felt. Disabled style or user stylesheet could be a play ;-) SignatureTake care, Jonathan ------------------- LITTLE WORKS STUDIO http://www.LittleWorksStudio.com > > In article > > <6e4a700f-d9ca-4d48-9b90-300d3625c06d@k13g2000hse.googlegroups.com>, [quoted text clipped - 13 lines] > 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. Signaturedorayme >>> In article >>> <6e4a700f-d9ca-4d48-9b90-300d3625c06d@k13g2000hse.googlegroups.com>, [quoted text clipped - 15 lines] > > True, I better take a small precaution, like cook a nice chocolate hat. Good plan! SignatureTake care, Jonathan ------------------- LITTLE WORKS STUDIO http://www.LittleWorksStudio.com >> In article >> <6e4a700f-d9ca-4d48-9b90-300d3625c06d@k13g2000hse.googlegroups.com>, [quoted text clipped - 13 lines] > 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. > In article > <6e4a700f-d9ca-4d48-9b90-300d3625c06d@k13g2000hse.googlegroups.com>, [quoted text clipped - 8 lines] > > get the <b></b> tags to work for all the lines! Surely there must be > > another way than having to apply <b></b> tags to each sentence??? May I suggest that the normal convention with quotes is either the use of italics, " 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></p> block element in CSS as p.QT {margin-left:49px; margin-right:49px;} with <p class="QT">...</p> containing 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 <br> element 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! SignatureTimothy 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 > May I suggest that the normal convention with quotes is either the > use of italics, " 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, " is bad practice, since the ASCII quotation mark " (which is what " means) is not a recommended quotation mark in any normal human language. (Besides, using " 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 <blockquote> for 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 <blockquote> is 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 > > May I suggest that the normal convention with quotes is either the > > use of italics, " marks or indented block. Personally I prefer [quoted text clipped - 11 lines] > 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 <blockquote> for block > quotations, and that's it. You change the rendering in CSS, if desired. [quoted text clipped - 6 lines] > 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... > > a blockquote element is recognised > > inside or outside block elements. > > 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... > > However, inline elements inside a > > blockquote element are reported as invalid unless the blockquote [quoted text clipped - 6 lines] > _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. > > 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. 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! > > 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. The original poster wanted bold, so here it is by this method; and it validates... SignatureTimothy 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 > Try parsing the statements in full... I do, and a combination of nonsensical sentences still does not make a full statement any more sensible. >> It seems that you are trying to say something about HTML syntax. >> Please learn it first. You are just confusing yourself, and maybe [quoted text clipped - 5 lines] > 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 " - and it works and validates, so thanks, I agree it's much easier to use - but it is a pain to discuss! [SNIP] > > Block elements inside the blockquote element actually do > > validate as HTML strict; [quoted text clipped - 6 lines] > 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/blockquote-valid-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/blockquote-valid-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? SignatureTimothy 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> Signaturedorayme [SNIP] > > 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. [SNIP] This arrangement I am talking about is also something I tested. IE: ...<body> <p> <blockquote> > You claim that the validator has a bug without <br> > 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. SignatureTimothy 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 > 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> > You claim that the validator has a bug without <br> > 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 <blockquote> implicitly closes an open <p> element, etc. Well, this has been explained so often, that it's probably in the W3C validator FAQ... Yucca > > 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. 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> [quoted text clipped - 4 lines] > > 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? SignatureTimothy 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 >> > I did this test yesterday, explained the conditions and outcomes, so >> > given that anyone can test this bug, I've provided all the evidence [quoted text clipped - 5 lines] > 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. SignatureChris F.A. Johnson <http://cfaj.freeshell.org> =================================================================== Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) > 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-- SignatureMy blog: http://shermspace.blogspot.com Cocoa programming in Perl: http://camelbones.sourceforge.net > >> > I did this test yesterday, explained the conditions and outcomes, so > >> > given that anyone can test this bug, I've provided all the evidence [quoted text clipped - 9 lines] > page that has 3 errors and 5 warnings and looks like this: > <http://cfaj.freeshell.org/testing/bq.jpg>? ROTFLOL! BTW, I did say it doesn't validate, .... What can I say? That was a deliberate act of sabotage on my part - some might call it standards-terrorism! This page was created to demonstrate how a single error is reported by the validator as three that don't quite state the problem - IE, by fixing only one error (the nesting), the other two errors go away as well. My point is that *_everyone_* who posts here has to know something about HTML, even if it is a simple fact like "HTML has something to do with web pages" - which it does! You see, even that is not complete ignorance. Besides, argumentum ad homenim is just intellectual thuggery combined with intellectual sleight of hand. If someone has a reason to disagree, they can state it without hiding behind the ignorance of the other person - and may I point out that those of us who are human are all ignorant to some degree. I'll repeat that: we all have gaps in our knowledge. This is such a definite and guaranteed aspect of the human condition that it speaks to glass houses when people take it upon themselves to accuse others of ignorance. Experience has taught me to distrust those who substitute substantiation with argumentum ad homenim. SignatureTimothy 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 <48c8e845$0$31806$afc38c87@news.optusnet.com.au>, "Number Eleven - GPEMC!" <eleven_is_the_number@timothycasey.info> wrote: > Experience has taught me to distrust those who substitute substantiation > with argumentum ad homenim. ad hominem. Actually, your phrase reminds me of an attempt to convince me that 9/11 was a US Govt inside job... i kept being referred to youTube speeches and demos. I protested that I was not keen on arguments by home video. Your phrase suggests home animations (which also featured)... Anyway, arguments ad hominem are not always bad ones if they are shorthand ways of delivering more forceful arguments. More often they are mere forms of abuse. But the term is not as clear as some people think it is. Signaturedorayme > "Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote 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 <p> on 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 </p> in 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. > > "Jukka K. Korpela" <jkorpela@cs.tut.fi> wrote in message > [...] [quoted text clipped - 18 lines] > Better for the validator to stick to what it's good at which is not > guessing what people meant. QED. I really think this point you make about the open paragraph element with no closing tag is sound. I'd forgotten about it because I never intentionally use it. It's a feature that I believe makes the mark-up unnecessarily complex to parse - and validation not so straightforward to interpret... Thanks for your perspective... SignatureTimothy 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 [...] > I really think this point you make about the open paragraph element with no > closing tag is sound. I'd forgotten about it because I never intentionally > use it. It's a feature that I believe makes the mark-up unnecessarily > complex to parse - and validation not so straightforward to interpret... Only the other day someone was asking if there was a tool to warn about things like unclosed <p>s. The proper way to do it is with a custom DTD, which Korpela has a page on his website explaining how to do. A couple of us also messed around with ways of doing it with regular expressions and/or sgrep. > [...] >> I really think this point you make about the open paragraph element with no [quoted text clipped - 10 lines] > A couple of us also messed around with ways of doing it with regular > expressions and/or sgrep. Or use that *linter* CSE HTML <del>Validator</del><ins>Linter</ins> ;-) SignatureTake care, Jonathan ------------------- LITTLE WORKS STUDIO http://www.LittleWorksStudio.com >> [...] >>> I really think this point you make about the open paragraph element with no [quoted text clipped - 12 lines] > > Or use that *linter* CSE HTML <del>Validator</del><ins>Linter</ins> ;-) And hope that its <del>features</del> <ins>bugs</ins> serendipitously correspond to the output you wanted :) >>> [...] >>>> I really think this point you make about the open paragraph element with no [quoted text clipped - 13 lines] > And hope that its <del>features</del> <ins>bugs</ins> serendipitously > correspond to the output you wanted :) <big>Exactly!</big> SignatureTake care, Jonathan ------------------- LITTLE WORKS STUDIO http://www.LittleWorksStudio.com On 10 Sep, 00:23, "Number Eleven - GPEMC!" <eleven_is_the_num...@timothycasey.info> wrote: > 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 Flavell's Law. > On 10 Sep, 00:23, "Number Eleven - GPEMC!" > <eleven_is_the_num...@timothycasey.info> wrote: [quoted text clipped - 4 lines] > > Flavell's Law. Flavell's Law says nothing of how, only that HTML tutorial pages tend not to validate. http://allmyfaqs.net/faq.pl?Flavell's_Law Which doesn't apply to pages intended not to validate because they were written to show how a particular error is reported - now how is a page like that supposed to validate if it is meant to flag a problem and specific errorset by presenting an error set the validator can raise? Other pages on this site intended to validate, do validate - and in this respect, the only thing in keeping with Flavell's Law is that the site doesn't offer a HTML tutorial - not anything in keeping with what you learn doing a teaching diploma. SignatureTimothy 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 > [SNIP] >> > Then the w3c validator has a bug or two but at the end of the day, it [quoted text clipped - 27 lines] > 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 <p> or <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 <p> in front of the blockquote-- the </p> is 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 <p> you didn't open-- the first <p> was 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. > > [SNIP] > >> > Then the w3c validator has a bug or two but at the end of the day, it [quoted text clipped - 30 lines] > 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. SignatureTimothy 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 > "Ben C" <spamspam@spam.eggs> wrote in message [...] >> I think the validator's output makes more sense when you realize that >> there are three different problems with the markup here. [quoted text clipped - 6 lines] > reason I am bringing this up is because this doesn't work for everyone. Not > everyone knows HTML like you or I do. Yes the validator could try to be more user-friendly and give more helpful error messages, but that's not a bug. It's also a harder problem to solve than it might look-- programs that try to guess what the author intended in order to give more friendly error messages often guess wrong, and then it's harder for the author to work back to what's really at the bottom of the problem. >> 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. I haven't been following all of this thread, but in the example you were just talking about, which was basically: <p> <blockquote> text </blockquote> </p> I didn't think the validator misidentified anything with the three errors it reported. On 10 Sep, 00:45, "Number Eleven - GPEMC!" <eleven_is_the_num...@timothycasey.info> wrote: [...] > > > This arrangement I am talking about is also something I tested. IE: > [quoted text clipped - 6 lines] > > > </p> > > > ...</body> [...] > > > See:http://web-design-1011.com/blockquote-bug.shtml > > > http://web-design-1011.com/blockquote-bug2.shtml [quoted text clipped - 14 lines] > 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. > > 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. 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 validator doesn't flag the nesting of the blockquote. The blockquote is not nested inside an p element, but inside the body element. > > However, it does flag normally valid content within the blockquote IE: 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> > > 1. The ";" in "> You claim that the validator has a bug without <br>" constitutes one error Yes, the validator says "character data is not allowed here". Only block-level content is allowed. > > 2. The "<br>" in "> You claim that the validator has a bug without <br>" constitutes another error being considered outside any block elements. The validator says "document type does not allow element "BR" here;...". The br element is an inline element and only block-level content is allowed within blockquote elements. > > 3. The validator then notices the end tag for the blockquote - but only in the context of an apparently missing start tag - which is not missing but improperly nested inside a block element other than a blockquote. No, the validator says "end tag for "BLOCKQUOTE" which is not finished". It is not complaining about a missing start tag. To finish the blockquote element an block-level element must occur one or more times within that blockquote element. "<!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- long quotation -->" <http://www.w3.org/TR/html401/struct/text.html#edef-BLOCKQUOTE> In "3.3 How to read the HTML DTD" it says: "( ... ) Delimits a group." and "A+ A must occur one or more times." <http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.3.3.1> You claim that the blockqoute element is "improperly nested inside a block element", but it isn't. The blockquote element is nested inside the body element. The p element before the blockquote element is closed. The end tag of the p element is optional, but the element is closet because it can't contain an block-level element. "End tag: optional" http://www.w3.org/TR/html401/struct/text.html#edef-P > > 4. Finally, the validator then notices the end tag for the paragraph There is no paragraph, the p element is already closed. > > - but only in the context of an apparently missing > > start tag No, the start tag is missing. If you want a new paragraph you have to open it. "Start tag: required" <http://www.w3.org/TR/html401/struct/text.html#edef-P> That's why the validator says "end tag for element "P" which is not open". > > - which is not missing but the entire paragraph improperly nests a blockquote. No, the first paragraph don't nest the blockquote. The end tag for the p element is optional and since the p element can't contain a block- level element it is closed before the blockquote. You should know that the blockquote element is an block-level element, if not, read an absolute novice beginner guide to HTML. I suggest "Head First", it has a lot of pictures. > On 10 Sep, 00:45, "Number Eleven - GPEMC!" > <eleven_is_the_num...@timothycasey.info> wrote: [SNIP] > Can you show one example where the validator is misidentifying an > error? [quoted text clipped - 6 lines] > The blockquote is not nested inside an p element, but inside the body > element. [SNIP] <body> [...] <p> <blockquote> > You claim that the validator has a bug without <br> > giving any evidence. </blockquote> </p> [...] </body> So what do you call this? Is it that you can only say the grandchild element is nested inside the parent but not the child element, in the context of HTML literature? To me, the body element in this invalid example, is parent to the paragraph element which in turn is parent to the blockquote element. So from the perspective of a programmer, the blockquote is nested, albeit invalidly, inside the paragraph, which is nested inside the body element. Can you not express it this way when discussing HTML? How then do you identify the immediate container or parent node when discussing structure? My point was that it is a single mark-up error that causes the validator to generate a report of three such errors, none of which explicitly describe the nesting problem - by way of commenting on the care with which one needs to interpret validator output. SignatureTimothy 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 10 Sep, 00:45, "Number Eleven - GPEMC!" [...] ><p> ><blockquote> [quoted text clipped - 4 lines] > [...] ></body> [...] > My point was that it is a single mark-up error that causes the validator to > generate a report of three such errors, none of which explicitly describe > the nesting problem - by way of commenting on the care with which one needs > to interpret validator output. No there are three errors, not one. The other two are: character data in the blockquote and no blocks in the blockquote. > > "Roy A." <royarneskar@gmail.com> wrote in message news:cd927f76-797b-4764-b9e8-4753f504e546@j22g2000hsf.googlegroups.com... > >> On 10 Sep, 00:45, "Number Eleven - GPEMC!" > [...] [quoted text clipped - 17 lines] > The other two are: character data in the blockquote and no blocks in the > blockquote. But there is a single solution that if applied without adressing the other two errors leaves the code in a condition in which no errors remain. Perhaps this can be taken to indicate a singular problem. You have a point - the other two are errors; but only because of that single problem with the nesting. I just saw your post (news:slrngcerp8.5av.spamspam@bowser.marioworld), which I think proves that the validator output on this is not a bug. Thanks for talking about the HTML instead of me... SignatureTimothy 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-11, Number Eleven - GPEMC! ><eleven_is_the_number@timothycasey.info> wrote: [quoted text clipped - 28 lines] > But there is a single solution that if applied without adressing the other > two errors leaves the code in a condition in which no errors remain. You mean moving the <p> to after the <blockquote>, and the </p> to before the </blockquote>? Yes that would work. > Perhaps this can be taken to indicate a singular problem. It could be. It's a bit of a grey area how many birds get killed by how many stones. On 11 Sep, 11:57, "Number Eleven - GPEMC!" <eleven_is_the_num...@timothycasey.info> wrote: > > <eleven_is_the_num...@timothycasey.info> wrote: > [SNIP] [quoted text clipped - 14 lines] > [...] > <p> You have an empty p element, that's allowed. > <blockquote> > > You claim that the validator has a bug without <br> > > giving any evidence. You have character data and a inline (text-level) element inside a blockquote element. That's invalid nesting. The validator flags those errors: -"Line 214, Column 5: character data is not allowed here" -"Line 214, Column 57: document type does not allow element "BR" here;..." Why is 'character data is not allowed here'? Well look it up. Since you're a programmer you could look at: http://www.w3.org/TR/REC-html40/index/elements.html http://www.w3.org/TR/REC-html40/struct/text.html#edef-BLOCKQUOTE There it is spelled out: -"BLOCKQUOTE is for long quotations (block-level content)" Why is it so that 'document type does not allow element "BR" here'? Well since you're using HTML 4.01 the validator is suggesting that you're missing an block-level element: - "...; missing one of "P", "H1", "H2", "H3", "H4", "H5", "H6", "PRE", "DIV", "ADDRESS" start-tag ." > </blockquote> If you didn't correct those errors, the validator is flagging another error: -"Line 216, Column 12: end tag for "BLOCKQUOTE" which is not finished ." Why isn't the "BLOCKQUOTE" finished? Well, if you don't know, the description might give you a hint: -"Another possibility is that you used an element which requires a child element that you did not include. Hence the parent element is "not finished", not complete." The validator is even telling you what they mean by the phrase 'not finished'. > </p> The last error flagged in your example, that you claim to be a bug is: -"Line 217, Column 3: end tag for element "P" which is not open ." Why is the validator telling you that the "P" element isn't open? The description says: -"This is often caused by a leftover end tag from an element that was removed during editing, or by an implicitly closed element" Only you know if the tag is removed during editing or if the error is caused by 'an implicitly closed element'. If you look up the p element: http://www.w3.org/TR/REC-html40/index/elements.html http://www.w3.org/TR/REC-html40/struct/text.html#edef-P You can see that an 'implicitly closed element' might be the case: -"Start tag: required, End tag: optional" -"It cannot contain block-level elements (including P itself)." So no, the blockquote element is not nested inside the p element. The content inside the blockquote is however, not nested inside an block- level element. > [...] > </body> > > So what do you call this? Is it that you can only say the grandchild element > is nested inside the parent but not the child element, No, I didn't say that. The first p element is nested directly inside the body element. The blockquote element is nested directly inside the body element. The last p element is not opened. It is missing the <p> start tag. > in the context of HTML literature? Which literature do you suggest? Something from Walt Disney? > To me, the body element in this invalid example, is parent > to the paragraph element which in turn is parent to the blockquote element. This isn't MSHTML. > So from the perspective of a programmer, the blockquote is nested, albeit > invalidly, inside the paragraph, No, just look at the DOM structure that this code produces. Some programmers are using the inside of their head. Although, this invalid code will lead to different DOM structures. > which is nested inside the body element. > Can you not express it this way when discussing HTML? Not if you are using HTML 4.01, and have to take in account 'implicitly closed elements'. > How then do you > identify the immediate container or parent node when discussing structure? By reading HTML literature, and by knowing which elements that can be 'implicitly closed' and when they are. Or by explicitly close those elements. > My point was that it is a single mark-up error that causes the validator to > generate a report of three such errors, The whole code is generating a report of four errors. Three is referring to an invalid nesting within the blockquote element. -"Line 214, Column 5: character data is not allowed here" -"Line 214, Column 57: document type does not allow element "BR" here;..." -"Line 216, Column 12: end tag for "BLOCKQUOTE" which is not finished ." The fourth error is referring to the '</p>' end tag, which could be a result of an invalid nested element. Only you can know that. -"Line 217, Column 3: end tag for element "P" which is not open ." The first '<p>' start tag isn't mention at all. It's valid. It's denoting an empty paragraph. But the validator has pointed you in the right direction, so it's up to you to figure it out. It's no need for the validator to make wild guesses. Anyway it's not a bug. > none of which explicitly describe > the nesting problem -"Line 217, Column 3: end tag for element "P" which is not open ." Isn't that a good enough suggestion that you might have a nesting problem? Only you can know if that is true or not. > - by way of commenting on the care with which one needs > to interpret validator output. The validator can't know what your intention was. It could be a nesting problem, or it could be a leftover end tag. But it isn't hard to make sense of an end tag that is not opened. There is no need for the validator to make random guesses. > On 11 Sep, 11:57, "Number Eleven - GPEMC!" > <eleven_is_the_num...@timothycasey.info> wrote: [SNIP] > > > The blockquote is not nested inside an p element, but inside the body > > > element. [quoted text clipped - 6 lines] > > You have an empty p element, that's allowed. [SNIP] QED Thanks, that was a great elaboration. I'd forgotten about the self-closing p element because I never intentionally use it. SignatureTimothy 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 > 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></b> do 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 |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.