So we are using some rich snippets and they use the html5 markup scheme.
Our problem is the itemscope attribute doesn't have a value.
<div itemscope itemtype="http://schema.org/LocalBusiness">
This cause our old products html validation to fail because it thinks it's an empty tag. Does google and markup rules work the same if you assign it a value of 1 like so.
<div itemscope="1" itemtype="http://schema.org/LocalBusiness">
It's a work around for now until we can properly update our validation methods but that is a farther out project.
So basically is there a proper syntax to make this still valid for Googles Rich Snippet rules, html5 and older validation engines prior to html5?
(This answer is basically copied from Peter Murray, specifically these two comments.)
The HTML5 spec allows for boolean attributes with a value of an empty string or the attribute name:
If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace.
So either this:
<div itemscope="" itemtype="http://schema.org/LocalBusiness">
or this:
<div itemscope="itemscope" itemtype="http://schema.org/LocalBusiness">
is valid HTML5.
To be sure that Google recognizes itemscope="itemscope" correctly, he (Peter Murray) created an example page and ran it through Google's rich snippet validator. From the results, you can see that Google picked up the data (an Event item) correctly.
Related
I always thought the standard way to specify a fragment identifier is by <a name="foo"></a>.
go to foo
<a name="foo"></a> <!-- obsolete method, it seems -->
<p>some content under that anchor with name</p>
But it seems like this is the old way, and the new way is using an id, like this:
go to bar
<p id="bar">some content under that p with id</p>
In fact, the W3C validator says that name is obsolete for the <a> element. So are there 2 ways to jump to the fragment identifier but 1 of them is obsolete? (And when did that happen?)
(there are other questions about the difference between id and name, but this one is about fragment identifier)
So are there 2 ways to jump to the fragment identifier but 1 of them is obsolete?
There are two ways to identify a fragment.
(There are also two ways to jump to one, since you can do it with a URL or write a pile of JavaScript to scroll the page).
And when did that happen?
id was introduced in 1996 when HTML 4 came out. It effectively obsoleted the name attribute for anchors.
name was made officially obsolete in HTML 5 in 2014 (or in Living HTML on some date that I'm not going to try to figure out).
Yes there are two ways to jump to a fragment identifier and both aren't obsolete ( except a element).
That's rules applied to all HTML 5 elements other than a (because in a hasn't name attribute in HTML5).
So shortly it's obsolete to idenfity name attribute as fragment idenitifier for a element as that's attribute depricated since HTML4.
Flow of accessing fragment from HTML5 Specification:
If there is an element in the DOM that has
an ID exactly equal to fragid, then the first such element in tree
order is the indicated part of the document; stop the algorithm here.
If there is an a element in the DOM that has a name attribute whose
value is exactly equal to fragid, then the first such element in tree
order is the indicated part of the document; stop the algorithm here.
Otherwise, there is no indicated part of the document.
Both ways of doing fragment identifiers work.
Using id="fragment" is the newer, recommended way of jumping to fragments in HTML. It was introduced with HTML4, and works basically everywhere (I just verified this with IE5).
<a name="fragment">, the older way, still works, but is obsolete since HTML5.
Answer to your question: Yes, There are two ways to identify a fragment and one is obsolete.
What is Fragment Identifiers ?
Fragment identifiers for text/plain.
URIs refer to a location in the same resource. This kind of URI starts with "#" followed by an anchor identifier (called the fragment identifier).
Fragment Identifier using JS like below.
location.replace('#middle');
More information on the name attribute.
Basically, the name attribute has been deprecated (obsolete in HTML5-speak) for just about everything except for form elements. Forms retain them as the method of identifying data, and it is the name plus the value property which is sent back to the server. (The id in form elements is used for attaching label elements, and has nothing to do with the actual data).
There is a fundamental weakness in the name attribute, which the id attribute addresses: the name attribute is not required to be unique. This is OK for forms where you can have multiple elements with the same name, but unsuitable for the rest of the document where you are trying to uniquely identify an element.
The id attribute was specifically required to be unique, which makes it better for identifying a link target, among other things. CSS is pretty relaxed about applying styles to multiple elements with the same id, but JavaScript is more strict about this requirement. And, of course, you can’t have a practical link target if you can’t guarantee uniqueness.
The Ember docs for Ember.View attributeBindings states that:
http://emberjs.com/api/classes/Ember.View.html
If the return value of an attributeBindings monitored property is a boolean the property will follow HTML's pattern of repeating the attribute's name as its value
However, I am marking my pages up with schema.org semantic data and would like to set the itemscope attribute on one of my div tags. But when I do this with attributeBindings Ember wants to give me:
itemscope="itemscope"
rather than just a vanilla "itemscope" boolean attribute tag.
I think the answer to this may well be "not currently possible" but it seems like something that must be doable so I wanted to appeal to the wisdom of S.O. before giving up.
If you set itemscope to the String 'true' rather than the boolean true then it should work.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
In all examples around the web I see Microdata properties itemscope and itemtype being applied to div elements, like so:
<div itemscope itemtype ="http://schema.org/Movie">
<h1 itemprop="name">Avatar</h1>
<span>Director: <span itemprop="director">James Cameron</span> (born August 16, 1954)</span>
<span itemprop="genre">Science fiction</span>
Trailer
</div>
But can Microdata be applied on any other element, in my case I want to apply it to a list item:
<ul>
<li itemscope itemtype ="http://schema.org/Movie">
<h1 itemprop="name">Avatar</h1>
<span>Director: <span itemprop="director">James Cameron</span> (born August 16, 1954)</span>
<span itemprop="genre">Science fiction</span>
Trailer
</li>
</ul>
Are there any known problems with this?
You can use every HTML5 element for Microdata …
Microdata defines 5 new attributes for HTML5:
itemid
itemprop
itemref
itemscope
itemtype
Let’s see where they can be used. Section 5.2 says:
Every HTML element may have an itemscope attribute specified.
So every element can have itemscope. Further on it says:
Elements with an itemscope attribute may have an itemtype attribute specified
So if it has itemscope (and we learned that every element can have it), it can have itemtype, too. Next:
Elements with an itemscope attribute and an itemtype attribute […] may also have an itemid attribute specified
If it has itemscope and itemtype, it can have itemid, too. And:
Elements with an itemscope attribute may have an itemref attribute specified
If it has itemscope, it can have itemref.
Only itemprop is missing now. It’s defined in Section 5.3:
Every HTML element may have an itemprop attribute specified
So itemprop can also be used on every element.
(Note that Microdata (W3C Note) refers to the HTML5 spec for defining what a "HTML element" is, so essentially "HTML element" means "HTML5 element".)
… but some elements get a different content model (when itemprop is used)
See 8.1 Content models.
For example:
href becomes a required attribute for a and area
data becomes a required attribute for iframe
the attributes name, http-equiv and charset are no longer allowed on meta
… and some elements have special rules for determining the property value (when itemprop is used)
See 5.4 Values.
For example:
Special rules for links. Here foobar’s value is the URL http://example.com/, not the string Link:
Link
Here foobar’s value is 5, not 10:
<data value="5" itemprop="foobar">10</data>
And search engines should know this.
If Google or other search engine services support it can’t be answered definitely, as nothing can be answered with certainty when it comes to third party services that keep their code hidden. Even if they (seem to) support it today, we can’t know what will happen tomorrow. So such questions are usually not appropriate for Stack Overflow.
However, there is no reason to assume that search engines wouldn’t support it.
Simply put, "Yes". Check out the Google page yourself to see them use it in different tags: https://support.google.com/webmasters/answer/176035?hl=en
Adding to Jeremy Miller's answer:
Microdata essentially forms objects. In valid HTML, an element with the itemscope attribute contains all of the microdata associated with it. Also, the scope of each element with an itemprop is enough to contain all data necessary for that property.
Imagine replacing each itemscope element with the item itself; and replacing each itemprop element with the property itself, and its value. (Think XML)
In your example, the item would look like this:
<movie>
<name>Avatar</name>
<director>James Cameron</director>
<genre>Science fiction</genre>
<trailer>Trailer</trailer>
</movie>
This structure of itemscopes and itemprops can be applied to any suitable hierarchy of HTML elements, regardless of what elements they are. The long-winded answer is still yes, but I hope this has helped you understand how microdata is interpreted.
Also, I'm guessing your example is from here, but I suggest you give at least items 1a-1d a quick read.
Let's say I have the following sentence I want to add rich snippets to:
I live and work in New York
Since New York is both my residency and the city where I work in, I would theoretically want to tag the line like this using schema.org standards:
<div itemscope itemtype = 'http://schema.org/Person'>I live and work in
<span itemprop = 'homeLocation' itemprop = 'workLocation'>New York</span></div>
Is it valid to have 2 itemprops in one span tag? If not, will the below work?
<div itemscope itemtype = 'http://schema.org/Person'>I live and work in
<span itemprop = 'homeLocation'><span itemprop = 'workLocation'>New York
</span></span></div>
The usual HTML way would be to use one attribute and separate several values with space characters.
Looking into the Microdata specification, you’ll notice that this is the case for the itemprop attribute, too:
The itemprop attribute, if specified, must have a value that is an unordered set of unique space-separated tokens […]
So this should be correct:
<div itemscope itemtype="http://schema.org/Person">
I live and work in <span itemprop="homeLocation workLocation">New York</span>
</div>
(Note: If using itemprop values as CSS selector, use [att~=val] instead of [att=val].)
The first snippet of code I posted does not work, but the second does. Google has a rich snippets page tester which is pretty useful for code validation
I'm trying to understand the reason behind the existence of two attributes instead of just making the element holding the 'itemtype' the one that wraps the scope for the item.
Is it valid to have 'itemtype' attribute on one element and 'itemscope' attribute in some other? like this:
<section itemtype="http://data-vocabulary.org/Person">
<div itemscope>
<span itemprop="name">Alonso Torres</span>
</div>
</section>
If this case is not valid then why the existence of the 'itemscope' attribute at all? Why the spec didn't come up with the idea of making the element holding the 'itemtype' attribute to be the one which sets the scope. That would have make sense for me.
You're right, the itemscope attribute seems redundant. Someone else pointed this out on the W3C's HTML mailing list: http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0517.html
The answer ( http://lists.w3.org/Archives/Public/public-html-bugzilla/2011Jan/0523.html ) was that:
The HTML spec editor did user-testing
of the feature earlier, and if I
recall correctly, several of the test
subjects found it much easier if there
was an explicit indicator of the
container, rather than it being
implicit due to the type.
In other words, it's better for attributes to have a single clear definition than multiple implied definitions. Not sure I agree but that's the official view.
itemscope is mandatory if itemtype is used on the same element
The example you show is invalid. The spec has been updated to include this:
The itemtype attribute must not be specified on elements that do not have an itemscope attribute specified.
Here, "must not" is to interpreted as in RFC2119: "the definition is an absolute prohibition of the specification".
I don't believe that it is useful to place an itemtype attribute anywhere but on the same element as the itemscope attribute. The spec says:
The type for an item is given as the
value of an itemtype attribute on the
same element as the itemscope
attribute.
The reasons why two attributes are needed isn't clear to me either. Semantically they serve different purposes, so for clarity of usage it may have seemed more sensible. For simple use, it's possible to create an item using itemscope without giving it a type. That means that itemscope is a boolean attribute, whereas itemtype takes a string value. It's not possible in HTML for an attribute to behave as boolean when used without a value, and a string when used with one, so separate attributes makes sense.
I know that Google did a usability study on the Microdata mark-up before it was announced, so it was likely that such questions were addressed there and that the separate attributes was the preferred outcome. (Although that study also resulted in a preference for itemref being an element, not an attribute, something that was subsequently changed.)