I've just started to learn about microdata in HTML. Now I have a simple question about it. I'm using bootstrap to design my website. So I'm using the bootstrap breadcrumb class. In every instructions how to set up the microdata correctly, it says I should add itemtype and itemprop to a div container.
So my question is:
Is it possible not to use a div container for this? Is it important to have a div-container?
My example code is something like this:
<div class="col-md-12">
<ol class="breadcrumb">
<li itemscope itemtype="http://data-vocabulary.org/Breadcrumb"><a itemprop="url" href="<?= base_url(); ?>home"><span itemprop="title">Ferienwohnung</span></a></li>
<li itemprop="child" itemscope itemtype="http://data-vocabulary.org/Breadcrumb" class="active"><span itemprop="title">Anfahrt</span></li>
</ol>
</div>
Thanks for any help!
Microdata can be used on any HTML element (but note that some elements come with special rules). So yes, re-use your existing markup.
Side note: you are not using the Breadcrumb type correctly; the itemprop="child" must be specified on an HTML element that is a descendant of the parent entry’s itemscope. So it’s not possible to use the child property in a ul (without nesting the list entries). See my answer to a question where the OP used similar markup.
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.
For example:
<div class="menu">
<div class="menu__item">
<div class="menu__item-title">
</div>
</div>
</div>
There's some solution like menu__title.
But if menu has its own title, then how to recognize menu's title and menu item's title?
The main difference is that block__element__element is not a valid BEM selector. The markup you showed in your question is the CORRECT way of naming your elements.
Create a block
If a section of code might be reused and it doesn't depend on other
page components being implemented.
Create an element
If a section of code can't be used separately without the parent
entity (the block).
The exception is elements that must be divided into smaller parts –
subelements – in order to simplify development. In the BEM
methodology, you can't create elements of elements. In a case like
this, instead of creating an element, you need to create a service
block.
More info in the official documentation: https://en.bem.info/methodology/quick-start/#should-i-create-a-block-or-an-element
If you want to have Menu title, the markup should look something like this:
<div class="menu">
<h2 class="menu__title">..</h2>
<div class="menu__item">
<div class="menu__item-title">
</div>
</div>
</div>
BEM gets a bit tricky when you have "children" of an element. But either use the menu__item-title naming convention or rethink your element, perhaps it can be separated and reused as a Block?
I want to semantically enhance my HTML markup by adding elements from the schema.org WebPage vocabulary including semantic markup for the breadcrumb navigation. According to the definition I should use schema.org BreadcrumbList to achieve this.
When looking at Google's documentation about adding structured data for Breadcrumbs though, they explicitly state that the schema.org markup for breadcrumbs is not yet supported.
Instead, the apparently older definition for a data-vocabulary.org Breadcrumb should be applied. This seems to be due to the fact, that the schema.org BreadcrumbList is still disputed. Actually Google parses schema.org BreadcrumbList markup in their Structured Data Testing Tool but don't use it for nice representation in the search results like they do for breadcrumbs annoted using the data-vocabulary.org Breadcrumb definition.
However, it would be nice to bring together both worlds and have semantic markup for webpage and breadcrumbs. The best I was able to come up with looks like this (using itemref to prevent needing to nest each Breadcrumb into the other):
<body itemscope itemtype="http://schema.org/WebPage">
<h1 itemprop="name">George Orwell</h1>
<p itemprop="description">Eric Arthur Blair (25 June 1903 – 21 January
1950), who used the pen name George Orwell, was an English novelist,
essayist, journalist and critic.</p>
<nav itemprop="breadcrumb">
<ul itemscope>
<li id="bc1"itemscope itemref="bc2"
itemtype="http://data-vocabulary.org/Breadcrumb">
<a href="http://example.com/books" itemprop="url">
<span itemprop="title">Books</span>
</a> ›
</li>
<li id="bc2" itemscope itemprop="child" itemref="bc3"
itemtype="http://data-vocabulary.org/Breadcrumb">>
<a href="http://example.com/books/authors" itemprop="url">
<span itemprop="title">Authors</span>
</a> ›
</li>
<li id="bc3" itemscope itemprop="child"
itemtype="http://data-vocabulary.org/Breadcrumb">>
<a href="http://example.com/books/authors/orwell" itemprop="url">
<span itemprop="title">George Orwell</span>
</a>
</li>
</ul>
</nav>
</body>
The itemscope attribute on the <ul> is needed so the subsequent breadcrumbs with itemprop="child" are not interpreted as properties of WebPage.
When I throw this code at the Structured Data testing tool, all data is recognised as I want it to be, but there are warnings for the undefined ul item.
Is it safe to ignore these errors? Are there other approaches or even best practices to solve the problem? What about future-proofness: would it be wise to use this kind of code on a website that may not be updated for years?
When testing your markup, Google’s Testing Tool doesn’t seem to report any errors or warnings. It says "All good" for every item.
Your use of Microdata is valid. You are adding an item without type, which does not have any content (because no properties are added).
Using Schema.org’s breadcrumb property seems to be appropriate, as one of its expected types is Text. So Schema.org consumers would extract only the text content of the child items, no URLs:
Books › > Authors › > George Orwell
I don’t think that the linked issue is the reason why Google does not support Schema.org’s BreadcrumbList: the issue is from 2012, but the BreadcrumbList type was added only a few months ago (2014-12-11) to Schema.org.
The issue is about using the breadcrumb property without a type (which did not exist back then), which is not ideal because this does not allow to specify metadata for each breadcrumb (e.g., its URL).
The future-proof way would be to use both vocabularies for breadcrumbs. The Microdata syntax makes this hard/impossible, but the RDFa syntax allows this (however, the odd requirement from Data-Vocabulary.org that the breadcrumbs have to be nested might require markup changes).
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?"
Are there any benefits of using the following code?
<ul role="list">
<li role="listitem"></li>
<li role="listitem"></li>
<li role="listitem"></li>
</ul>
Does the following code have the same meaning to assistive technologies?
<ul>
<li></li>
<li></li>
<li></li>
</ul>
The answer is yes, assistive technologies work well when correct semantic markup is used for structuring the document. If it is a simple static list then there is no need to mark them with the roles.
For example: Consider the role="listitem" whose baseConcept is defined as HTML li. And the baseConcept HTML li is almost identical to the role="listitem" definition except for the fact that it does not inherit any properties. More info
Thus, consider the following example:
<h3 id="header">Vegetables</h3>
<ul role="list" aria-labelledby="header" aria-owns="external_listitem">
<li role="listitem" aria-level="3">Carrot</li>
<li role="listitem" aria-level="3">Tomato</li>
<li role="listitem" aria-level="3">Lettuce</li>
</ul>
…
<div role="listitem" id="external_listitem">Asparagus</div>
Here the page author wants to use aria-level property for the li. Even though aria-labelledby and aria-owns can be applied to all elements of base markup, aria-level property requires that the element have some role. Since ARIA spec uses Web Ontology Language (OWL) to represent the roles in a class hierarchy. OWL describes these roles as classes along with their states and properties. So inorder to use a aria-level the element has to be defined some role as plain HTML li will not inherit any properties or limitations. Once you mark the role as listitem it requires that listitem be owned by an element with role="list". So you end up using both the roles.
On the other hand roles are also useful if semantic markup is also not used. For example:
<div role="list">
<div role="listitem">dog</div>
<div role="listitem">cat</div>
<div role="listitem">sparrow</div>
<div role="listitem">wolf!</div>
</div>
Here the screen reader software will indicate the ARIA list (made up of divs) as any other normal HTML list.
You question is a bit ambiguous, but if you are asking whether there's a benefit to adding role="listitem" to li items, which already have that as their default role, then the answer to that specific question is 'No.'
(Yes, the use of a li is preferred instead of a div. And role="listitem" is needed if you were using a div. But I don't think that's quite what you are asking.)
Check out Using ARIA by Steve Faulkner; he's put together a draft best-practices document on when and where to use the various ARIA roles in HTML5.
Generally speaking, you don't need to (and shouldn't) specify a role for elements if that role is the same as the element's default role. So since li elements have a default role of listitem, there's no reason to restate that.
There are some exceptions to this rule, and they're mostly concerned with new HTML5 elements that browsers have not yet correctly implemented default roles for. So, for example, since HTML5's article element isn't yet exposed by all browsers as having a role of article, then <article role='article'> is actually recommended in that and similar cases.