I'm trying to write a site using the most semantically correct HTML I can manage, and my client wants a navigation bar where each link has a title and a description/subtitle inside the clickable area. What's the best way to achieve this?
Here's what my code looks like right now:
<nav role="navigation">
<a href="dashboard.html">
<!-- There's an icon here but don't worry about that -->
<h4>My Dashboard</h4>
<p>Get an overview of your cases.</p>
</a>
<a href="new.html">
<h4>Submit Case</h4>
<p>Get help from the Service Center.</p>
</a>
</nav>
And for reference, here's what it looks like styled:
The accessibility guidelines I'm following specify that heading tags should be used in descending order (as in, <h3> may only appear after an <h2> tag, etc). The answers to this question seem to indicate that it's not a good idea to use headings in the navigation regardless.
I could use <p> tags for both the title and description, but I'd prefer for screen-readers to be able to tell that the title is more important.
I'm inclined to use a description list, but I can't find examples where they're used this way.
I ended up using styled <p> tags, but with a hidden colon between the title and the subtitle to still convey the hierarchy between them to screen-readers. Headings were the wrong way to go from the start, since the nav links aren't part of the page's content.
Related
I want to write semantic beautiful no-nonsense HTML. When is the right time to include class and when it's not? Should I add class on every element of my HTML?
To write semantic markup, we must use HTML tags correctly so that our markup is both human-readable and machine-readable. When we write semantic markup we can no longer select HTML elements based on visual presentation. Instead, we select HTML elements based on their semantic meaning, and then use CSS to define the visual presentation of our content. When writing semantic markup, the presentation of web page elements is kept completely separate and distinct from the markup of the content itself.
<body>
<ul class="post">
<li class="title"> <h3>Title of Post</h3> </li>
<li class="content"><p> Lorem Ipsum bla bla..</p></li>
<li class="hashtag">#samplepost
</li>
</ul>
</body>
<style>
.title{code}
.content{code}
.hashtag{code}
</style>
or
<body>
<ul class="post">
<li> <h3>Title of Post</h3> </li>
<li><p>Ipsum bla bla..</p></li>
<li>#samplepost </li>
</ul>
</body>
<style>
.post > li > h3{code}
.post > li > p {code}
.post > li > a {code}
</style>
Which of these is more semantic? Should we use class on everything or only when necessary?
Only use classes when you want to style a group of elements in a similar way (and ids for unique elements), it can be confusing for someone picking up your code if class names don't have any styles attached to them, and it just adds clutter.
Using semantic tags will make your html more semantic - ie. header, nav, main, footer, aside - etc. Some of these tags even make it easier for screen readers to navigate. w3 schools has good info about semantic tags: https://www.w3schools.com/html/html5_semantic_elements.asp
It is better not to be attached to HTML tags, who knows where else you will have to use a similar interface. It’s best to stick with some CSS methodology (for example BEM) and write styles based on CSS classes. From the presence of classes, the layout will not be less semantic. The main html tags to write correctly.
In general, if you want to avoid problems in the future, use the css classes.
I would write like this:
<body>
<div class="posts-list">
<h3 class="posts-list__title">Title of Post</h3>
<ul class="post-list__ul">
<li class="post-list__item">
<p> Lorem Ipsum bla bla..</p>
</li>
</ul>
<div class="posts-list__hashtag">
#samplepost
</div>
</div>
</body>
Creating classes everywhere is a lot of work and can potentially cause some problems later on. If you add a class to every HTML tag, imagine how hard to maintain the code is going to be if the project becomes bigger. As mentioned above there are specific methodologies which can be really helpful, and BEM is a popular, but not the only one, you can use other. If you don't want to use methodology and stick with simple classes for now (though at some point I really suggest diving into that topic, you don't have to know perfectly how to use specific methodology, but how they works, if you ever join any team working with code, then they are going to tell you what methodology they picked for the project), I suggest using second code, but with comments:
<body>
<!-- Post -->
<ul class="post">
<!-- Title -->
<li>
<h3>Title of Post</h3>
</li>
<!-- Content -->
<li>
<p>Ipsum bla bla..</p>
</li>
<!-- Hashtag -->
<li>#samplepost </li>
</ul>
</body>
<style>
.post>li>h3 {
code
}
.post>li>p {
code
}
.post>li>a {
code
}
</style>
Comments are really simple and powerful tool. They will help you getting oriented in the project really quick, and avoid adding unnecessary classes for semantics.
The first thing to note is your content is not a list, so you shouldn't be using ul/li. That bad semantics, and as such worse than no semantics at all.
Your semantic markup is this:
<body>
<h3>Title of Post</h3>
<p>Lorem Ipsum bla bla..</p>
#samplepost
</body>
If you want to create a containing block for your post, to might reasonably wrap it in a div element, and although it's not necessary for such simple content, you could also consider wrapping it in a main element. You could put your anchor inside a p element but that makes no semantic difference.
Now you add one or more classes to any element when it is sensible to do so. What is sensible? It means not going over the top, forcing a class onto an element just because it looks naked without one. Generally, a good rule of thumb is to add a class when there's a utilitarian purpose in doing so. Classes are a way of putting you content in to categories, so that categorisation should be useful in some way.
For example, it might be that you want to style all the content with a particular category a similar way. Or it might be that you want to add some common functionality via JavaScript to all the content in a particular category.
Or it might be that you want to identify a category of content for your maintenance purposes. For example, suppose you have a large document describing products that you sell. With each product is a price. Even if you have no intention of styling the price differently from the other content, nor have any relevant JavaScript, you might add a class of "price" to each one, so that when the time comes to update your prices, you can easily find them all in your editor, and thus make sure that you don't miss one.
For each utilitarian purpose, think about opportunities, rather than necessities. By adding a class to categorise some some content, you are creating an opportunity for common styling, or functionality, or discovery to be applied.
Is there any way to markup Item properties placed inside a child Item (and therefore out of it's scope)?
I'm using microdata and schema.org to mark up some web page with. and I have a code like this:
<body itemscope itemtype="http://schema.org/WebPage">
<header itemscope itemtype="http://schema.org/WPHeader">
<a href="index.html">
<img id="logo" src="xxx" alt="xxx" itemprop="primaryImageOfPage">
</a>
</header>
<!--the rest of the page-->
</body>
I have the logo inside the WPHeader Item and I want it to be the primaryImageOfPage for the WebPage Item. I know i can use Itemref to include properties which are out of the item's scope, but like this you don't take this property out of the child item's scope. That's really a problem if both items can have the same property, such as name or description.
This is only an example to explain the problem I have. By the moment I solve it using itemref...but there has to be a better way to do that.
I know there's no need to markup everything, I just want to know which is the best way to avoid having this problem.
Microdata is RDFa rip-off constrained to be relevant to search cross-cutting concern for semantic fragments. It thus assumes the advanced scoping abilities of CURIEs is discardable. For wholeness that good quality domain-specific content pages exhibit, RDFa alongwith vocab covering domain-specific aspects accordingly is the ultimate way as yet. While search providers dominated HTML5 spec to make microdata part of standard, as the Web keeps growing more semantic, the differences between both are ending up as mere matter of "what's in a name?"
I am working on a website on which i show restaurants according to either categories, food, etc. So I have a listing page where I list the restaurants as per the filters applied by the user.
I have a SEO question.
It is said that using heading tags<h1>,<h2>... tags should be used for titles, and important items.
So this is what I did.
...
<div class="item">
<h1>Title of Restaurant</h1>
<h2>Address</h2>
<p>Description</p>
</div>
...
which, for design changes, was later changed to
[EDIT]
As per #Guffa's response, there should be minimum <h1> tags possible on the page.
Since the Title of the restaurant is important and I want it to be recognized as a heading rather than simple text, I'll use <h3> for it.
...
<div class="item">
<h3>Title of Restaurant</h3>
<h4>Address</h4>
<p>Description</p>
</div>
...
The scenario that <h4> tag has no text but rather a child node with a link.
So my question is when my page is indexed (second case), will the <h4> be recognized?
Or will it be completely ignored and thought of as a hyperlink?
Is filling the heading text with a very high text-indent a smart idea?
Or should i use the anchor as it is and apply a title attribute to it?
The h1 tag should be used for important information about the page, so you should really only have one on the page.
Having a listing with h1 tags means that the spiders get conflicting information about what's important on the page, and will likely ignore all of them.
As the h1 should be something like the title for the page, it doesn't make much sense to have a link inside it, as that link would go to the same page.
I have a sidebar with latest news and random blog posts etc
<nav id="sidebar">
<section id="latest_news">
<h1>
Latest News
</h1>
<h2>
News Item 1
</h2>
<p>
Truncated text from the news item in question
</p>
View all news items
</section>
<section id="random_blog_post">
<h1>
Random Blog Post
</h1>
<h2>
Blog Post 1
</h2>
<p>
Truncated text from the random blog post in question
</p>
View all blog posts
</section>
</nav>
As you can see, I've got sections, h1's and paragraphs inside my nav.
I'm just wondering if this allowed or considered good practice. Is there a better more semantic (or less) approach to marking-up and structuring such sidebar content?
Yes, this appears to be pretty valid html5. w3org have an example of navigation with h1 tags in it.
Yes, you can do that, as also denoted in the spec
Quotes specifically relevant to your question:
The nav element represents a section
of a page that links to other pages or
to parts within the page: a section
with navigation links.
and
A nav element doesn't have to contain a list, it can contain other kinds of content as well. In this navigation block, links are provided in prose:
<nav>
<h1>Navigation</h1>
<p>You are on my home page. To the north lies <a href="/blog">my
blog</a>, from whence the sounds of battle can be heard. To the east
you can see a large mountain, upon which many school papers are littered. Far up thus mountain
you can spy a little figure who appears to be me, desperately
scribbling a thesis.</p>
<p>To the west are several exits. One fun-looking exit is labeled "games". Another more
boring-looking exit is labeled ISP™.</p>
<p>To the south lies a dark and dank <a href="/about">contacts
page</a>. Cobwebs cover its disused entrance, and at one point you
see a rat run quickly out of the page.</p>
</nav>
Actually, you could even write an h1 element as a direct child of the nav element so that the nav element would be named in the document's outline.
I suggest this reading about the importance of headings and document's outline:
http://dev.w3.org/html5/spec-author-view/headings-and-sections.html#outline
You can check your document's outline with this on-line tool:
http://gsnedders.html5.org/outliner/
Regards.
Take these two pieces of markup:
<div id="header">
<img src="/img/logo.png" alt="MyLogo" />
<ul id="misc-nav">
<li>..</li>
</ul>
<header>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<p>The smell of invention awaits you...</p>
</header>
</div>
and
<header>
<img src="/img/logo.png" alt="MyLogo" />
<ul id="misc-nav">
<li>..</li>
</ul>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<p>The smell of invention awaits you...</p>
</header>
My example may not be perfect, but I'd like to know if the purpose of the tag is for semantic definition of the content, or is it block level structural definition with CSS?
It is my understanding from the spec itself, that the first example is the correct interpretation, yet I see the second being touted as the right way.
Can you offer any clarity on it?
Both are fine. But what exactly do you mean by "structural" vs "semantic"?
It's your first method (semantically).
The < header> tag defines an
introduction to the document.
<header>
<h1>Welcome to my homepage</h1>
<p>My name is Donald Duck</p>
</header>
<p>The rest of my home page...</p>
http://www.w3schools.com/html5/tag_header.asp
Spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element
The header tag purely semantic.
However, in fact all HTML tags are to provide a context to the content (= semantics).
Use CSS to style your content approperiately.
I would advocate the following combination of markup and CSS:
In your CSS:
header {
background: #fff url(/img/logo.png) top left no-repeat;
padding-left: 64px; /* or whatever required to display margin correctly */
}
/* if you REALLY want your navigation to appear as a bulleted list */
nav a {
display: list-item;
}
In your page markup:
<nav>
<a>...</a>
<a>...</a>
</nav>
<header>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<p>The smell of invention awaits you...</p>
</header>
This way you're using the semantic <header /> and <nav /> tags to mark up text content, and then using CSS to enhance the presentation with display formatting, logo images, etc.
I recall - although alas I can't find the sources now - that the proposed new elements in HTML5 (header, nav, footer, aside, article, etc.) were chosen based on analysis of Google's database of websites to identify the most commonly-used ID attributes assigned to DIV elements, figuring that those represented the most common scenarios where developers were using DIVs to wrap meaningful elements of their page structure.
HTML5 actually does away with block/inline distinction in favour of a more nuanced content model. The header element is flow content, which is like the default state for HTML5 elements. Semantically it should be considered as introductory information for its nearest section content or sectioning root ancestor.
I think both your examples are valid uses of the element, though I personally would probably markup your first one this way:
<header>
<img src="/img/logo.png" alt="MyLogo" />
<nav>
<ul>
<li>..</li>
</ul>
</nav>
<hgroup>
<h1>Welcome to Bob's Website of Fantastical Conbobulations</h1>
<h2>The smell of invention awaits you...</h2>
</hgroup>
</header>
I used to think that the first method is the proper way to use the element, as it is intended to provide relevant information for a given section it is included in, not being a section itself, besides we already have elements for structuring the content, but for what i've seen in some pages, the reason many people includes also a header element at root level is to provide that same information considering the whole page as a big section, so i've changed my mind to think both of the examples can be considered correct.
If you read the W3C HTML5 specification you will find that every html page should have only one H1 tag, so if you use h1 then h2 then h3 you might see some weird styling. That is because the browser expect one h1 on every html page when it parses it.
So you can instead use h1 h2 h3 tags and style them any way you want.
The point of using semantic html elements is because your website will be 'read' not only by web browsers but also by web crawlers, tools that read the page with voice, braile tools and many more applications and physical tools.
So when those applications read your website they don't read css, only html and might read some javascript. So when they see lang="en" they know to read the contents in the element in english etc. When they see "section" they know it's section element and when they see "aside" they know it is some aside element etc.
We can easy see the page and know what is what, but visually impaired and other people can't do that so for them this will be of great help. Think about that when you make your websites, think about all the people that will access it and how easy will be for them to do that.
That is the whole point of the new awesome html5 elements. You can make the same webpage just with one element - "div" for example, and with a whole range of new html5 semantic elements - article, section, header, footer, aside etc. The webpage will look the same in web browsers, but smart applications like search engine robots will crawl the page better and some applications that read web pages will parse the page more easily.
The point of web is to be open to all people and free, and I agree to that.
In the future, the web will evolve without doubt, new tools will be made that will parse web pages, and using new html5 semantic elements will make your webpages future proof, so these new tools will read our pages in smart way.
Hope this helped someone :)