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.
Related
I am making a site about coding, and I want my page heading to look like an opening function, and then to close the function at the end...
<h1>function myCodingPage(){</h1>
... page content ...
<h1>}; // myCodingPage ends</h1>
However, I am aware that the spec says NO! I must only have one H1. This got me thinking, that I could just style the second one to match the defined style of the first, but what if I did not want to specify the style of either? Maybe I can just use H2 instead...
So that is my question to the forum... are there any positive/negative implications of using H2 and up, instead of H1 and up in terms of accessibility (do screen-readers expect an h1 for example), SEO, standards compliance, non-standards common practice (will h2 titles be recognized as page titles by any advanced browser bookmarking systems etc...) or anything I have not yet considered?
Edit: updated since comments
Two valide points made in the comments...
It seems that two H1 tags are allowed in the spec (although I suspect there is a good reason not to which I can't currently identify).
Also, the second use of H1 is a decorative element, and not a heading in it's own right, so should not be a heading element at all.
In light of this, I would like to know
Are there any issues with using multiple h1 tags?
How exactly should I markup the mostly decorative second half of the heading?
Maybe I should have left this thread alone. But I guess other people may need to know this as well.
HTML is for meaning, not presentation. The h1 tag is meant to be the primary heading. You really can't have 2 "main" headings competing for attention, the same way you can't truly have two "best" friends.
Proper usage would be to use an h2, as it is a secondary heading. CSS could easily be changed to make the properties of the h1 and h2 the same, if necessary.
All HTML elements have a purpose. Clean, correct coding involves using the elements in the scope that they were meant for. That's why we don't use tables for site layout, and why we use <strong> and <em> instead of <b> and <i>.
Use HTML for purpose and meaning, and use CSS for presentation and styling.
I understand all these tags have different semantic meanings, like article is for a story that stand apart; section is for self-contained part of the page...
They are good and useful tags, in many ways. But, are they just syntax sugar? Because I didn't see any style differences among them. When not applied by any CSS rules, they are just like divs.
Hope some webkit/gecko experts can clarify it on the code level.
Mostly yes. They're not actually divs, but block level elements (subtle but different).
http://diveintohtml5.info/semantics.html#new-elements
There are several new elements defined in HTML5 which are block-level elements. That is, they can contain other block-level elements, and HTML5-compliant browsers will style them as display:block by default.
So yes, for now they are just there for shortening your code length and creating cleaner markup, but that's what block level elements do. If you remove the default styling from a <p> tag isn't it just like a <div>?
I didn't see any style differences among them. When not applied by any CSS rules, they are just like divs.
Each browser has it's own native stylesheet that is applied to the page content. This is why we commonly use CSS reset stylesheets - to normalize everything between different browser stylesheets. Style and content are two completely separate things, what something looks like has no bearing on what it is, therefore you should not be marking up your page based on how you want it to appear.
Some day, it may be common for browsers to add default style to certain HTML5 elements, like some padding on <section>s, but it doesn't matter (and is actually unlikely).
Are they just syntax sugar?
Not at all. While there may not seem to be much of a difference, it allows your content to be understood by, for example, screen readers or search engines, in a more meaningful way.
As Grillz's answer mentions, the elements in question are all block level elements, so in that respect - they are basically rendered like divs, but have semantic value and aren't meant to be used as generic container elements.
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.
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