I create a semantically and logically correct HTML5 document with a concious created document outline to satisfy search engines and other software which take advantage of element semantics.
The <p> element -
I know I should not take its name, paragraph, too literally, but I am not sure If I should use it to wrap every text-node in the document?
Generally asked, should I wrap every text-node in the DOM with a <p> element, even the smallest text portions, or may I just write them down in the document?
If you look at the definition of a paragraph in the HTML5 spec, you'll see several examples of pieces of text not wrapped in <p> tags. So no, there is no requirement to wrap every scrap of text in <p> tags.
I just recently came across the same problem when I was working on making my own grid. Up until now I taught tags were optional. And as far as I know they are. However I seem to be wrong about something. When I have:
<div>xyz</div>
I taught this was technically the same as:
<div><p>xyz</p></div>
But when I try to style it like
div > p {color: red}
The div with the p element works, but the one without doesn't. So it seems at least to me that they are not identical.
As a short answer to your question, I would recommend using P element around text when you are sure you will need to style it based on its parent. like in this case, the parent being a div. Otherwise for the most part you will get away with it. But its caveats like this that will come back to bite you later. I have an arguably "bad" habit of not using P tags unless I really need them because technically they are optional. But that's just me.
If this answer is not 100% correct, please let me know in comment instead of just voting down as I would like to learn the "correct" way as much as anyone else. So this is as much a question as it is an answer cause I am not 100% sure too. I'm left to thinking it is a matter of preference unless necessity dictates otherwise as in the case of styling above. But I would like to know what others think on this too.
Related
I have some HTML that looks like this:
<div class="position-container">
<div class="top-position">1</div>
<div class="current-position">2</div>
</div>
I won't bother adding the style here, but basically the 1 and 2 are each block elements with specific background colors. Some dude I work for doesn't like me using so many divs, so he wants me to change the first div in "position-container" to <strong> and the second to <em> and then change their display to block.
I was under the impression that those elements should be used within a block of text to indicate emphasis within a given context. I also thought they were semantically to be used in an inline manner. Am I off the mark? Should I really just be arbitrarily throwing around <strong> and <em> tags once my <div> count gets a bit high?
The problem shouldn't be that you have too many HTML elements that are divs, but the problem arises if you have too many HTML elements tout court.
"Some dude" in your story is, then, wrong in my opinion. In some cases - and possibly for some SEO benefits - some HTML elements are preferred over others, but you can't just look at a HTML page and say "Well, I see so many div tags, why not change this to that and that to this and it looks prettier!"
The thing I would look at is: how can I make my HTML structure more semantically logical. This would probably involve all te new HTML5 elements. The use of section, article, aside, nav and role attributes make a page much more intuitive and logical. Basically, with HTML5 you can show a person that knows nothing of webcoding the code of your HTML5 page and by simply looking at the tags you used, he can easily derive what is important and what not. That's the beauty of HTML5.
So, before randomly starting to change some div tags to strong tags, consider HTML5. And you might also want to ask WHY "some dude" wants you to change it. Maybe he does have a legitmate reason, you never know!
Strong and Em are inline tags that should be used to either bold or add italics to words themselves. That's basically it. They shouldn't be block elements. Not really their purpose.
The guy saying you have too many divs, and recommending the used of either strong or em as block elements to alleviate this issue is incredibly off base in their approach.
I would recommend, to at least offer up something different, use HTML5 element tags such as article, section, header, footer, etc. to make the code a little more readable. Assuming that's what you're looking for.
If you need to support older browsers that don't recognize newer tags. Take a look at something like Modernizr.js.
Note: I am NOT talking about the display - I understand why they have different defaults. I'm talking about the functional differences between blocks and inline elements, esp. in regards to things like nesting
I've been told time and again that HTML is about describing content, what things do and what things are, not what they look like (beyond default stylistic elements associated with tags, that can be changed).
As such, it seems like the division between "block"-level tags and "inline"-level tags (not the display of those tags, but the inherent difference in those tags), something that trips up and complicated a great many neophyte and even more experience page designers, is arbitrary and... seemingly against principle, if you would. This sort of behaviour seems like something that should by controlled stylistically, not exist as a built-in element of a block. And in some ways, it IS controlled stylistically - we all know there is CSS that can make a span look like a div, and vice-versa.
So what is the point of having the functional distinction between blocks and inlines? Why aren't they just like any other nested element? Why isn't everything a "block" with "inline" elements simply set to "display: inline"? Is it just for, say, backwards compatibility, or is there a benefit to this seemingly arbitrary division that I'm just not seeing?
Note, this might be better as a community wiki question, since it's unlikely to have a single clear answer, but I'm not exactly sure on the details.
As an example, from what I understand, the following would be invalid html:
<label style="display:block">
<h4>Name</h4>
<span class='sub'>Whether legal, pseudonymous, or made up</span>
<input id="name"></input>
</label>
Why?
Why isn't everything a "block" with "inline" elements simply set to "display: inline"?
Well, it almost kind of is; just the inverse. Rather, everything is "inline" with "block" elements set to "display: block".
But that would be really annoying, if for every page you create, you need to tell it that div tags should be treated as block elements. So for that reason, default styles are assumed, best illustrated at http://www.w3.org/TR/CSS2/sample.html
This question already has answers here:
Which is more correct: <h1><a>...</a></h1> OR <a><h1>...</h1></a>
(9 answers)
Closed 8 years ago.
I'm wondering which of the following two orders is semantically correct in HTML:
1. <h1><a>Header</a></h1>
2. <a><h1>Header</h1></a>
<h1><a>Header</a></h1>
<h1> is a block-level element and <a> is not, it is syntactically invalid HTML to have block level elements inside inline elements (at least until HTML5) which is how the other way would be.
This answer on a duplicate question is better than mine: https://stackoverflow.com/a/7023551/20578
But, for posterity:
Semantically, there’s no difference. Remember, “semantic” just means “related to meaning”, and meaning is just something agreed between humans (because computers don’t natively do meaning, that’s a human brain thing). No-one’s got time to agree that one of these virtually identical options means something different to the other :)
Surprisingly, they’re actually both valid as well, as of the current HTML spec, because <a>’s content model is defined as “transparent”, i.e. the same as its parent.
See:
http://www.pauldwaite.co.uk/test-pages/5341451
And:
http://html5.validator.nu/?doc=http%3A%2F%2Fwww.pauldwaite.co.uk%2Ftest-pages%2F5341451%2F&showsource=yes
(That assumes that <a>’s parent can have an <h1> as its child)
However, it’s not valid under previous versions of HTML:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.pauldwaite.co.uk%2Ftest-pages%2F5341451&charset=%28detect+automatically%29&doctype=HTML+4.01+Transitional&group=0
From a semantic perspective: both (or neither).
(From a structural perspective, OTOH, before HTML 5 an anchor cannot contain a heading, and since browsers aren't all HTML 5 capable yet you should avoid the new form of the construct where possible)
If you are creating a link target, then <h1 id="target_name"> is preferred to <h1><a name="target_name"> anyway.
If you are creating a hyperlink, then having the most important heading on the page link somewhere else is somewhat dubious from a semantic point of view.
I'd say <h1><a>, because <h*> are block elements and <a> is inline element, so it seems more natural to keep the inline element inside a div block, not the other way round.
The header should be first in my opinion but I doubt that search engines would really mind what way round they are, inside the H1 just seems cleaner to me...
Since h1 does not directly correspond to a viewable object they both are correct.
I see the <p> tag used a lot in the code of others but have never used it in my own work.
I'm wondering what advantage this gives over using a <div> tag?
Are there any benefits I could get
from incorporating the <p> tag
into my pages?
Is there any disadvantage in only
using <div> tags without <p>?
DIV indicates a separate section on a page, which is not semantically connected to the others. With P tags you indicate that this piece of text is broken into paragraphs but it still stays a single entity.
ADDED: With "semantics" people usually refer to the possibility to extract information from HTML as to what various elements of a page represent and how they are related to each other, as opposed to treating the whole HTML as just a markup to be rendered. For example, when you do menus it is recommended that you use ULs (unordered list) for that purpose, because it will be possible to learn from the markup that all LIs (list items) contained within a particular list probably mean choice options of the same level. I know it is helpful for screen readers for impaired people that you try to make your markup as semantic-rich as possible.
If you're not concerned with this, then it is virtually no difference for the rendered result whether you use DIVs or Ps. You can style both with CSS to achieve the same look and feel.
Semantic HTML is still not "the absolute good" to be strived for. For many people semantics does not add any value as they wish just that their pages are rendered correctly. That's why the ever-lasting discussion on whether to use tables for markup (and add semantics where it does not belong) or stick to CSS is not going to end any soon.
p means 'paragraph', div means 'division'. That's as complicated as it gets. It's a way of telling search-engines, scrapers, tools, etc that this is a paragraph of text.
div is undesirable when you're actually marking up a 'paragraph' of text.
Both tags have a different purpose.
p indicates a paragraph, usually for
organising content (text and
images,mostly)
div on the other hand is a
rectangular space on the canvas,
usually for layout purposes.
Example: You would put your navigation panel in a div, making it easy to move it from the left to the right of the page, or switching to a 3 column layout. The different sections in your navigation (first the general site navigation, next specific hotlinks to the most recent blog post or whatever) could be seperated by putting them in defferent paragraphs.
(I know, bad example, because the navigation is better represented by unordered lists, but what the hey).
In direct answer to your question, they give you the advantage of differentiating between organising your layout and organising your content, in a way that becomes clear in the HTML source.
If you are tagging content so you can lay it out with CSS, you probably want <div>; <p> should be used to indicate a paragraph of text and that's it.
Beyond just the semantics of it (which are important), you will also want to consider validation problems. According to the HTML4 spec, you are not allowed to nest other block-level elements (<div>, <ul>, other <p>, etc) inside a <p> without invalidating your HTML.
I've seen a number of instances where parsers will choose to prematurely close the <p> to allow the other nested block element to begin.
Are there any benefits I could get
from incorporating the tag into my
pages?
Yes, provided that you use it correctly -- because the use of semantic HTML is always a benefit.
There are a range of reasons why this is so, but the primary one for people who need a quick explanation is SEO. Search engines will understand your page better if you use semantic HTML.
p tags are for paragraphs. p tags often contain additional CSS styling regarding the textual content that goes into them, and this styling can be defined in various places in the css documentation. for example, a p usually has a bit of extra space below it. if you try laying something out with p tags, you'll end up with uneven padding.
It is better to use divs if you want to have more control over the content in your page from a programmatic perspective. sticking to divs for all layout concerns will also allow you to use p tags exclusively for paragraphs.
Is there any benefit in using a <blockquote> element over a <div>? I was looking at a website's markup to learn CSS and I couldn't figure out why the <blockquote> was being used.
EDIT: Yeah sorry I didn't clarify, it was used to hold the <div> tag with username as 'text' and an input tag. There was clearly no quote.
Semantically, a blockquote tag makes sense when you're quoting something. Sure, a stylized div can do the same thing, but why not use the right tag for the job?
Additionally, the blockquote tag allows you to include a citation with the cite attribute.
In theory, HTML should be as "semantic" as possible - meaning that every element should indicate something about its content. <h1>s should enclose the most important headline; <p>s should surround paragraphs; <em> should indicate emphasis, etc.
That way the code makes sense when you - or a screen reader, or whatever - look at it. This also helps for devices that don't understand all (or any) of your CSS rules.
<blockquote> should be used when the text it contains is a block quote. This sounds very obvious to me, so is there another aspect to your question?
As mentioned, <blockquote> is for quoting. Similarly you will use several <p> blocks for paragraphs within one <div> that holds page content or whatever. HTML5 proposal will have lot more block elements (i.e same as divs) which purpose will be to add a semantic info about it, such as header, footer, menu, etc.
As mentioned earlier, blockquotes are for quotes. Just like tables are (arguably) for tabular data, lists are for listings, divs for divisions, p for paragraphs, etc.
Sure, you could almost everything with divs. That's the beauty of using HTML with CSS: you can make anything look however you want it to look (in theory, in the real world browser quirks mess that up sometimes).
Using divs for anything you can think of is commonly known as 'divitis'. See this article for a little explanation :)
The likely reason they're using blockquote is that many people dabbling in HTML don't know enough about CSS to know that a div can be given the same left-margin as blockquote renders with by default.
Easy peasy, right? Nothing has really changed. Remember that as is a ‘block-level element’ (flow content) we can put most anything in it, including headers, images, and tables, in addition to the usual paragraphs of text. There are a couple of slight differences in HTML5 though. is a sectioning root, meaning that any - elements it contains don’t become part of the document’s outline. Also, adding a single paragraph of text with no enclosing tags is now completely kosher. Here are some simple examples (apologies for the fake content):
The suggestions in my article came directly from writing and editing a few megs worth of raw text used on my website, which bought up lots of edge-cases and curious questions about semantics; so whilst I wouldn’t say my choices would suit everybody, they have at least been trialed in a background of the text.
My complaint about the ABBR article you published here on HTML5Doctor was essential that you weren’t following your own advice, as I know that I practically went insane trying to use those rules on megs of text before I came up with my own to take back control of my sanity.
But, I will definitely say that cite still remains the weaker out of the three and I appreciate this article for being far more square.
If you would like, my article could be further adapted with feedback from the doctors to better suit a broader audience. I strongly believe that a key part of learning HTML5 is learning HTML4 properly and eschewing spans and divs for semantics where possible