I'm trying to find the best way to code a search result page in HTML5.
Here's how I've done it.
<section>
<header>
<h2>Results for <kbd>this terms</kbd></h2>
</header>
<!-- list of results -->
<ol>
<!-- First result -->
<li>
<article>
<header>
<h3>
<cite>
This is a result
</cite>
</h3>
</header>
<blockquote cite="http://addressofthepage.ch/">
<p>So, setting about it as methodically as men might smoke out a wasps' nest, the Martians spread this strange stifling vapour over the Londonward country. The horns of the crescent slowly moved apart, until at last they formed a line from Hanwell to Coombe and Malden. All night through their destructive tubes advanced.</p>
<footer>
<p>Published <time datetime="2010-07-15T13:15:05-02:00">MMMM DDth, YYYY</time> at the <abbr title="Uniform Resource Locator">URL</abbr> http://addressofthepage.ch/</p>
</footer>
</blockquote>
</article>
</li>
<!-- Second result ... and so on -->
<li>...</li>
</ol>
</section>
The main questions are
<header> mentions the search terms. What is the best tag to use? <kbd>?
Is the <cite> tag related to the <blockquote> if it is positioned in the <header>?
Is not better to put the <cite> in blockquote > footer like <p>[...] at the URL <cite>http://addressofthepage.ch/</cite></p>
All this is also available on a Gist
is meant as a way to show keys. That's why many sites style that tag as a keyboard key. You're not showing keys, you're showing a search term. A <span> should be fine. Maybe add a class like <span class="search-term">.
Semantically speaking, no, it wouldn't be related as it's not a child.
The "correct" HTML for using cite and blockquote would be:
A quote here...
— Foo Bar
gist here of the HTML: https://gist.github.com/OscarGodson/5a3e87ce895b3af952de (stackoverflow appears to have issues rendering HTML when in code tags?!)
Notice the cite and footer tags. As per spec:
The blockquote element represents content that is quoted from another
source, optionally with a citation which must be within a footer or
cite element, and optionally with in-line changes such as annotations
and abbreviations. Content inside a blockquote other than citations
and in-line changes must be quoted from another source, whose address,
if it has one, may be cited in the cite attribute.
Source: http://www.w3.org/html/wg/drafts/html/master/grouping-content.html#the-blockquote-element
The main thing to remember, and coming from someone who's been doing this for a long, long time, semantics matter, but don't overthink it. Sure, the blockquote has some strict rules about how to properly use it, but browsers will handle whatever you give it fine. Do what makes sense for your app and that should be semantic enough 90% of the time as long as everything isn't a span and div. If you over analyze this stuff you'll spend more time deciding which tag to use instead of just getting stuff done ;)
Related
My goal is to use the correct H* tag (H1 to H6) in my html5 code.
I read here I shouldn't use <section> at all: "Why you should choose article over section : Browsers’ visual display of headings nested inside elements makes it look as if they are assigning a logical hierarchy to those headings. However, this is purely visual and is not communicated to assistive technologies"
but I feel that isn't true because of the answers to this popular question:
that says "sections in an article are like chapters in a book, articles in a section are like poems in a volume" and I want to use sections for their intended purpose.
The problem is this mdn page says "Important: There are no implementations of the proposed outline algorithm in web browsers nor assistive technology; it was never part of a final W3C specification. Therefore the outline algorithm should not be used to convey document structure to users. Authors are advised to use heading rank (h1-h6) to convey document structure."
The guy from the first link I posted does make a good point about halfway down that page where he says "browsers display different sizes of font depending on how deeply the is nested in <section>s”.
So am I correct in saying I have to correctly match H* tags to depth/nesting to achieve a good outline AND visual styling or is there a different way. eg this would be incorrect:
<body>
<h1> something </h1>
<section>
<h1> section heading for outline </h1>
<article>
<h1>my first news article</h1>
<p>stuff</p>
</article>
</section>
</body>
because screen readers can't properly process <section> for outlining.
and because browsers display different fonts according to level of nesting.
so then would this would be correct?
<body>
<h1> something </h1>
<section>
<h2> section heading for outline </h2>
<article>
<h3>my first news article</h3>
<p>stuff</p>
</article>
</section>
</body>
note: This is my first question I'm posting so please go easy on me if I've made a faux-pas, I'm new here :)
The document outline algorithm based on <h1> has been removed from the spec and actually never worked. In terms of heading levels, your last code example is the correct one.
Why the HTML Outlining Algorithm was removed from the spec – the truth will shock you!
There Is No Document Outline Algorithm
So you should not use it, and your quote holds true.
Authors are advised to use heading rank (h1-h6) to convey document structure.
Correctly using <section>
As to the question of using <section> vs <article>.
You shouldn’t avoid the latter due to styling issues. You already did your research and should stick to your outcome. You’d need to apply some styling yourself, though.
I’d also like to add the ARIA perspective on a page summary:
<article> has role article
An article is not a navigational landmark
and
<section> has role region, which is …
[…] sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page.
To do so, it is also noted
Authors MUST give each element with role region a brief label
So, let’s put it together
<body>
<h1> something </h1>
<section aria-labelledby="s1-heading">
<h2 id="s1-heading"> section heading for outline </h2>
<article>
<h3>my first news article</h3>
<p>stuff</p>
</article>
</section>
</body>
What's the best HTML5 element to represent a preview or summary of another webpage? I was thinking <abbr>, but is there a better one to represent these?
(I can’t think of a case where the use of abbr would be appropriate; well, unless the preview content is an abbreviation.)
Preview as teaser etc.
If you want to display some content that already exists at some other place, you probably want to use the blockquote element. You may only use blockquote if you aren’t changing anything of the content.
As it’s a sectioning root element, any headings/sections won’t affect your outline.
<blockquote>
<!-- the quoted page -->
<h1>Foo bar page</h1>
<nav>…</nav>
<article></article>
<!-- could of course also use 'iframe' if it’s the whole page + CSS -->
</blockquote>
Also use blockquote when you want to display a screenshot of the content:
<blockquote>
<img src="screenshot.png" alt="Article Foo …" />
</blockquote>
If you need more complex alternative content, you might want to use object instead of img.
If you are not quoting (i.e., the content is on the same site resp. your own content, or you are paraphrasing), you could just go with article.
<article>
<h1>Summary of article Foo</h1>
<p>…</p>
</article>
In that case, headings/sections do affect your outline, which makes sense, as it’s your content (you summarized/paraphrased).
If it’s just a teaser/snippet in a sidebar (or a search result, or a list of posts etc.), you might want to use the bookmark link type to link to the actual content.
Preview, when creating/editing content
I guess it depends on your understanding of the content if a dedicated element is needed in the first place. One could argue that the preview is (part of) the actual content of the page, and it only happens to be published at another page in addition. So the most basic variant would be to use a sectioning element that is appropriate for this content, probably article:
<form><!-- the content edit form --></form>
<article><!-- the preview --></article>
resp. with a more useful outline:
<body>
<h1>Create a new foo</h1>
<form><!-- the content edit form --></form>
<section>
<h1>Preview of your foo</h1>
<article><!-- the preview --></article> <!-- depends on your case; would also be possible to have several sectioning content elements here -->
</section>
</body>
It could make sense to use the figure element here; as it’s a sectioning root, possible headings/sections of the preview content wouldn’t affect the current outline:
<form>
<!-- the content edit form -->
</form>
<figure>
<!-- your preview -->
</figure>
This is what I would recommend:
<body>
<h1>Create a new foo</h1>
<form>
<!-- the content edit form -->
</form>
<section>
<h1>Preview of your foo</h1>
<figure>
<article>
<!-- your preview -->
</article>
<!-- might use other, more or no sectioning elements here; depends on your case -->
</figure>
</section>
</body>
Special cases
samp
In some cases it might be appropriate to use the samp element:
The samp element represents (sample) output from a program or computing system.
Note that samp can only have phrasing content, so you can’t use it for complex content.
output
In some cases it might be appropriate to use the output element:
The output element represents the result of a calculation or user action.
You could even use the for attribute to relate the output (= preview) with the form.
Just like samp, it can only have phrasing content, so it’s not appropriate for complex content.
It sounds like you might have many short previews or summaries of these websites in a single page? In that case, I think there are many ways to express these types of blocks in smaller HTML chunks while giving them additional semantic meaning. So I will give you several options I would try using in HTML5.
The DETAILS element
The details element is new interactive element in HTML5 which shows a text summary and additional hidden text details that the user can see by clicking the summary text. This is usually created by the browser as a piece of title text with a dropdown toggle arrow that reveals hidden content when clicked. This element is typically used as a Javascript-free toggle widget to disclose additional information if the user chooses to view it. What is nice about this new HTML5 element is it will create this nice toggle, open-and-close, text block without the need for any Javascript, and which includes a nice clickable summary "bar" that unfolds with more detail text. Ive added some extra CSS to make it look sexy. (Note: IE1-11 does not support this element, but with the styles Ive added it degrades gracefully and shows summary and div content in one stacked block.)
<details>
<summary style="display:block;margin: 0;padding: .2em;width: 25em;background-color: #ccccccff;box-shadow: 2px 2px 3px #aaa;">© Copyright 2021</summary>
<div style="display:block;margin: 0;padding: .2em;width: 25em;background-color: #efefefff;box-shadow: 2px 2px 3px #aaa;">
<p>Owned by Company ABC. All Rights Reserved.</p>
<p>All content and graphics on this web site are the property of Company ABC.</p>
</div>
</details>
The DEFINITION element
The dfn element represents a piece of definition text when its term is defined in a paragraph. It represents a piece of text that is going to be defined within a sentence. The definition item is usually styled in plain italics. Not as fancy as the details element but tells search engines you are associating a text title with descriptive text. If you want to just drop page previews in plain paragraphs but give their titles more meaning, wrap the titles with this simple piece of HTML. You could also wrap an anchor tag around the dfn element and link to your page you are previewing. This link then has more semantic meaning.
<p>The <dfn id="sun" title="Our Shining Celestial Body">Sun</dfn> is the name of the local star in our solar system.</p>
The DESCRIPTION LIST element
If your page previews need something more formal, as in a listing, try a description list. The dl element is a description list and contains groups of description terms (dt) and descriptions details (dd). The description list is often used to show a page's glossary, lexicon, or dictionary of terms in key-value pairs. A description list is great if you have many of these previews. It really holds a lot of semantic meaning and allows you to have a description TERM and its DESCRIPTION in separate places. Again, this has more semantic meaning than plain HTML paragraphs. Ive added some CSS to this which you will see when you paste this in an HTML page and view it. Each description is in a white block with a border. You might add your page preview titles as terms, and your text preview in the description element.
<dl>
<div style="margin: .2em;padding: 0 .5em;border: 1px solid #999;">
<dt id="fruit1">Apple</dt>
<dd nowrap="no" role="definition" aria-labelledby="fruit1">A popular fruit that grows on trees</dd>
</div>
<div style="margin: .2em;padding: 0 .5em;border: 1px solid #999;">
<dt id="fruit2">Strawberry</dt>
<dd nowrap="no" role="definition" aria-labelledby="fruit2">A popular berry that grows low to the ground</dd>
</div>
</dl>
I am very new to HTML5 and I need to implement an article container (for example, I need to create the classic structure for the WordPress articles where the user see a series of articles one below another), but I have some doubts about the semantic use of the new HTML5 components.
To do this I thought something like this:
<section>
<h1>My Posts:</h1>
<article>
<header>
<time datetime="2010-11-10" pubdate>10/11/2010</time>
<h2>FIRST POST TITLE</h2>
</header>
<p>
POSTS CONTENT
</p>
<footer>
<address>MY NAME</address>
</footer>
</article>
<article>
<header>
<time datetime="2010-11-01" pubdate>01/11/2010</time>
<h1>SECOND POST TITLE</h1>
</header>
<p>
POSTS CONTENT
</p>
<footer>
<address>MY NAME</address>
</footer>
</article>
</section>
So I have reasoned in the following way:
All the shown posts are contained in an external <section> element (because following the HTML5 specification a <section> represents a generic section of a document, in this case an area where posts are shown), the <sections> have its <h1> title.
Every post is represented by a specific <article> element (should be semantically correct).
Every article element represents a specific post and contains a <header> element that contains the date of publication and the post title. I used a <header> element to contain these information because this element is used to represent "a group of introductory or navigational aids".
Then I have a classic <p> to contain the article textual content (but I can also wrap it into a div or is it better use a new <section> if the text is long and detailed?)
Finally I have put the e-mail contact into a <footer> element because it is an information about the container (the <article> element).
Is this a valid structure for my problem? Is it semantically correct in HTML5?
This looks largely great to me. headers and footers were changed a while ago to allow them to be used in sections and articles.
However, the p element should be used for a single paragraph. In all likelihood, your articles will have more than a single paragraph, and WordPress will generally generate these for you based on line breaks. If you need to wrap all of your article contents into an element, a div will be sufficient. If your article is long and has several sections, you could use these instead.
The address element threw me off a bit first, as not many people use it, but its purpose is to describe the contact address of the author of the document (or part of the document), so your usage is absolutely correct.
For bonus points you can consider implementing the hCard standard for formatting the email: http://microformats.org/wiki/hcard
Basically, aside from the use of the paragraph element to wrap the entire article, this is absolutely fine! You've shown a lot of thoughts behind your decisions, which is quite rare these days.
Your markup is fine.
(Note that for the first article you used h2 and for the second one h1. While both ways are possible, why not stick to one variant?)
is it better use a new section if the text is long and detailed?
Don’t include the whole text in a section! But when you use sub-headings in the article, you are "encouraged" to use explicit section elements to group the heading and its content.
In a typical index of articles (like a blog without excerpt) like this image:
those items should be a list (<ul><li>) or just divs?
And also, they should be figure/figcaption? Because would make some sense, but also... picture is part of an artcile not the main content, so maybe title/description is not the caption of the image, but the caption of the article.
what do you think?
EDIT: a live example - https://news.google.com/?hl=en
I’d use an article for each snippet (i.e. a news teaser).
Each article contains an h1 element for the heading, an img element for the image, and p element(s) for the text.
As you probably want to link to a full version, you could enclose all elements in one a element (which is allowed in HTML5), or the heading etc. only.
So it could look like:
<article>
<h1><!-- news title --></h1>
<img src="" alt="" />
<p><!-- news description --></p>
</article>
Only use figure if this image itself should have a separate caption. The news description (here contained in p) usually isn’t the caption for that image.
You may change the order of the article children. Thanks to the way sectioning elements work, the heading doesn’t have to be the first element.
You may use an ul, but it’s not necessary. ol, however, should only be used if the order is really meaningful for understanding the content (i.e. a different order would change the meaning of the document). Typical example: if the items are ranked by relevance (e.g. most relevant teaser at the top), you should use ol.
Regarding your question if the teaser should be an article:
Don’t confuse article (HTML5 element) with the term "article" (English language). article has a separate definition that doesn’t necessarily have something to do with the understanding of the term "article".
The teaser should also be an article – the teaser article and the fulltext article are different articles, although they refer to the same entity.
The answers here leave a lot to be desired. The HTML spec has an example of blog post markup with comments inside.
https://www.w3.org/TR/2013/CR-html5-20130806/sections.html#the-article-element
While the accepted answer has copy/pasted the description of how the <article> element is used it does not answer the question asked at all.
Here is the answer from W3.ORG
If you can use a native HTML element [HTML51] or attribute with the
semantics and behavior you require already built in, instead of
re-purposing an element and adding an ARIA role, state or property to
make it accessible, then do so.
Here is the logic I am proceeding with after researching:
I have a list of reviews.
Each review is ordered by helpful votes.
Therefore the first level will be an ordered list since reviews will be ordered by their helpful votes. Otherwise an unordered list would suffice such as the nested comments:
<ol>
<li class="review" role="article"> <!-- reviews ordered by votes-->
<header>
<h2>Review title</h2>
</header>
<p>Review body</p>
<section class="comments">
<ul>
<li class="comment" role="article"> <!-- comments with votes-->
</li>
</ul>
</section>
</li>
</ol>
An insightful answer by #Terrill Thompson explains that screen readers are helped by semantic list markup. So yes, a list of <article>'s does make sense. As things become complex he mentions how confusing it can be. This is where ARIA, role and tabindex attributes should absolutely be added and tested.
That answer has a comment directing users to a conversation at W3.ORG. By definition it appears that <article> would not be part of a list where it should be "stand alone content". However the question here, myself and probably you reading this require a deeper answer where article applies to a true list of articles.
Such as:
List of blog articles with excerpts
Search results
Reviews
Comments
This is an opinion question so it comes down to preference.
Based on your image, I would use a <ul> <li> though I could get the same result using divs.
If each item represents an article, then each should be represented using <article> elements.
If you feel that it's an ordered or unordered list of articles, then you could use <ol> or <ul> elements respectively.
I would recommend keeping the markup as simple as possible and as complex as necessary, so something along the lines of:
<div>
<article>
<img>
<div>…</div>
</article>
<article>
<img>
<div>…</div>
</article>
…
</div>
As other people said, I think that each article should be marked with an article tag.
I also suggest to surround the whole list with an aside tag. So If you have one main article in the page (surrounded with main), it will not be affected by the other articles.
Here is a nice article about aside.
using HTML5, would it be semantically correct to place an <article> element within a <li> element. A situation where this would prove useful is a list of recent or popular articles on a blog. Consider the following:
<section id="popular">
<div class="blurb">
<h2>Popular Articles</h2>
<p>The most popular posts from my blog.</p>
</div>
<ul>
<li>
<article>
<h3>Article</h3>
<p>An excerpt from the article.</p>
</article>
</li>
<li>
<article>
<h3>Article</h3>
<p>An excerpt from the article.</p>
</article>
</li>
<li>
<article>
<h3>Article</h3>
<p>An excerpt from the article.</p>
</article>
</li>
</ul>
</section>
Which would appear as follows:
Popular Articles
The most popular posts from my blog.
Article
An excerpt from the article.
Article
An excerpt from the article.
Article
An excerpt from the article.
To me, this seems an excellent way of marking up the information. My only question is if it is correct to nest the <article> element inside the <li> element in this way.
There is nothing semantically incorrect about it, but it is not really necessary. The <ul> and <li> elements aren't really adding anything here, unless you are taking advantage of their default styling. Simply putting the <article> tags directly within the <section id="popular"> should be sufficient, and it reduces the complexity of your page as well as its size.
To determine whether something is semantically correct and useful in HTML, ask yourself a few questions. Are you using each element for its intended purpose? For instance, it's not semantically correct if you use an <a> element for a button, as <a> is for hyperlinks, <button> is for buttons. Do you need each element you are using in order to convey all of the semantic information about your content (sections, headings, links, etc)? Is there anything meaningful that you intend to convey that isn't expressed by use of appropriate elements? Having lots of extra meaningless elements usually isn't harmful, but it adds clutter, and it may mean that there are semantic distinctions you are conveying visually but not encoding in a way that a screen reader or automated bot or browser that presented the information in a different format could make sense of.
If it displays correctly in all implementations, I don't have any idea why it would be incorrect... HTML5 is meant to be flexible. Also, the documentation states:
Contexts in which this element can be
used:
Where flow content is expected.
Which looks to be the context of most elements available.