Google's Rich Results Test incorrectly parses <iframe> Microdata

Google's Search Console has been pestering me for years about missing information in videos shared on Blogger. I have ignored this because I knew the information provided was correct.

However, I have recently launched a new website and wanted to validate the Microdata added to it, so I decided to go back to a post that has had issues and try to solve them. Immediately the Rich Results Test reported a problem. A problem that only exists for Google.

Maybe the VideoObject is picked up as part of the Article?



Yes, but none of the details.

So what does the Schema.org validator have to say on the subject?



Nothing. It's happy. Everything is picked up and validates correctly.

Surely the validator from the official schema site must be correct. Just in case there was a bug in there somewhere I thought I'd give Yandex a go.

Well, it does a better job than Google but there is clearly something it is not happy about. It turns out that Yandex does not like having URLs in <meta> tags. I couldn't find anything in the HTML5 spec about this, but Yandex suggest using <link> and href instead.

Confusingly, W3Schools states, in reference to the <link> tag:

The required rel attribute specifies the relationship between the current document and the linked document/resource.

This is only partially true. From the HTML5 Living Standard:

A link element must have either a rel attribute or an itemprop attribute, but not both.

Despite Schema.org being quite happy with my original layout, I caved in to Yandex and updated all my <meta content= tags to <link href= tags. This pleased Yandex.

Trying again with Google, just in case this was the issue, gave the same result. Indeed, to get Google to accept the Microdata I had to move it outside of the <iframe> tag. Google was unhappy about:

<div itemprop="sharedContent video" itemscope itemtype="https://schema.org/VideoObject">
  <iframe itemprop="embedUrl" src="foo.html">
    ...Microdata...
  <iframe>
<div>

So I changed it to:

<div itemprop="sharedContent video" itemscope itemtype="https://schema.org/VideoObject">
  <iframe itemprop="embedUrl" src="foo.html"><iframe>
  ...Microdata...
<div>

Finally this made Google almost happy and the Microdata was picked up.

But, why would I put the Microdata in between <iframe> tags to begin with? Well, there was no reason not to. Schema.org was happy with it, the code was invisible to the user, and it it looked a little bit neater to me. I have tried searching for the “rules” around data between the <iframe> tags and there doesn't seem to be any information about this. It doesn't seem to be defined. Once again: Schema.org seems to be happy with this.

However, undefined might be the problem here: if something is not defined in a standard, such as HTML5, then the treatment and behaviour of such a practice is itself undefined. Maybe, then, it's not fair to say that Google incorrectly parses the data, rather it discards this data as undefined. I would love to reach out to Google about this, but as everybody knows there is no way to contact anyone at Google about anything. Which is nice.

..almost, you say? Sadly, yes. One problem remains for Google that isn't present for Schema.org nor for Yandex.

Despite actually having itemprop="embedUrl" in the iframe tag, Google cannot pick this up. This time I believe this is Google's fault. The Living Standard states:

Every HTML element may have an itemprop attribute specified

Each token must be either:

A valid URL string that is an absolute URL defined as an item property name allowed in this situation by a vocabulary specification

So, in my opinion, Google is erroneously missing this particular itemprop. The workaround? Move the itemprop into a new link element.

I'm not overly pleased that two search engines seem to disagree on how to implement Microdata. To apparently disagree with standards is even worse. Nonetheless I am now aware of the limitations of both Yandex and Google, and what I need to do to work around them.

Blogger Template Designer does not apply web font selections

The Blogger Template Designer offers a quick and easy way to (re-)design your blog without having to faff around with the template code.

...except that it doesn't work properly.

Why?

Well, it would appear that when you open the BTD it nicely downloads all the web fonts so that you can preview them easily. The problem is that once you have made your selection the only part of the template code that is changed is the font name. There is nothing to instruct the browser that it needs to download the font in order to render it. Sadly, you will have to faff around with the template code.

The first thing to do is to find the font you wanted over at Google Fonts. In my case it is Gruppo: https://www.google.com/fonts/specimen/Gruppo. There should be a link that takes you into Google Fonts where you can play around with the fonts of your choice, and the styles of your choice. The buttons along the bottom will take you to a page that shows you what code you need to add to your page. In my case this was:

<link href='https://fonts.googleapis.com/css?family=Gruppo' rel='stylesheet' type='text/css' />

And now your selection should work. The BTD should have inserted enough into the template at this point to allow the browser to render your font correctly. If not... 😕.

Note: Things may not work nicely in Internet Explorer. That's tough luck - don't use Internet Explorer.

Google Analytics, despite ad blockers

You have noticed that ad blockers also block Google Analytics in some valiant attempt to protect your privacy. If you're one of the normals then you use Analytics so you have some idea what is going on when people visit your website, not to create a vast database of users. Indeed Google Analytics itself anonymises some of its data to try to allay the fears of the truly paranoid.

You therefore need a way of tracking what is going on.

First, let's have a quick look at what is going on with the Analytics code.

Once you have created your property, you are told to add a code snippet to your pages:

(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
ga('create','UA-12345678-90','auto');
ga('send','pageview');

YouTube Poll Cards are lush, honest!

Everyone loves polls. It's just a fact. YouTube know this so they have introduced Poll Cards to creators.



Cards are interactive elements that slide into view during a YouTube video which prompts a user to interact in one of a number of ways. You can use a Card to:

• Promote a video or playlist
• Promote a channel
• Ask users to take part in a poll
• Link to an approved website
• Ask users to donate to a non-profit
• Beg for money

Unless you're using an overbearing adblock, you'll see them in the video that you're watching.

This, of course, allows users to give you quick feedback where they might not be able to use the comments section, such as when the video is embedded into another site or a third-party application, assuming the application can handle them; or if they just can't be bothered to scroll down a bit. It offers the user an easy way to interact.

The cards can be updated at any time to ask a different set of questions. The video, of course, cannot without uploading a whole new video, bar simple editing like video quality. If you add your own comment asking questions it could be buried under the avalanche of xenophobic bilge that always fills a YouTube comments thread. This way your question will be seen.

You can change your answer too, should you choose the wrong option the first time.

If you're a creator in good standing it is incredibly easy to add a Poll Card.

From your My Videos click on the drop-down menu next to the video you want to add a card to and select Cards.

Once you're in there, pick the position of the video where you want your teaser to appear then click Add card. From there you can select Poll and fill in the details. It is a very simple interface: there's no room for confusion.



Click Save and it's done! You can click on the little i to see your new Poll card. Lush.

YouTube does NOT listen to copyright claims

Last year I wrote about how YouTube does listen to copyright claims.

After writing that I realised that YouTube, in fact, don't even get involved. Their Content ID system finds a match, and a copyright claim is automatically triggered by the system on behalf of whoever claims to own the copyright, even when they don't.

The result being that they then start receiving revenue for your video.

Now, if you're idiotic enough to steal another person's copyrighted material then that's your tough luck, but if the person making the claim in the first place has no claim at all then they're effectively stealing from you, and that is a criminal offence.

YouTube is utterly broken

Google have recently made a whole bunch of changes across most of their platforms to, apparently, integrate more easily with Google+. One of the platforms affected is YouTube. But YouTube also decided to introduce a new video format at the same time, namely 140p (around 32kbps, presumably for dial-up users).

At the exact same time my ISP, O2, sold their broadband network to Sky, more's the pity. I have been informed that there should have been no changes to my ISP in any way... yet.

If that is the case then YouTube is definitely broken.

Nuisance 1
Connection: Ethernet --> ADSL2+

The first problem which became apparent was that the Wii client couldn't play videos any more, or not for more than a few seconds anyway. When it did play it would randomly stop to buffer only a few seconds at a time, and sometimes give up altogether and exit the video. I am not alone:
YouTube on Wii keeps buffering. It won't load more than 30 seconds of video.

Nuisance 2
Connection: Any

The second problem was on the trusty browser. In my case Chromium on Ubuntu 12.04.

I seem to have been volunteered to join the HTML5 trial, which I really didn't mind except that it doesn't bloody work.



The video above is Big Buck Bunny downloaded in H264 format at 1080p. It refuses to play in the HTML5 player. To be fair this has only been uploaded a few hours ago and may need time to prepare/transcode/whatever, but as a general rule the HTML5 player fails on videos a LOT.

Switching back to Flash for affected videos can still give the same message, but continually hitting refresh tends to get the damned thing working.

Nuisance 3
Connection: Any

Another problem is that the video will play for a few seconds, usually the magic number of 19 seconds, and then stop, never to continue. Hitting refresh a number of times is required for this to start working too. See the video in Nuisance 4 for an example of this.

Nuisance 4
Connection: Wi-Fi --> ADSL2+

With my 3Mbps down connection I have been able to play 720p YouTube videos for quite a while. If someone else is on the network then it would happily drop down to 480p and play nicely. Not any more!

For reasons unknown the quality jumps up and down, preferentially towards the new 144p format. This is simply ridiculous! At 144p some videos are nothing more than a jumble of pixels. I have deliberately chosen a picture slideshow to show this as quality should be easy to maintain (very little motion). The video is 1080p.



This video shows a typical example of what happens (approximate times):

0:00	"An error occurred, please try again".
0:27	480p
0:37	Video stops altogether as the download stream fails and there is not enough video buffered.
0:45	144p
0:55	480p
1:13	240p
1:45	360p
2:20	144p

Perhaps the ISP or the connection to the router is the problem? Well, I tested this by downloading Big Buck Bunny. This was over Wi-Fi. Caution: this is a very dull video.



tldw; The video basically shows a number of drops in download speed. If I was sensible I would compare this to a wired connection but I don't feel there is any point: the drop-outs are minimal and very short lived. The download (of Big Buck Bunny) is not affected. I also have no other problems with connection on this computer ever. I feel fairly safe to conclude that the signal is not the problem and given that YouTube is supposed to buffer to avoid these problems, that this is not the cause. Uploading is a very similar story. In this instance it's an upload to YouTube of Big Buck Bunny. An equally dull video.

Reported.

Nuisance 5
Connection: Wi-Fi --> Any

On mobile, the video usually plays quite well, but recently has decided to simply pause for no reason. Hitting play will start it up again but... Nuisance 6.

Not tested over a mobile network yet but I cannot imagine it makes a difference.

Reported.

Nuisance 6
Connection: Any

On both mobile and web the video should buffer. It doesn't really matter if it does, however. Once paused, either intentionally or because the mobile just felt like it, the video continues to buffer. When clicking play the entire buffer is lost and the video starts downloading again. What the Hell is the point in the video buffering if it's just going to dump the buffer anyway? A wonderful waste of bandwidth.

Pausing used to be useful if I wanted to buffer a whole video in 1080p and watch it in this higher quality. Now it is simply impossible!

The Android app has a solution: pre-loading. Add the video to "Watch later" and it will download the whole video. Annoyingly if you don't watch every video you have pre-loaded immediately then there is a notification on the phone "reminding" you that you have pre-loading enabled and you're not watching the videos. P.I.T.A.

Nuisance 7
Connection: Ethernet --> Powerline --> Ethernet --> ADSL2+

This has never worked. I have a Philips Blu-ray player which comes with a YouTube app (probably Java).

The problem being that the bloody stupid thing makes no attempt to discover the maximum download speed. This means that it will play at the highest quality, no matter what it is. At 3 Mbps my connection cannot handle 1080p (or in some cases 720p) and so continually stops, buffers a BIT (pausing is no use) and then goes through the process again. There is no solution. Even using the Android app the quality cannot be amended.



I thought this app may be maintained by Philips, but it has the same layout as other T.V. apps for YouTube so I don't know who maintains the code. Either way it's cack.

Reported.

Nuisance 8
Connection: Ethernet --> Powerline --> Ethernet --> ADSL2+

Same equipment as above. The Wii works fine using the Android app as a remote control. On the Blu-ray player it often does whatever the Hell it likes. It nearly always starts the video twice, sometimes three times, and often randomly switches the video. Sometimes it plays a video I played a while ago because it seems to have created a play list and decides to play that from the beginning. The whole thing is just garbage! The responsiveness is generally poor on the YouTube app on this Blu-ray player anyway. The Blu-ray player itself seems underpowered but it plays all kinds of HD files without any problem.

(The Picasa app cannot handle video at all, but makes no attempt to filter them.)

I'm sure there are more but I think I've said enough for now.

YouTube is utterly broken!

YouTube does listen to copyright claims

I'm sure YouTube users are familiar with the blanket copyright notices that are sent whenever music is added to a video.

My video, a fly-by of the Lancaster Bomber at the Sunderland Air Show 2012, had the music "The Dam Busters March" playing throughout. The link being, of course, that the Lancaster was used by the real dam busters and used famously in the film of the same name. I did not add this music: it was playing while the video was being recorded.

Within hours of uploading the video I received a copyright notice via e-mail, and had to defend my use of the audio track. There are a few concerns with this that I will highlight in a moment.

My argument was that the movie "The Dam Busters" was actually released in 1955, and under U.K. copyright law the theme to this film is now in the public domain.

YouTube listened. Actually, YouTube have nothing to do with it. The faceless corporation making the claim agreed, and removed said claim.

This is nice, and everything, but if I hadn't bothered to do the research then my video would have been silenced.

• Why do I need to do the research? The people claiming to own the copyrights should know that they have no claim! Claiming that they do is an offence.
• How often does this occur? Are companies creating false claims all the time in order to drive people to their websites to increase revenue?
• Why are YouTube letting this happen? It seems anyone can make a copyright claim, and this certainly isn't the first time that this has occurred.