Using as a reference: https://support.google.com/webmasters/answer/146750?hl=en
You will notice under 'Product' that there is a category Property, and furthermore there's an example on down the page:
<span itemprop="category" content="Hardware > Tools > Anvils">Anvils</span>
which I've mimic'd exactly:
<span itemprop="category" content="kitchen sinks > stainless steel sinks > undermount">undermount</span>
Yet when I test it with Google's structured data tool, I get the error:
Error: Page contains property "category" which is not part of the schema.
I realized in the example also, it's using data-vocabulary.org→Product, where I'm using schema.org→Product.
Now on http://schema.org/Product, it does not have category anywhere mentioned. Does schema.org not offer categories? Or am I missing something?
category is an itemprop of schema/Offer, not schema/Product
To fix your problem, place an offer within the product, and attach the category to the offer.
Note: You are using a content attribute on span, which is not valid in HTML5 or Microdata (but in RDFa).
Schema.org has a category property, but it can not be used on Product. Depending on your content, you may want to use Offer instead of Product (see also my answer with an example use of category).
I've been working on JSON-ld & microdata a lot recently, and I believe in your case 'category' needs to be placed in a meta tag, not span/div tag, preferably before your item. Logically, your need to identify 'undermount' is redundant as it would already be included within your content. Oddly, the schema type service has 'serviceType' as a property, but product does not have an equivalent, otherwise that could have been another workaround. For your content 'undermount' use itemprop="name" within your span, no content within that tag necessary.
<meta itemprop="category" content="Hardware > Tools > Anvils > Anvils" />
Here is the correct format accepted by schema.org...
Related
I found this example in the TYPO3 documentation:
<f:be.uri route="web_ts" parameters="{id: 92}"/>
Unfortunately the doc doesn't explain, what "route" is for.
"parameters" is for key-value-pairs (given to TYPO3 to work with), but unfortunately it isn't mentioned, how to add more than one and how they would become seperated.
Furthermore the doc is mentioning an argument "referenceType", which also isn't explained.
May I ask for some help/explanation for it?
Edit: The title of the question doesn't really reflect the nature of my question. stackoverflow wasn't allowing me to use a more precise one.
The documentation https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/BackendRouting/Index.html explains backend routes quite well.
Furthermore the backend module "Configuration" > Backend Routes lists all available routes.
The core itself is most of the time a good example how ViewHelpers can be used, so a random example which covers quite a lot is the following one
<a href="{f:be.uri(route:'site_redirects', parameters: '{action: \'overview\', demand: demand.parameters, page: 1}')}" title="{f:translate(extensionName: 'fluid', key:'widget.pagination.first')}">
<core:icon identifier="actions-view-paging-first" />
</a>
Checking the implementation, referenceType can either be url or absolute to change the type of urls generated. I don't see currently the need to set this, so I guess you won't need it as well.
In Chrome DevTools, the element tab shows the constructed DOM and I can click on elements in the DOM which also highlights the element on the page. Image of both versions shown in DevTools
If the DOM shows:
<input class="gLFyf">
Then the page highlight will show:
input.gLFyF
I realise these are two ways of writing the same thing, I also realise the former is HTML style and the latter follows CSS conventions. However, I lack the vocabulary to properly refer to either.
What do I call each format?
Eg. would it make sense to refer to <input class="gLFyf"> as HTML syntax and input.gLFyF as CSS syntax? Is there a more widely accepted way to differentiate and name them?
gLFyf is the name of the class which is an attribute that can be referred to in the stylesheet to match styles with elements of that class on the page.
A class leads with a period (.) - whereas an ID would lead with a hash (#).
So .gLFyf is a class.
And #gLFyf would be an ID.
It is a class, whether viewing HTML markup or the DOM inspector. They both refer to the same thing as you already state.
This may be of some use/reference.
Pricerunner have their prices in SERP, so I wanted to do this as well. But for some reason, I don't get any prices in my results.
When I test with Google's structured data tool, I get:
But on my page I get:
Apparently, the only difference (besides review), is the #ids.
If I follow Pricerunners ID then it's an actice link, but if I follow mine IDs, they result in a 404. Problem is, that I haven't set up any IDs?
If you take the first ID on my page, it's: /lelo-lyla-2/product-2348
ID is set to product-2348, wich is standard WooCommerce, but it's being added to the URL, so the URL is /lelo-lyla-2/product-2348 witch results in a 404.
Same with the last ID in aggregated offer: /lelo-lyla-2/price-list
Where does /price-list come from? The div? Should I remove the id="price-list" from the div, in order to make it work, or?
<div id="price-list" itemtype="http://schema.org/AggregateOffer" itemscope itemprop="offers">
<meta content="675" itemprop="lowPrice">
<meta content="1039" itemprop="highPrice">
<meta content="7" itemprop="offerCount">
<meta content="DKK" itemprop="priceCurrency">
</div>
When I run the page through Google's test tool, it gets 0 errors. But I suspect it's because of the "invalid" IDs, or?
I think it’s a bug in Google’s SDTT that it takes the value of the id attribute and uses it as identifier for the item. That’s the job of the itemid attribute in Microdata. I would suggest to ignore the extracted #ids that result from this; only care about those coming from itemid.
For Google’s Product rich result (with aggregate offer) it doesn’t state that an identifier would be required to begin with. So the problem that you don’t get the rich result has most likely nothing to do with this.
As per Google's Product-specific usage guidelines, "Adult-related products are not supported."
I need to show in a page a list of, let's say, person's properties that should be rendered more or less as follow:
name: Name
date: 1/1/2000
other: Other
Reading the doc they say:
The LABEL element may be used to attach information to controls.
So, is it the right tag to encompass the names of the properties like name, date...
even if there's not an <input> to associate with?
Nope, as per Quentin’s answer.
However, in HTML5, <dl> can be used for generic associations where <label> isn’t appropriate.
No.
It says that it can associate information with controls.
It does not say that it can associate information with anything else.
See also the newer (but draft) specification:
Some elements, not all of them form-associated, are categorized as
labelable elements. These are elements that can be associated with a
label element.
button input (if the type attribute is not in the hidden state) keygen
meter output progress select textarea
No, it is not correct to use the label element like that.
The important thing here is the meaning of may.
The LABEL element may be used to attach information to controls.
RFC 2119 (which the HTML4 spec follows) defines may:
May: This word, or the adjective "OPTIONAL", mean that an item is truly optional
So here, may does not mean the label element can be used for other purposes; it just means that it is not required to use a label element with controls.
As far as alternatives go, it depends what you want to achieve. If you are just trying to follow the spec closely, then I suggest using p and a strong element for each pair. If you want the data to be more meaningful to computers, you could consider using one of the Microformat specifications.
I partially agree with the answers so far but want to add that if you want to use labels for some reason, then I would display the property values in read-only controls, and then your labels will be valid.
I've done this using appropriate styling to differentiate the read-only controls from the functioning controls to avoid confusing your users. This was on a sequence of pages which built up the information gathered from the user in a wizard.
I have this link to W3C - the "Editor's Draft" as opposed to the link above which is the "Working Draft", which states that you can associate it with any element - as long as it's 'labelable' - even though this is a subsection of the Form section. It states earlier that a labelable element does not have to be within a form.
http://dev.w3.org/html5/spec/single-page.html#the-label-element
Why is the following code NOT working without id or name attribute specified for the anchor element?
<html>
<body>
First link
<p>innerHTML of the first anchor:
<script>document.write(document.anchors[0].innerHTML);</script>
</p>
</body>
</html>
But if I add an id (or name) attribute, like that:
<a id="first" href="#">First link</a>
It starts to work.
Why is id or name attribute so important? I don't refer to it in my javascript code. I don't use "getElementById" or anything, but it still wants an id to be specified.
P.S. I tested only in IE7 (not the best browser, but I don't have access to anything better at the moment, and it can't stop me from learning :)
UPDATE:
Thanks to Raynos who gave me an idea of HTMLCollection in his answer, I've gotten a deeper understanding of what's going on here, by searching the web.
When we use document.anchors collection, we're actually referring to a collection of a elements with the name attribute that makes an a element behave as an anchor, and not (only) as a link.
We don't have to specify the name attribute if we want to refer to a elements as links. In this case we just need to use a different instance of HTMLCollection object which is document.links.
So the original code will work without name attribute if we modify it to:
document.write(document.links[0].innerHTML);
What a nice feeling of enlightenment! :)
WHATWG says:
The anchors attribute must return an HTMLCollection rooted at the Document node, whose filter matches only a elements with name attributes.
the document.anchors collection needs <a> elements with a name attribute.
IE is known to have bugs where it treats id's and name's as the "same" thing. So that would probably explain why it works for <a> elements with an id attribute.
As an aside, document.write and .innerHTML are evil.
Why don't you use this:
document.getElementsByTagName('a')[0].innerHTML