Forum Moderators: open
In my document, I use several lists within the content, along with a table of data.
When validating my page as XHTML 1.0 Transitional, the validator kicks back errors when I try to encompass lists or tables with paragraph tags.
For instance:
<p>On this site you can learn about:
<ul>
<li>This; and</li>
<li>That</li>
</ul>
</p>
Does not validate. It wants the paragraph tag to come before the list, when the list is obviously a part of the first paragraph of the document.
What is the proper use of the <p> tag? I guess a list is not part of the paragraph that describes/leads to it? This makes no sense to me.
Please enlighten me :)
<p>On this site you can learn about:</p>
<ul>
<li>This; and</li>
<li>That</li>
</ul>
That should sort it out. If it helps any - I know what you're going through - I just designed and validated a site in xhtml strict and I'm finding that so many of my perceptions were very far off...
Funny, one of the most basic HTML tags is causing me a mess of problems. It just doesn't make sense that an element of a paragraph cannot be defined within the paragraph.
W3C say:
The P element represents a paragraph. It cannot contain block-level elements (including P itself).
If you want to arbitrary enclose block-level items inside others, use <div> rather than <p>.
Although I hate to do it, I eliminated <p> tags altogether.
It just doesn't make sense that an element of a paragraph cannot be defined within the paragraph.
A <p>...</p> marks up a paragraph of text. It doesn't include lists or tables or graphics.
It's perfectly correct to have a paragraph which reads On this site you can learn about: and then follow the paragraph with a list.
You can also enclose one or more of those blocks in a <div> to apply styling to all of them together.
Thanks, I know how to fix the code... I'm just confused about what the paragraph tag really stands for, and if I should even be using it.
Think of it this way: the <p> element represents any block of textual content which is followed by a hard return. If you think about other printed material (books etc), lists are usually set in this kind of way:
text
[hard return]
list item
list item
list item
[hard return]
text
However, the w3c rules are (here as elsewhere) the tiniest bit bizarre, in that they don't allow a list to appear inline in a paragraph (e.g. as in "I went out to buy milk, eggs, butter and bread"...) Do a google search for 'Taming Lists' for a kind of unsatisfying workaround.
-B
A list is a structure of somehow related ideas. Each one of its elements could be one paragraph or more than one.
However, the contrary (a list inside a paragraph) is quite against the grain of the nature of both, paragrahs and lists.
So, I'd choose to nest paragraphs inside list elements, even if they are only one idea at a time.
And I'd do so because when a list becomes 'more than one idea' is handy to divide it into more paragraphs and keep visual (ie: format) and structural coherence.
And if you don't like how separated the lines are, you can arrange that with css.
That's just my lay opinion, of course
Although I hate to do it, I eliminated <p> tags altogether.
That's a wrong thing to do as now your text won't be marked up properly. Also using <p> makes styling easy. (Eg: add a class or id to a <p> to style it differently.)
We must abide by the W3C rules as most of the time they make sense.
headings, paragraphs, lists, tables, or forms.
We must abide by the W3C rules as most of the time they make sense
Recommendations, not rules.
<p> is just a tag, and was presumably originally designed so that a html paragraph mimicked that in a commercial letter or academic document, i.e., with no indent and a blank line between paras.
Today with CSS we can style it how we like, e.g., to mimic the paragraph style used in books (idented with no inter-para space), but this is getting away from the original concept.
In my view <p> is still useful if you want the office-style para, but unneccesary otherwise.
edit_g: The div's should contain the elements listed and any other elements. So the divs contain the content, but the content is wrapped in the elements (p, li etc).
But I can define a div like this. Is that wrong?
<div>Some text here.</div>
HarryM: In my view <p> is still useful if you want the office-style para, but unneccesary otherwise.
I think you're missing the point. The tag declares what the text is, so that other devices (such as parsers, mobiles, search engines etc) will 'understand' that you intended the text to be classed as a paragraph.
I hardly ever use <p>'s, but my pages show up fine in mobiles. And I have never seen any evidence that SE's take any notice of <p> tags - it's the text the SE is interested in, not the layout.
But I would assume you'd need to use a lot more <div>, <span> and <br> tags to handle the visual styling. So why not take the easy way? <p> is one of the very handy and natural tools in the toolkit. And as tags go, a single-character tag is might economical and makes for very clean mark-up.
By the way, I have seen data (a bit over a year ago) that showed Google was ranking pages with "true" paragraphs a little bit higher than those without. But that is not likely to mean that the algo looks for <p> tags, but rather that authors you use proper paragraph elements are taking a bit more care all around, on the average.
It's even easier if there is an ID used on the tag - JavaScript code can go straight to it.
CSS can also make use of the 'document tree' to style elements directly.
Mine and other scripts depend on the user marking up paragraphs of text using... the 'paragraph' tag! Makes sense, doesn't it?
All I'm saying is that if everyone followed the recommendations (thanks for clarifying that!) web programs and authors would all be singing from the same hymn sheet.
Google was ranking pages with "true" paragraphs a little bit higher than those without
I remember Macguru saying something along those lines a year ago, in a thread along the lines of "why not just use H tags all the way".
tedster, if they wouldn't look for the <p> tags, are you suggesting there is other HTML involved or perhaps are they more interested in whats within the <p> tag (i.e. well structured paragraph/sentences).
I never forget that Google has some heavy duty semantic processing going on, and they are definitely aiming to rank information pages well. The density for various parts of speech will be quite different if you compare an information/article page to a sales-blurb/fragment/slogan page.
This thread exemplifies the differences between thinking of HTML as a "layout program" of some kind, and using it as a "mark-up language". And once you get the point - that the ML stands for "mark-up language" - then all manner of mysteries just dissolve.
You start with a document and you "mark it up" for the web. That's been the concept from the start, despite the illusions that WYSIWYG editors try to create.
When you get to XML, everything has to be inside a tag or it won't get processed.
This thread exemplifies the differences between thinking of HTML as a "layout program" of some kind, and using it as a "mark-up language".
I agree. But I suspect in the majority of cases web pages are created with a view to layout rather than mark-up, and I confess that is the category to which my pages belong.
As for using <p> tags to allow someone to run a js program so it can mess with my text - that's just given me another good reason not to use them! :)
I think that trying to get people to use 'correct' markup is flogging a dead horse. (Except of course XML, but that's a different issue.) How would the js cope with the page I saw today where the only <p> tags used in the page were used to force a vertical gap between tables? <p> </p> It's a big world out there, and I suspect only a small proportion of webdesigners have even heard of W3C.
Oh. Look I repeated the first sentence of message #7 in message #11 and now I'll repeat the second sentence of message #7 again here:
You can also enclose one or more of those blocks in a <div> to apply styling to all of them together.
But if someone comes to a forum such as this and asks about validation and browser behavior, then they must come to terms with the whole nine-yards: valid mark-up, css, standards mode rendering and so on. Why? Because that's where the answers lie, and that's why we're here - to help people become more professional and to discuss things among professionals.
Yes, it takes some home schooling to get on top of all this. But it's really worth it if you intend to develop web pages into the future. Once you understand, your job just gets easier and easier.
Street code will always be around, I think, but less and less in the truly professional ranks. It was only bad browsers that slowed down the process, because when valid code didn't work, people who needed to get a job done were forced to work "outside the law."
You can include text in a div without the need to wrap it in any other tags. It will validate at W3C which is what I take to be the ultimate criteria.
Tedster,
If you are referring to my example of <p> </p> as "street code", it may not meet your personal criteria of what is ideal, but it works, all browsers should understand it, and it validates.
To be a professional is to understand that standards are not the be all and end all. Standards are to be followed as long as they are useful. As any technology forges ahead some formal standards become obsolete and new competing industry standards emerge. Later, after the usual bloodshed, the standard with the strongest backers becomes established as the norm. Standards follow technology, not the reverse, and any attempt to impose anything that is perceived as an artificial restriction is bound to fail.
Excessive use of <span> tags is often a sign of "street code" - and yes, misuse of <p> or or <br> are often rampant, as well as nesting errors, completely redundant mark-up and so on.
But the most common, defining feature fof what I call street code is that it is wasteful, full of "tag debris" from false starts in development and so on.
What's the big deal about using <p> tags, anyway? They are incredibly intuitive and economical, no <span> tags required. And they certainly help make site maintenance easy.
I guess you could say that I'm talking more about best practices than I am about "standards" because there have been and still are some very silly parts in the W3C recommendations. The fact that a "paragraph" cannot contain a "list" (as the opening post mentions) is one of them, IMO.
The analogy between best practices and HTML is something like the relationship of grammar to a written language - or even a stylebook like the Chicago Manual of Style. Yes, poor grammar and spelling can still communicate, and used consciously and intentionally such "rule-breaking" may even communicate well. But that's for E. E. Cummings or James Joyce. If you want many people to understand what you're saying, then some best practices will come in very handy.
I think that a paragraph is a meaning related tag that has the same sense that it has in human language: A set of words that explain one meaningful idea (more or less...).
That's more or less correct according to Merriam-Webster's:
a subdivision of a written composition that consists of one or more sentences, deals with one point or gives the words of one speaker
However, the proper reference here is not so much a dictionary but a style manual. The Chicago Manual of Style, one of the most authoritative style manuals, says the the following (15th ed, section 2.90) with regard to typesetting tags:
Each tag has a name and is aplied to either the paragraph level or the character level. A paragraph is defined as any string of text that follows a hard return and ends with a hard return.
In that sense, the HTML Recs just follow long-standing recommendations made by style manuals with long traditions behind them.
Tom
<i>"However, the proper reference here is not so much a dictionary but a style manual."</i> I beg to disagree about a 50% ;)
You can judge or take any act of comunication from two points of view: Message and form. You say that a given form makes something a paragraph and that could be right but it has two troubles:
1. Function defines form and not the other way round.
2. That definition forgets the 'message' part in comunication (that was what I tried to point to).
As it comes that in web comunication you can bend the formal rules as you like with css (something that Chicago Style handbook cannot take into count), that formal definition fells quite short.
To me a paragraph (html tag or following typographic conventions) is a simple way of giving <b>form</b> to a functional element of human thought (ie: ideas).
I think that if we forget that then it has no sense, for example, to make recommendations about writing short phrases and concise paragraphs, does it?
So, I think I am a paragraphilic ;)
[PS. Forgive me my broken English, please]
Me: >> msg#12: What about divs? <<g1smd: Oh. Look I repeated the first sentence of message #7 in message #11 and now I'll repeat the second sentence of message #7 again here:
You can also enclose one or more of those blocks in a <div> to apply styling to all of them together.
I meant what about divs with no other tags inside them - pure text. I even gave a clear example later on, which I will repeat here:
<div>Some text here.</div>
Perhaps I made a poor choice of words. I did not mean that a style manual should be the appropriate reference, but that it is the appropriate reference for understanding the thinking behind the Recs. Nothing more than that.
Let me explain. I've noticed that when I come across something that seems foolish in the W3C Recs, most notably the box model, it is usually something that comes out of some earlier non-web tradition. The Recs were not thought up in a vacuum, but in reference to pre-existing recs and standards in other domains (for example. print).
So the box model and the paragraph model don't seem to be logical, but I think the W3C trying was to look at existing models for analogous tasks and to try to follow those when possible. So when looking to understand the why of some of the W3C Recs, I find that looking to the way things were done in the print world prior to the creation of the web usually explains things.
If you do that, you see that the W3C was looking at the paragraph from the point of view of a compositor, not a linguist, thus the proper reference for understanding the thinking behind the Recs is the style manual, not the dictionary.
I fully understand that you can argue that the web is a new medium and that one should not cleave to prior traditions. I'm being agnostic about that, just trying to point out where people should look if they want to understand the traditions that the Recs draw on.
Make sense?
Tom
