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
Related
First of all, I realize that styling in HTML should be handled by CSS, and I don't want to change that.
I just want a solid tag I can use for underline, a tag that is meant for underlined text, or one that makes sense to use as such. Then I can style it with CSS.
Now where is that tag?
Why is strong, b, em, i etc. perfectly fine (and often auto-styled in browsers), but underlined is the forbidden fruit?
I would hate to write
<span style="blabla: underline">some underlined text</span>
OR <span class="underlined">some text</span>
when I can just use
<u>hello</u>
and style it?
The u element was meant for underlining, ever since HTML 3.2. HTML 4.01 frowns upon it by “deprecating” it, and HTML5 proposes to redefine its meaning in an obscure manner. Yet, in reality, it works in all browsers, and will keep working, and has the exact effect of underlining.
Whether you should underline anything but links on web pages is a different issue. So is the question whether you should think in terms of logical structure rather than visual rendering.
Underlining text is generally a bad idea because it should be exclusively reserved for links. Users just generally expect to be able to clock on underlined text and have something happen.
That said, there is one main exception I can think of:
Price: <del>£12.34</del> <ins>£9.87</ins>!
Most, if not all browsers will render the new price there with an underline, and people will understand it to be an insertion.
I think the whole issue is better approached if we try to understand what the HTML spec writers are trying to accomplish.
On the early days, HTML was basically the only tool to create hypertext documents so it tried to provide all the necessary stuff. As the web grew up it soon become obvious that this all-in-one solution did not scale. Mixing content and presentation didn't provide full control on either. So two steps were taken:
A new language was created to take care of visuals
HTML itself was cleaned up to focus on content definition
The problem with underline is that it doesn't really have any meaning by itself. It will have a meaning if you assign it one in your app context (you can decide, for instance, that underline text will be used for book authors in your on-line library catalogue). So when the guys at W3C created HTML tags for several content types (titles, abbreviations, dates...) they simply didn't consider underlining: it was deliberately outside the language scope. There's no HTML tag for "underline" for the same reason that there's no tag for "red circle" or "uppercase Comic-Sans text".
Of course, in fact there is a <u> tag but underline is only a serving suggestion because the important part is the semantics—like printing <h1> with a large font.
It is not forbidden , but a better practice not to use it ,as underline tag is deprecated in HTML 4 http://www.w3.org/TR/REC-html40/present/graphics.html#edef-U so won't validate.
Underline an element is more a style quetion. So, it's better to give a class like "underline_style" and in the CSS give the correct rules.
The u element you can still use for underlining but because it's more complex than b, i,strong and em you will need CSS to style it in detail. Underline has style and color property which is not the case with other mentioned elements. You have more on this topic here.
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.
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.
As we are moving on to HTML5, there are some tags which now hold a very least importance that it did in the past.For example <dl> the defination list, I dont remember the last time used this tag.
And not only this, but there are tags which have a better and more efficient versions or just clear redundancy like <strong> and <b>, <basefont> and <font> etc.
In your Opinion, which are the tags that as a developer you can live out with?, and Which are the tags which can be ignored? because we have a better version.
B and STRONG are not the same thing, and neither are I and EM.
EM means that the text shoud be emphasised. This thus says something about how the text should be interpreted, and this is understood by screen-readers (text-to-speach), etc. It has a logical meaning. I, on the other hand, says nothing about the semantics -- it simply tells the HTML renderer to render the text in italic. Hence, in text, to make an emphasis, use EM. If you for some reason need a bit of text to be in italic without this implying that the text should be emphasised, then you can use I.
The same things applies to STRONG and B.
However, I really dislike FONT, because it says nothing about the semantics. Use Hn for headers, EM for emphasis, CODE for code, etc. If you lack some tag for some context, define a CSS rule like
<p class="footer">...</p>
or
<p>This is <strong class="extraordinaryEmphasis">extremely</strong> important.</p>
It was suggested I make this an answer, so here is an excellent page that discusses which tags and attributes should be avoided in HTML5 pages, and why, though he doesn't include elements like the blink tag.
http://www.html-5.com/avoid/
STRONG and B have distinct semantic meaning now. There was a lot of effort to clean up semantically-ambiguous elements like that. Even HR got some attention.
I use DL all the time, personally. It my workhorse KeyValuePair type. I sometimes find myself wishing it had more rigorous semantics, but then other times I'm thankful for its flexibility in allowing me to define its semantics contextually.
I suppose it depends on your definition of 'useless', which I take to mean 'having no practical use whatsoever'. I don't really know of any element in HTML5 I could say that I'll never use under any circumstances.
P should be abandoned. No Joke. It creates artificial breaks in flowing text that can be better reproduced with a line break. Is there a P tag on a typewriter? What follows is that it becomes a "text container" that we've become dependent on for no good reason. Paragraph is a stylistic flow marker only. At most it should be a singleton tag.
In CSS, I use it simply as a text-area container, a designation which is similar to SPAN except in block form. The P should really be a TEXTSPAN tag that can be parent to multiple spans, but not to itself. We are often forced to store some representation of P in databases, which then are impossible to reconstruct for display. Again, a double line break is much more appealing and universal.
:-)
<code> is useless. Unless maybe you a perl one-liner fan. It should have been a semantic way to create a <pre> block - that would have been useful.
<embed> is useless. It is redundant to <object> and less capable than <object>
<small> is useless. It has no semantic meaning and should be done with CSS.
Those are my opinions of the three most useless tags that made it into the HTML5 spec.
I think that anything that indicates something that should be done in CSS is probably something that should be avoided. This includes
<b>,<strong>
<i>,<em>
<center>
<u>,<strike>
My least favourite has be to <font>, as it has absoutely no meaning, and should, in all instances be replaced with a tag.
Personally, I think it's also good to avoid HTML attributes that should be done with CSS such as "color" and "border".
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.