I'm pretty inexperienced as far as html goes and even less so with html5.
I have a question regarding modal popups - page sections that are interacted with using javascript/ajax, but not necessarily displayed on the page all the time. These are not generally in the main html flow - I might for instance place all my modal code at the end of the page for maintainability. The question is - should I be declaring these chunks of the page using html section tags, or something else?
To shed more light on the situation I'm describing, I have an application page. This contains a number of sections (I'm not referring to html5 here). The first section is modal on entering the page - it's a "click to continue if you agree" section. The next 5 chunks belong to a stepped application form - each step is displayed on at a time using a multiview control. Then another modal - a UI block, followed by a final decision section.
Since they are modal, and appear out of the flow, it is probably most suitable to use a div for them. If you do want to use a semantic block, then which you use will depend on what the content is, and how it relates to the rest of the page. The following articles should help you make that decision:
http://html5doctor.com/the-section-element/
http://html5doctor.com/the-article-element/
http://html5doctor.com/avoiding-common-html5-mistakes/ (particularly the first section of that article - "Don’t use section as a wrapper for styling")
Edit: Have added that 3rd link, since I now have enough rep to do so :-) yay!
The question is - should I be declaring these chunks of the page as sections, or something else
One of the big advantages of HTML5 is it's sematically readable. If you feel that your modal pop ups are better described by something like an article tag, then use an article. Use the tag you feel most accurately describes your functionality.
For example, let's say I have a sample page like so:
<html>
<head></head>
<body>
<article>
<!-- Some stuff here -->
</article>
</body>
</html>
I would expect the content of that article tag to fit this definition:
The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.
W3C Specification. The Article Element.
Note: In this context, an article is designed to represent flow content. Given that your aim is not to write flow content (as you correctly put) this is not a good example. This is very clear from the definition I've provided.
Similarly, if I replaced article with section, I would expect it to fit this definition:
Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site's home page could be split into sections for an introduction, news items, and contact information.
W3C Specification. The Section Element
If I were you I would have a look through the spec and think the following questions:
What does my content actually mean to the user?
How will my content appear to other programmers?
Does the use of this content give me a hint at the correct semantics?
It depends what you have in your modal.
You could have a login form, subscribe stuff, advertisements, articles, a frame of another page, so it would only make sense to use <section> if they are actually an interesting section of the page, for example, you have an article and then you want to display the autor info in a modal box, then I would say that it would acceptable to use <section>.
So overall if it is part of the content then sounds ok to use that, if is is not you should use a <div>.
I would also say that no one has the answer for this as it is purely opinionated, and quite frankly doesn't matter.
There is also another way to incorporate modals. As they are dependent of JavaScript you could also load the popup contents via AJAX without having them in the document flow. A recent project I worked on, first renders links to a normal and complete HTML page for popup contents (e.g. contact forms). If JS is enabled, a parameter is added to the links to load only the main content without header, menu and sidebars via AJAX.
As the modal content does not really belong to your site content (if it does it shouldn't be a popup but within the documents main content) it shouldn't get marked up with some section, main or article tag. Instead use a div to render the popups or use an iframe if that is admissible for your project.
It doesn't really matter what tag is used for a modal, as long as it's appropriate the purpose (don't use a <fieldset> for example). Usually we see a <div> representing a modal.
You can use the role attribute for semantic information about the purpose of an element. In this case role="dialog" would be appropriate. You can find more info on the role attribute in HTML5 here.
Also note ARIA attributes: They enhance accessibility. For example aria-hidden="true" specifies that the element isn't visible. Screen-readers use this to skip the content.
Related
Say I'm building a typical document editor:
Where the preview (in red) is an up-to-date, formatted vue of the form's data.
The preview element contains semantic elements (e.g. h1, h2, main, header, etc.). It's kind of a document in itself, which does make sense, conceptually. But this makes the structure of the real document quite confusing for crawlers and screen readers. There might be, for instance, two h1 or main elements. I'm looking for a way to avoid that.
Plus, there's the problem of repetitive content (see image).
For the accessibility part of the problem, I could just add an aria-hidden="true" attribute to the preview element. In fact, visually-impaired people don't need the preview, it's just redundancy to them, they just need the form.
But for crawlers, here are my options:
Don't use semantic elements inside the preview element, use divs instead (😥).
Host the preview at an other URL and insert it via an iframe (that's what I'm doing right now, but it seems hacky to me).
Leave it like that, crawlers don't care.
Any idea/resource/suggestion?
As long as your preview area is clearly indicated for assistive technology, it's perfectly fine to have redundant information. If you have an <iframe>, make sure there's a title attribute on it.
<iframe title="preview area"...>
However, you might have validator issues with multiple structure elements.
For example, HTML only allows one <main> element:
A document must not have more than one main element that does not have the hidden attribute specified.
You can have multiple <header> elements but a <header> has a default role of banner and the banner role says:
Within any document or application, the author SHOULD mark no more than one element with the banner role.
The key here is "should", meaning it's a strong recommendation but not required. You can also get away with multiple banner roles if your preview section has role="document".
I would recommend not using non-semantic elements (div) because an assistive technology user might want to check the actual semantic structure of what's generated, although I suppose you could also have a "show in new tab" option for the preview that uses all full semantics, kind of like your second bullet but not using an iframe.
I am working on a site with jQuery Mobile "multipage" documents, where there may be several "pages" of the site that are coded as divs of a single html document. Here's the basic structure:
<body>
<div data-role="page" id="page1">
<header>Page 1</header>
<main>Content...</main>
<footer>...</footer>
</div>
<div data-role="page" id="page2">
<header>Page 2</header>
<main>Content...</main>
<footer>...</footer>
</div>
</body>
I would like to use the html5 <main> element as shown, but the w3c validator gives me an error, saying "A document must not include more than one main element."
I understand that the w3c standards permit only one <main> per document. However, the aria standards for role="main" (to which <main> is mapped) do allow "multiple main elements as DOM descendants, assuming each of those is associated with different document nodes" (https://www.w3.org/TR/wai-aria/roles#main).
Do these jQuery Mobile [data-role='page'] divs count as "different document nodes"? Can I have multiple <main> elements if only one at a time is exposed to the end user?
(Note that inactive jQuery Mobile pages are in the document <body>, but hidden with display:"none".)
2018-10-10 update
The HTML standard now states the following requirement:
https://html.spec.whatwg.org/multipage/grouping-content.html#the-main-element
A document must not have more than one main element that does not have the hidden attribute specified.
So the answer now is, you can’t have multiple main elements in a document — unless only one of them at most lacks a hidden attribute.
https://validator.w3.org/nu/ will otherwise now report an error.
Previous answer
Maintainer of the W3C HTML checker (validator) here. I’m not familiar with jQuery Mobile multipage documents but it seems like if only one main element is being exposed to users per logical document, then you’re conforming to the spirit of the requirements.
The W3C checker is stricter about this because in general it’s usually a bad idea to have more than one main per document. But that said, when you give the checker a URL to check it looks only at the static HTML source there and doesn’t execute any JavaScript and so in some case may not really see a very accurate representation of what actual users will see.
I mean, for example, in the case described in the question here, it seems like what users see is not one single document at the URL, but a sequence of logical documents.
So in cases like this instead of the W3C HTML checker you may try using https://checker.html5.org/ to check the document. For main it checks against the requirements in the upstream WHATWG spec, which are less strict in this regard than the corresponding requirements in the W3C version.
In other words, using https://checker.html5.org/ you won’t get an error for multiple main elements.
The Primary purpose of the main tag is to help screen readers and other assistive technologies understand where the main content begins.
As per W3C standards it should only be used once per document. If you try to use more than one main tags per document, the w3c validator will throw an error. Another thing to note is that You can't use it as a descendent of an article, aside, footer, header, or nav element.
quote from the W3C HTML Editors Draft :
The main content of the body of a document or application. The main content area consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application.
main is not a sectioning content, it doesn't affect the outline of the document in the way article, section or nav does.
But according to HTML5 Living Standards :
There is no restriction as to the number of main elements in a
document. Indeed, there are many cases where it would make sense to
have multiple main elements. For example, a page with multiple article
elements might need to indicate the dominant contents of each such
element.
I think it comes down to SEO. If you dont want your SEO to be affected then i think you should avoid using multiple main tags and instead go with the arai-* role tags in your html.
In a simple HTML5 document, you might have something like the following:
header
nav
article
footer
The definition of an article implies that it wraps the main self-contained content.
The question is: should all pages contain an article element. This includes pages with only a contact form, for example.
Thanks
According to HTML 5.1: 4.3. Sections: The article element, the article element can be implied:
When the main content of the page (i.e., excluding footers, headers, navigation blocks, and sidebars) is all one single self-contained composition, that content may be marked with an article, but it is technically redundant in that case (since it’s self-evident that the page is a single composition, as it is a single document).
That would suggest that it’s OK either way.
I think marking it up in an article still has the benefit of being clearer and providing an appropriate container for CSS. However, it is clearly not required.
After every article in my website there are previews for other articles. They are random previews.
The problem is the previews are really big: got headline, subheadline and 6 rows of text. Sometimes google thinks they are part of my article.
Is there any way to tell google that this div contains text from another article?
preview example:
By using the appropriate semantic markup that HTML5 offers, user agents (like Google) would, in principle, be able to understand this; but that, of course, doesn’t necessarily mean that they (currently) support (all of) this.
The teasers should be outside of the main element.
Signal: It’s not part of this page’s main content.
The teasers should be in an aside element.
Signal: It’s only "tangentially related" to the page’s content.
Each teaser should be in its own article element.
Signal: It’s a self-contained item of content.
Each teaser’s link (to the full article) should get the bookmark link type.
Signal: The permalink URL of the teaser/article is not the same as the current page’s URL.
(One could also consider using the blockquote element for the parts taken over literally, i.e., in cases where the teaser doesn’t contain (slightly) different content, like a summary. But it depends on your understanding of your content, if you really quote here.)
However, that doesn’t stop Google to show parts of the teasers in their SERPs (if their algorithms deem it useful, get confused, or whatever). Without using some "hacks" (e.g., with JS or an iframe), it’s not possible nor intended to hide parts of the page for Google Search and their SERPs.
Wrap the preview article div in
<!--googleoff: all-->
<!--googleon: all>
That tells Google not to index that part of your page.
You can costumize the tag to your preference:
index — content surrounded by “googleoff: index” will not be indexed by Google
anchor — anchor text for any links within a “googleoff: anchor” area will not be associated with the target page
snippet — content surrounded by “googleoff: snippet” will not be used to create snippets for search results
all — content surrounded by “googleoff: all” are treated with all attributes: index, anchor, and snippet
(Source)
I've recently discovered rich snippets and their usage to make a search motor understand
the type of content such as addresses, people,...
I have a website in which for each page I replicate the menu (A simple menu with links to all the pages ~20 of the website)
Since the first element in the body is the menu, Google makes the same search preview for all the pages: the menu and not the actual content of the page.
So I would like to know if there is a way to tell the search motor the structure of the page: for instance that some elements are navigation elements, some are content, some are copyright...
Describing the "human" structure of the page.
What I understood is that rich snippets are intended to describe "real life" information, and what I am searching would be something similar but to describe the structure.
I hope that make sens.
Sorry for my english.
So I would like to know if there is a way to tell the search motor the structure of the page: for instance that some elements are navigation elements, some are content, some are copyright... Describing the "human" structure of the page.
Well, this is what HTML elements are used for. Some use the term "semantic markup/HTML" for this. Of course this has its limits, as not every kind of structure/content type can be described.
Solutions for your example:
For navigation, there is the nav element.
The main content of a page can be automatically found thanks to sections and the outline algorithm (in HTML 5.1 there is also the main element).
The copyright info should be given in the small element, probably in a footer element. If it's a link to a license, you should use the license link type.
In general, you should follow these steps (from structure to content):
use appropriate HTML elements, as detailed as possible
use defined/registered link types (for link, a and area elements)
use Microformats (class attribute values for all elements)
use defined/registered meta tags (in meta elements)
use RDFa (Lite) and/or Microdata (new attributes for all elements)
WAI-ARIA can give additional info about your structure intended for accessibility.
This might be what you're looking for:
<meta name="description" content="A description of the page" />
This tag provides a short description of the page. In some situations this description is used as a part of the snippet shown in the search results.
Google will take that string and will show it in the search results