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.
Related
Fragments (or hashes) in URL are widely used to specify some specific fragment in a document.
For example, the fragment below
http://example.com/page.pnp#<fragment>
Usually references something like <div id="<fragment>" /> or <a name="<fragment>" /> in a HTML document.
There is a standard to support CSS selectors as a fragment, like so:
http://example.com/page.pnp#css(<CSS selector>)
Are there any applications using it? Would it be nice for browser to support it? For example, browser could display only the selected fragments of the page or highlight the selected fragments. Or provide an option for developers to highlight the selected fragments with CSS or JS. Can somebody submit it to the relevant browser devs as a feature request?
What are other ways to reference specific content in a HTML page? For example, if I want to comment on some specific element in a HTML page, what are any other ways to specify that position in the document, preferably by using URI, or some other convenient identifier?
The document you link to isn't really a standard; it even says "Unofficial Draft" in the subtitle, and under where it says Status:
This document is merely a public working draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organisation.
... so it is completely inappropriate to refer to it as a "standard". A better term for this would be "concept" or "experiment".
That being said, rudimentary implementations exist (or at least, they did at the time it was first published) in the form of browser extensions; you can find links to these in section 8.
AFAIK, though, there hasn't been any activity around this at all after the first few months since the community group for this was formed and I joined. Either it never gained traction or it just wasn't very feasible to implement after all.
For now, as always, fragment identifiers can only point to elements with the respective id attribute, or named anchors. It seems it'll remain that way for the foreseeable future.
For Chrome, There's a Jquery Fragement selector extension:
With the advent of edge extensions it will likely become easy to implement in edge.
Microdata with Schema.org already better describes any element than HTML5, it seems redundant? For example:
<nav itemscope itemtype="http://schema.org/SiteNavigationElement">
<!-- might as well just be... -->
<div itemscope itemtype="http://schema.org/SiteNavigationElement">
and
<article itemscope itemtype="http://schema.org/NewsArticle">
<!-- might as well just be... -->
<div itemscope itemtype="http://schema.org/NewsArticle">
Some elements create an "outline" for the webpage, but aside from that what's the point? Why not just use divs and forget about the semantic tags, and just use Microdata and Schema.org?
The schema.org definitions are specifically for applications such as search engines (From What is schema.org?):
This site provides a collection of schemas, i.e., html tags, that
webmasters can use to markup their pages in ways recognized by major
search providers. Search engines including Bing, Google, Yahoo! and
Yandex rely on this markup to improve the display of search results,
making it easier for people to find the right web pages.
Your mark-up needs to be understood by browsers and screen-readers as well as search engines (from the schema.org Getting started page):
Usually, HTML tags tell the browser how to display the information
included in the tag. For example, <h1>Avatar</h1> tells the browser to
display the text string "Avatar" in a heading 1 format. However, the
HTML tag doesn't give any information about what that text string
means—"Avatar" could refer to the hugely successful 3D movie, or it
could refer to a type of profile picture—and this can make it more
difficult for search engines to intelligently display relevant content
to a user.
So microdata allows you to add additional semantic meaning to your mark-up (using definitions provided by schema.org) which can be ignored by applications which don't need it, such as browsers, and read by applications which do, such as search engines.
Microdata is not a replacement for using the appropriate semantic-HTML tags where available, it should be used to augment that information. So the simple reason to use nav and article tags along with the microdata is that these tags have meaning to browsers and screen-readers, while the microdata does not.
Actually, your examples are fairly simplistic. I would suggest you have a look at some of the examples on the schema.org getting started page to see how microdata can be used more meaningfully.
To see microdata being used in practice, try googling yourself and inspecting the results. If I search for myself, the first three results (LinkedIn, github and my portfolio page) all display information marked up using microdata which google can pull from the pages and present to the user to help provide more meaningful search results.
The vast majority of terms that we have in schema.org have no overlap with HTML terminology, since they represent kinds of real world thing such as places, processes, products etc.
The problem area highlighted here is the small set of terms around http://schema.org/WebPageElement . I am not aware that any current search engine features make specific use of these, and I would suggest that any publishers who do see value in their use should also employ the corresponding pure HTML markup as well.
I work on a website that recently had Schema.org markup added to it, but I think it is being used wrong.
Schema.org gives the example of
<span itemprop="name">Generic Name Here</span>
Our website implemented it in the following way
<span itemprop="name" content="Generic Name Here"></span>
Is the second way, our way, considered cloaking? We display the data to the user but at a different point and it is not marked up with itemprop.
In HTML5, the content attribute is only allowed on the meta element. Microdata doesn’t define it as global attribute either. But RDFa extends HTML to make content a global attribute.
According to your example, you are using Microdata. So you shouldn’t use the content attribute for span.
Microdata defines a way to add name-value pairs without having to mark up visible content: Microdata extends HTML5 to allow meta and link in body (in the future, this will be defined in the HTML5 spec directly; see the "Contexts in which this element can be used" for link and meta in the HTML 5.1 Editor’s Draft).
So instead of
<span itemprop="name" content="Generic Name Here"></span>
you should use
<meta itemprop="name" content="Generic Name Here" />
For schema.org, see Missing/implicit information: use the meta tag with content:
This technique should be used sparingly. Only use meta with content for information that cannot otherwise be marked up.
If you want to stick with microdata schema then you need to switch to the meta tag, exactly as 'unor' has written and explained very well. However, you could go with JSON-LD and put everything in the header and eliminate the badly written microdata if you want to save time. JSON uses the same schema method as microdata, but the coding is different.
I mean technically it correlates with the ideology of cloaking in the sense that the spiders are seeing something that the users aren't. Which is why i'm inclined to advise you to avoid such markup but also i'm not sure upon googles stance; as such markup isn't indicative of cloaking for SEO.
"Cloaking is a search engine optimization (SEO) technique in which the content presented to the search engine spider is different from that presented to the user's browser." .
Source - Wikipedia
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.