Is it considered bad style to use <br>? I have a text element that I would like to break up into two lines, is there a more recommended way to do this or a different element I should use?
The question you need to ask is, why do you need to break up the line?
If it's to make it fit in a space,
you need to use CSS to set word
wrapping and width values.
If it's because they are distinct
paragraphs, use the <p> tag.
If it's because you need to show a
visually distinct sample of
something, set display: block with
CSS.
Otherwise, it might be okay. What's the reason for the break?
You want to be as semantically correct as possible, and you want to separate presentation from content.
Semantically, the break tag is intended to convey a natural break in the flow of information - it's a little vague, but the idea is to use it when you need to indicate that there is a logical separation between elements but that they are still part of the same general context.
For instance I might have fieldsets styled so that they layout inline, racking up horizontally. In that scenario if I wanted to separate two fieldsets in the same form, I'd likely use a break tag. It indicates both visually and semantically that the fieldsets are still part of the same context but that there is some concept of seperation between them.
Another, probably better example: the address element.
<address>
<p>
123 Main Street<br/>
Townsville, USA 12345
</p>
</address>
The spec equates it to a carriage return. http://www.w3.org/TR/html401/struct/text.html
They're only 'bad' when you're using them for layout - i.e.: multiple breaks to emulate spacing that should really be handled in a cosmetic layer (like CSS).
Related
In general, I try to use semantic html to improve accessability. However, I'm working in an existing codebase and noticing that a lot of single-line text used in the layout is placed directly in <div> tags, to avoid the bottom margin that comes with <p> tags.
<div>Team Average is 20%.</div>
Does this have direct accessibility implications, and if so, what are they? Will using <p> tags and adding a style rule to each one to get rid of the bottom margin produce distinct accessibility benefits? (I realize I could just set p elements to have no padding via CSS, but as this is an existing codebase, that isn't an option.)
I also realize I should use more semantic html where possible; this is just in situations where nothing more specific applies.
In my experience, assistive technology will function better, and the page will be more understandable when text is placed in paragraph tags, as opposed to divs.
Divs seem to be treated more like raw text. If the div uses line breaks to simulate paragraphs, then the visitor will be unable to easily skip paragraphs or move between paragraphs without listening to the contents of the entire div.
Using divs instead of paragraph tags is definitely sub-optimal. Whether or not it's a failure of WCAG 1.3.1 is debatable. If it's relatively easy to change this out, it would be better to do so.
W3Cschools said "Any sort of content can be put inside the tag!" (https://www.w3schools.com/tags/tag_div.ASP) and in my experience there's no accessibility issues related to this.
DIV are for a division of space and it's no rules about their content however it's best for design to have html elements inside of if.
If you are concerned about accessibility rules i suggest you to check your website with some tools like the following ones:
aXe
Wave
Google Lighthouse
Valmolà
If it's a single-line text, then it will not be a problem.
If the text has more than 1 paragraph, then you should use <p> tags.
To make a divider in one specific design where I'm working, I need to make a divider between groups of multiple elements. I have only 2 options: either I can wrap elements (inner elements are not same in height) inside a <div>, or I can use an <hr>.
If I use an extra div, it will be only to make a separator.
Which is more semantic, one extra div or hr?
If the dividing lines are part of the content, then <hr> is definitely the appropriate answer.
However, a dividing line could be considered as a design element, in which case it shouldn't be in the HTML code; design should be done in stylesheets.
So the question is whether the dividing lines you plan to draw are part of the content or the design?
You can answer this question by considering whether removing the dividing lines would affect the content in the same way as removing <br> tags would do. Or by considering if you had to give the content to someone else to publish elsewhere, whether you would want to include the dividing lines as part of what you send. If the answer is 'yes', then they are part of your content.
If it's purely a case of it being your page design, then you should use stylesheets to add dividers because although <hr> is more semantic, it is only semantically correct if it forms an active part of the content.
You say you can wrap inner elements in a <div>, but that the <div> would only serve as a separator. If it has inner elements, it seems as though you may be using it to group related content, in which case I would suggest that as the most semantic approach. Otherwise, <hr> is your best option.
It seems that (strict) html doesn't allow nesting any non-inline elements inside a <p>, but then how am I supposed to render a paragraph that contains a list (something that occurs often in natural texts). I've seen three answers that all seem unsatisfying:
Lists should not happen inside paragraphs. (I'm not going to go into a cultural debate, but I certainly hope that html is not going to become the place to dictate writing style.)
Separate the text into a paragraph, then a list, and then a second paragraph with the post-text. This looks bad because now I have <p> chunks that are parts of paragraphs, and that seems bad for a markup that is trying to to move in a more semantic direction.
Fake paragraphs using some <div class="mypara"> — which looks like a bad way to bypass the whole thing and give up on using the markup with the proper semantics for text.
Is there some other way to do this that is semantically correct and valid?
Paragraphs in HTML 5, as of the latest working draft, are defined as flow elements which can contain phrasing elements only. Lists are also defined as flow elements, and may not be enclosed in paragraphs. Whatever you think the definition of paragraph should be, this is the formal definition of the term in HTML, and I think it's unlikely to change.
There are two possibilities that you might consider besides the two you've mentioned:
Consider reaching for a more broad-reaching flow element than paragraph if it applies, such as section, nav, header, footer, or article.
Use a hybrid approach: wrap the p – ol – p sequence with a div of your choosing that applies common formatting to the set.
As far as div goes, the HTML 5 spec clearly recommends that it should be a "last resort" element because it doesn't bear semantic meaning in the way that other HTML elements do, and may not be as user-friendly in alternative user agents. Going by this advice, I wouldn't use div at the cost of p for body text if semantics are important to you. However, it can be useful in making sure that the use of multiple paragraphs does not get too visually choppy.
I don't think the html <p> tag is meant to control the idioms of actual writing styles. It is simpy a way to display a chunk of text in an orderly manner. I don't believe it is meant to simulate printed material. You will have to use a Div for this one.
Is there a visual style reason behind all this? In other words when you have something like the following, is it visually rendering in a way that you do not find ideal?
<p>Some paragraph text.</p>
<ul>
<li>First list item</li>
<li>Second list item</li>
<li>Third list item</li>
</ul>
<p>Another paragraph.</p>
If the problem is too much margin after the P and before the UL, then you can try an adjacent sibling selector like this to compensate:
p + ul { margin-top: -1em; }
I suppose it depends on what you consider to be a "paragraph". It is obvious to me that the designers of HTML in no way consider a list to be part of a paragraph. And while I think an argument could be made for either interpretation, I'm of the opinion that the spec is correct.
While a list doesn't represent a break in line of thought, it certainly represents a change in voice or method of thought, which I believe merits a new semantic container.
In the same vein, a paragraph represents a logical partition in a piece of writing. A list represents a sequence of logical partitions, and while it is imaginable that one logical partition may be then divided into more partitions, it makes more sense to simply create a new partition (especially for such a large break in the voice/method).
Semantics can be largely subjective. And that's fine. However, in this case, I'm of the opinion that the HTML spec correctly represents the semantics.
The answer to your question is obviously no, because the specs say you can't do it. Like you, I like to maintain semantics, so I usually go with your 2nd option (paragraph, list, another paragraph). However, off the top of my head, I can't think of any text where the list doesn't actually break the flow of text, so it seems that starting a new paragraph after a list can't hurt.
The span element seems to be exactly like a div, but at the in-line level rather than at the block level. However, I can't seem to think of any beneficial logical divisions that the span element can provide.
A single sentence, or word if not contained in a sentence, seems to be the smallest logical part. Ignoring CSS, since CSS is only for layout and not for semantic meaning, when does span provide additional semantic value by chopping up a sentence or string of words?
It seems that in all cases, other elements are better suited to adding semantic value, making span a purely layout element. Is this true?
Span can be used to add semantic meaning that falls outside the scope of HTML. This can be done by using classes which identify certain attributes. For example, if you are writing a science-fiction novel you can use span to identify made-up words, because you may want to format those differently, or because you may want the spell-checker to ignore them:
Then the wizard called upon the <span class="wizardword">gravenwist</span> and bade it attack the approaching army. The <span class="wizardword">gavenwist</span> resisted but the wizard's <span class="wizardword">wistwand</span> was too powerful.
This could render as
Then the wizard called upon the gravenwist and bade it attack the approaching army. The gavenwist resisted but the wizard's wistwand was too powerful.
Another good example of this sort of thing are microformats, which allow the creation of arbitrary structure within HTML:
<span class="tel">
<span class="type">home</span>:
<span class="value">+1.415.555.1212</span>
</span>
The advantage of span, versus div, is that spans can appear almost everywhere because they are inline content, and divs are block elements, so they can only occur inside certain other elements.
A very useful benefit would be to mark changes in language. E.g.
<p>Welcome to Audi UK, <span lang="de">Vorsprung durch Technik</span>.</p>
Screen readers with multiple language capabilities could make use of this.
So they're not presentational, just generic. In fact, spans are rarely presentational, providing a semantically-meaningful class name is used, like "spelling-mistake" and not "bold-red-text".
<div class="name">
<span class="firstname">John</span>
<span class="lastname">Doe</span>
</div>
It depends completely on what you want to express. If marking up the first name is of semantic value to you (be it just to have a hook for CSS to format first names or to extract them using some scripting language), then you can use a span.
I use SPAN a lot when I want to have JavaScript parse the element and insert some value inside the tag, for example:
<span datafield="firstname"></span>
Would have a value inserted into it later, so in that case it does have meaning, though only a meaning that I decide to give it. The fact that span otherwise has no effect on the layout is ideal in that case.
spans can actually be carriers for semantic information in form of class attributes. This is used by microformats.
span tags need a class or id attribute to give them meaning.
e.g. <span class="personal_phone_number">0123 456789</span>
Ignoring CSS, since that will give the
semantic meaning, when does span
provide additional semantic value by
chopping up a sentence or string of
words?
Ignoring CSS (and other non-HTML markup), never. A <span>'s only purpose in life is to carry markup that you can't express in HTML. Markup such as <span style="dropCap">, which doesn't have an equivalent in HTML but has existed in print publishing for hundreds of years, and which is always applied to just one character - the first letter of an item (article, whatever), without causing a word-break (or any larger break).
It seems that in all cases, other
elements are better suited to adding
semantic value, making span a purely
layout element. Is this true?
Yes and no. The only real value of <span> is that it is semantically neutral. That is, unlike for example <p>, it doesn't do anything that you might want to have it not do when you're using it to carry other markup. And there are times, like <span style="dropCap"> above, when you don't want any other effects.
If you want to apply formatting rules to part of the contents (for example a single word or sentence) of a tag. You can use the span tag. It is sometimes called tagless formatting.
I use spans in my EBNF -> XHTML converter to apply a different format to literals and tokens.
SPAN (and DIV) elements by themselves are generally considered to be semantically neutral. A good approach is to use semantic markup as much as appropriately possible, but sometimes you run into situations where the existing html elements that do provide semantic meaning (EM, STRONG, ABBR, ACRONYM, etc, etc) aren't the right fit semantically for your content. So the next step is to use a semantically neutral SPAN or DIV with a semantically meaningful id or class.
I think he's asking about the difference between a div and a span, and there really isn't one, other than the default behavior.
It's a matter of convention. When using styling, div is typically used to demarcate divisions of content, while span is used to demarcate inline text. You could just as easily use div everywhere or use span everywhere, but it's helpful to think of them as different, even if it's only by convention.
In HTML could be used for microformats. But since actual HTML specification is XHTML, there is no point.
Instead of:
<P>Hello, my name is <SPAN class="name"> Joe Sixpack </SPAN></P>
I'd rather use:
<P>Hello, my name is <FOAF:name> Joe Sixpack </FOAF:name></P>
The meaning of SPAN is "this is a (generic) span of (e.g., text) content". Compare to DIV, which means "this is a logical division (i.e., a generic document section)".
SPAN is mainly a hook for hanging styles off of (so you can use <span style='color:blue'> instead of <font color='blue'>).
From the spec:
The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.
Suppose, for example, that we wanted to generate an HTML document based on a database of client information. Since HTML does not include elements that identify objects such as "client", "telephone number", "email address", etc., we use DIV and SPAN to achieve the desired structural and presentational effects. We might use the TABLE element as follows to structure the information:
<!-- Example of data from the client database: -->
<!-- Name: Stephane Boyera, Tel: (212) 555-1212, Email: sb#foo.org -->
<DIV id="client-boyera" class="client">
<P><SPAN class="client-title">Client information:</SPAN>
<TABLE class="client-data">
<TR><TH>Last name:<TD>Boyera</TR>
<TR><TH>First name:<TD>Stephane</TR>
<TR><TH>Tel:<TD>(212) 555-1212</TR>
<TR><TH>Email:<TD>sb#foo.org</TR>
</TABLE>
</DIV>
<DIV id="client-lafon" class="client">
<P><SPAN class="client-title">Client information:</SPAN>
<TABLE class="client-data">
<TR><TH>Last name:<TD>Lafon</TR>
<TR><TH>First name:<TD>Yves</TR>
<TR><TH>Tel:<TD>(617) 555-1212</TR>
<TR><TH>Email:<TD>yves#coucou.com</TR>
</TABLE>
</DIV>
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.