I've been reading this tutorial. When I cross cheked it with MDN page on link_types I found that some values like contents, glossary and copyright aren't mentioned on MDN page. For copyright there seems to be an alternative of license value.
Am I reading an outdated tutorial? Are the values contents, glossary and copyright deprecated?
For current info on this, see the existing rel values page in the Microformats Wiki.
That page is what the HTML spec itself references as the official list of rel values that are valid in addition the ones defined in HTML spec itself:
Extensions to the predefined set of link types may be registered in the microformats wiki existing-rel-values page.
So you look there, you’ll see contents, glossary and copyright are all listed as valid rel values.
For copyright there seems to be an alternative of license value.
Yes, they’re basically synonyms, where rel=license is the latest and rel=copyright is old—though not formally deprecated. But given that rel=license is among the link types actually defined in the HTML spec itself, it’s recommended to instead use rel=license these days —but even that’s not formally mandated/required. (You can still safely use rel=copyright if you want.)
2016-03-06 update
So, the (now-deleted/struck-through) part I said above about rel=copyright not being formally deprecated is actually wrong. In fact the HTML standard says it “must not be used in documents”.
If you look at the Link types section of the spec and scroll just past the table there, you’ll see the following sentence [which I’m planning to have moved to make it harder to miss]:
Some of the types described below list synonyms for these values.
These are to be handled as specified by user agents, but must not be
used in documents.
And then if you look at end of the section for rel=license, you’ll see that is says:
Synonyms: For historical reasons, user agents must also treat the keyword "copyright" like the license keyword.
So that means the spec says that rel=copyright must not be used in documents.
So I’ll also soon be changing the HTML Checker behavior to emit an error for rel=copyright.
Related
I see this a lot on site title links in WordPress themes (probably because Underscores does it and everyone copies that):
Some Site Title
I cannot find even a semi-authoritative statement anywhere that rel="home" on an anchor tag is used meaningfully today by any browser, screen reader, or other user agent. The only "official" documentation I've located is this draft specification from 2005 on the microformats.org site.
That doc proposes home as a valid value on both <link> tags in the <head>, as well as <a> tags. Using it on a <link> has some pedigree from HTML v3, and there's reference to it in the wild from 2002. But I haven't seen anything about the <a> tag usage.
So, is including it helpful for anything/anyone? Would I do better to use <link rel="home"> in the <head>, or is that obsolete too in 2020?
The rel="page" was part of an initiative to create permalinks (see section 'Permalink detection') as part of a standard in HTML 4.
However with HTML 5 it now has no purpose and does not offer any accessibility or SEO value. It also might not validate using W3C validator anymore (not tested).
rel="something" should only be used on <link> elements, with the exception of rel="noopener", rel="nofollow" or rel="noreferrer" on anchors (<a> tags).
Note - There may be other rel="" for hyperlinks but the two stated are the only ones I can think of, it is no longer valid to use it for page locations, bookmarks etc.
Update
Thanks to #Sean who pointed out in the comments other elements can accept rel="", however MicroFormats are not the preferred way of adding structured data according to Google and their development is not as full fledged as using https://schema.org and JSON+LD.
“We currently prefer JSON-LD markup. I think most of the new
structured data come out for JSON-LD first. So that’s
what we prefer.” - John Mueller
I am obviously incorrect in what I said as it is perfectly valid, however personally I would not bother and stick with what Google prefers apart from the few items I listed.
See #Sean's answer for a bit more info on the subject.
for clarity rel="" has no bearing on accessibility
home isn't one of the allowed keywords explicitly defined by the current HTML spec as allowed values for the rel attribute. However, the spec goes on to state that:
Types defined as extensions in the microformats wiki existing-rel-values page with the status "proposed" or "ratified" may be used with the rel attribute on link, a, and area elements in accordance to the "Effect on..." field.
On that microformats page, home has the "proposed" status—so it is valid to use according to the spec.
There's a specific rel-home page within that microformats site that goes into more detail about the usage with examples. It makes the statement—
Opera browser supports rel="home"
—which would imply that Opera has some functionality tied to that usage, but it doesn't provide any additional details.
Summary: rel="home" is valid to use on a elements. It's benefits aren't clear, but it doesn't hurt to use it. The draft spec for it has been around since 2005, so there's bound to be some technologies that make use of it.
I was reading James Donnelly's answer to "Is there a standardized (Meta?) Tag for the Date of a Website?". At the end he writes:
I don't believe Hangy's answer of dc.date (now dcterms.date) would be relevant here as, as far as I'm lead to believe, the date of this is the date associated with the resource. For example, if the resource was a discussion about the Battle of Hastings in 1066, the dcterms.date could be set to 1066. The same could also be said for icas.datetime.
The definition of dcterms.date is "A point or period of time associated with an event in the lifecycle of the resource." I think the question is whether this "event in the lifecycle of the resource" means an event discussed within the resource, or an event pertaining to the resource itself.
Looking around, I found an example of the use of dcterms:date:
ex:myManuscript dcterms:date "1633"^^dcterms:W3CDTF .
The use of 1633 in the example leads me to believe Donnelly's interpretation is right (especially since the other examples on the same page use dates in the 2000s).
However, reading this post, I also discovered that Dublin Core has a dumb-down principle. Quoting from the post:
The solution to the paucity of Dublin Core elements was this thing called “qualified Dublin Core” (although that term doesn’t seem to be used much any more), in which the fifteen core elements are qualified to make them more specific — for example, dateAccepted, dateAvailable and dateCopyrighted are refinements of the core element date. According to the Dublin Core’s own dumb down principle, “a client should be able to ignore any qualifier and use the value as if it were unqualified […] Qualification is therefore supposed only to refine, not extend the semantic scope of an Element.”
This leads me to believe that Donnelly's interpretation is incorrect.
So my question is: What is the correct interpretation of Dublin Core's definition of dcterms.date?
There are two ways how the DCMI Metadata Term date can be used in HTML5 documents:
in meta-name elements (in the head element), because it’s registered as MetaExtension:
dcterms.date
in URI-based structured data syntaxes (typically RDF serializations like RDFa or JSON-LD, but possibly also Microdata):
http://purl.org/dc/terms/date (with the RDFa Initial Context: dc:date or dcterms:date)
In the latter case, you can differentiate if you are talking about the document or about the thing the document represents. You just have to give the thing a URI (see more details in my answer).
In the former case, HTML5 doesn’t allow this differentiation. The HTML5 specification defines that a meta element with the name attribute represents "document-level metadata"; "it sets document metadata". So unless it’s defined otherwise for the keyword dcterms.date (which doesn’t seem to be the case), the date should be associated with the document, not the thing.
I understand why and how to use Schema.org to add microdata to your site, this is not a question about that. The question is why Schema.org has support for certain things that can be marked up with simple HTML5. Among these are
Types
WebPage and WebSite
I can see why WebPage and WebSite would be needed, for example, to reference the page/site of a certain organization in a link, but there's no need to mark up your own page with this—the <html> tag does this.
SiteNavigationElement
Why not just use <nav>?
Table
Just use <table>.
properties
WebPage/mainContentOfPage
<main> element
WebPage/relatedLink
<link> element inside <head>
This answer is primarily about the WebPageElement types (like SiteNavigationElement).
For WebPage, see my answer to the question Implicity of web page structure in Schema.org (tl;dr: it can be useful to provide WebPage, even for the current page).
For WebSite, similar reasons from the answer above apply. HTML doesn’t allow you to state something about the whole site (and, by the way, a Google rich result makes use of this type).
Schema.org is not restricted to HTML5.
Schema.org is a vocabulary which can be used with various syntaxes (like JSON-LD, Microdata, RDFa, Turtle, …), stand-alone or in various host languages (like HTML 4.01, XHTML 1.0/1.1, (X)HTML5, XML, SVG, …). So having other ways to specify that something is (or: is about; or: represents) a site-wide navigation, a table etc. is the exception rather than the rule.
But there can be reasons to use these types even in HTML5 documents, for example:
The HTML5 markup and the annotations from Microdata/RDFa are two "different worlds": a Microdata/RDFa parser is only interested in the annotations, and after successfully parsing a document, the underlying markup is of no relevance anymore (e.g., the information that something was specified in a table element is lost in the Microdata/RDFa layer).
By using types like WebPageElement, you can specify metadata that is not possible to specify in plain HTML5. For example, the author/license/etc. of a table.
You can use these types to specify data about something which does not exist on the current document, e.g., you could say on your personal website that you are the author of a table in Wikipedia.
That said, these are not typical use cases relevant for a broad range of authors. Unless you have a specific reason for using them, you might want to omit them. They are not useful for typical websites. Using them can even be problematic in some cases.
See also my Schema.org issue The purpose of WebPageElement and mainContentOfPage, where I suggested to deprecate WebPageElement and the mainContentOfPage property.
Just use <table>.
You seem to be reading the title of the pages and no further. The <table> tag doesn't have the dozens of special properties listed on that page like isFamilyFriendly or license or timeRequired.
Schema.org microdata is intended to build a standard set of additional, semantic metadata that can be used by automated systems - search engine spiders, parser robots, etc. - to better understand the nature and features of the content.
The cite attribute specifies the address of the source of the quoted text, I think, but who uses this information?
For example:
<q cite="http://www.example.com/quote">
<p>“A quote”</p>
<footer>Person quoted</footer>
</q>
The source of the quoted text isn't visible to the end-user in a normal browser, so who does use this information, and how?
First, it's not only blockquote where you can use the cite attribute.
You can use the cite attribute on the following elements also:
<blockquote>
<del>
<ins>
<q>
Why would one use cite in above elements?
To point to where the content is taken from, or change or deletion is referred.
Here is what w3.org says,
User agents may allow users to follow such citation links, but they
are primarily intended for private use (e.g: by server-side scripts
collecting statistics about a site's edits), not for readers
Now, the question, who uses it?
The cite attribute is used to identify the online source of the quotation in the form of a URI (for example, "http://sourcewebsite.doc/document.html").
The value of the cite attribute isn't rendered on screen (although this potentially useful meta data could be extracted and written back into the webpage through the magic of DOM Scripting).
As such, browser support for this attribute is marked as none, but because it has other potential uses (for search engine indexing, retrieval via DOM scripting, and more) and there is the likelihood of improved native support being provided for the attribute in future browser versions, you should use the cite attribute when you use the above elements.
So, currently no one uses it, but in future maybe used in user-agent or my search engines, so better to use it.
Both the <cite> tag and the cite attribute are for semantic purposes, which means that they are simply for giving a website more "meaning". For example, I could use a <div> tag for a quote, rather than using a <blockquote> tag, but this provides less meaning to the browser, and hence using <blockquote> is recommended for quotes.
The same is with the <cite> tag and cite attributes. As per the MDN definition for the cite attribute (link here):
Use the cite attribute on a or element to reference
an online resource for a source.
"so who does use this information, and how?" - I believe that search engines (e.g. Google) would use this information to show potential links between documents. If you think about this it is a major point. Check out the image below:
Notice how it shows the "Samsung Group" information box on the right. The guys who work at Google don't write this information - rather, it is sourced from Wikipedia. However, this information would be of greater relevance to the search "samsung" when this information is also written on other websites, with the cite attribute linking this information to Wikipedia (hence increasing the relevancy of Wikipedia). This is why Wikipedia's information is used here, and not some primary school's website regarding Samsung phones.
The cite attribute simply provides more meaning to the website. Tim Berners-Lee has described the semantic web as a component of "Web 3.0" - in other words, many components of the updating HTML language are simply to provide more meaning onto the webpage, as a step closer to Web 3.0.
TL;DR - in simpler terms, the cite attribute is just to provide more meaning to the web page, and may be used for search engines for better web linkage.
W3C has this to say:
The value of this attribute is a URI that designates a source document or message. This attribute is intended to give information about the source from which the quotation was borrowed.
It's not visible and I can't think of anywhere it's used except perhaps by search engines.
It is meant to be used by machine which collect and arrange data eg. search engines, but it can be used by any machine. It is meant to make webpages more systematic to be read by machine. As they can not understand which part of text represent citation and quote based on only context.
you can look up Semantic Web for more information.
http://en.wikipedia.org/wiki/Semantic_Web
Yes, the source of the quotation isn't visible to end user. So it's just a reference to the source.
Definition from WHATWG.ORG:
Content inside a q element must be
quoted from another source, whose
address, if it has one, may be cited
in the cite attribute. The source may
be fictional, as when quoting
characters in a novel or screenplay.
If the cite attribute is present, it
must be a valid URL potentially
surrounded by spaces.
Quoted from W3Schools:
The cite attribute is not supported by any of the major browsers.
However, search engines may use it to get more information about the quotation.
http://www.w3schools.com/tags/att_q_cite.asp
It's just another meta data chunk that can be used by server side scripts to collect statistics or by front end developpers to add functionnalities (they can choose to print the source, allow to access the original source, etc...).
It's just a good practice to have the original source written somewhere although it is actually not very useful for the end user.
I'm getting this error in w3C HTML 5 validator
Line 9, Column 101: Bad value
apple-touch-icon-precomposed for
attribute rel on element link: Keyword
apple-touch-icon-precomposed is not
registered. …-icon-precomposed"
sizes="72x72"
href="images/sl/touch/m/apple-touch-icon.png">
Syntax of link type valid for :
A whitespace-separated list of link
types listed as allowed on in
the HTML specification or listed as an
allowed on on the Microformats
wiki
How to fix this error?
Ignore it.
If that's the only error you have, then your document is valid HTML5.
Here's what the official (in development) spec states about the <meta> tag: Extensions to the predefined set of metadata names may be registered. I can't find the area in the spec that talks about the "ref" tag values, but the validator treats them similarly (one for links, one for strings), and points us to the extension Wiki. You 'may' register them, but don't have to. In RFC terminology this is a SHOULD not a MUST.
The spec doesn't seem to mandate a fixed list, or use of the Wiki. Doing so would seem odd, as these fields have often evolved with time. It does state that Conformance checkers must use the information given on the WHATWG Wiki MetaExtensions page to establish if a value is allowed or not: values defined in this specification or marked as "proposed" or "ratified" must be accepted. which is an interesting line as it is a specification for the HTML Validators, not HTML5 itself, and doesn't itself make the markup invalid.
In fact, many of these "extensions" are already in the wiki (including your one), they just haven't been accepted. Same with many meta tags, even very common ones. It seems many won't be accepted either.
I think it's very nice of the W3C to create a standardised list of these. It helps developers know what they should be using now and in the future (and can hopefully clean up some things linke reducing the number of ways you can specify a creation date from 5+ to 1).
Unfortunately we are dealing with third parties here (e.g. Apple) – and unless you want to contact every third party who has created one of these informal specification, and tell them to formalize a spec, and submit it to the W3C's list (which may or may not get accepted) what are you to do? At the end of the day you still need to support it.
Anyway, isn't the very point of having these HTML elements to support extensions so vendors don't break the spec by adding new elements to do what the need?
If you move the touch icons into your web root and follow the Apple documentation for naming conventions, you won't actually need to insert the link tags in your HTML and will avoid those validation errors.
The iOS devices will look for the icons in the web root automatically, using the predefined naming conventions and the correct resolution as also outline here. Good luck.
Delete the element from your source.
You probably don't want to do that though. Remember that validation is a tool, not a competition.
You might want to edit the wiki of supported link types and then wait for the validator to catch up.