JWplayer with <video> tag for SEO - jwplayer7

Is there a good way of using JWplayer to instantiate a video tag in stead of a plain div?
Here's a support thread (https://support.jwplayer.com/customer/portal/questions/6062676-jw-player-not-working-with-video-tag), but basically JW admin comes back and tells the OP to not use a video tag at all.
This is the example markup from JW:
<div id="myDiv">This text will be replaced with a player.</div>
<script>
jwplayer("myDiv").setup({
"file": "http://example.com/myVideo.mp4",
"image": "http://example.com/myImage.png",
"height": 360,
"width": 640
});
</script>
SEO wise, this is utterly useless, the video won't get crawled if it's only instantiated into a plain div by JavaScript after page load.
What I want to do is to have a proper video tag on the page and then instantiate a JW player instance from it. This way the video tag is visible to crawlers without it having to execute JS (which not all do)

The JW Team removed the "support" for embedding over the <video> tag in the upgrade from JW5 to JW6, primarily because they were experiencing too many support issues with embeds failing as a result of conflicts between the initial <video> tag loading and what their code was trying to do.
I wrote an article in 2012 which explains the problem they were faced with: http://powered-by-haiku.co.uk/?p=1
Rather than fix it, they decided to go with the current embed into <div> solution.
Now, you can still technically embed over a <video> tag with JW6 and JW7 - you just need to ensure the "preload" attribute is set to "none" in the original tag, and that this video is also not set to autostart.
However, in terms of SEO using the current JW approach, there is still a way to allow search engines to index and show your videos in search - actually the biggest issue with the move away from embedding over native <video> tags is to do with accessibility - not SEO.
Check out https://developers.google.com/webmasters/videosearch/schema#adding-videoobject-to-a-video-page for details of how to add schema.org markup to your page to support video tagging.
Ideally, in time, JW will allow a built-in means to progressively enhance this Schema.org metadata and build a JW config object dynamically (like they used to do with the video tag) - as it stands however, you'd either need to do that yourself or duplicate the associated information.
Either way, the accessibility issue still exists!

Related

HTML5 video loading slow

I have videos on my website that are taking very long to load.
I don't think it is my webhost since it also happens on localhost.
Each time there is only 1 video shown to the user, depending which category they chose. (So it is not loading each video always).
The videos that take longer to load are the bigger ones (the biggest one is about 351MB video file)
This is my html code for the video:
<div class='video'><h2>$vidTitle</h2><video width='640' height='360' controls preload='metadata'><source src='$viddir' type='video/mp4'></video></div>
I've also read that it could be that the video indexing could be at the end, could this be the case?
What can I do about this, do I need to use another player thann the default html5 player (I tried this but it didn't really help) | do I need to use a cdn?
How can I solve this?
Thanks!
My understanding is that the preload='metadata' attribute in your video element is supposed to prevent the video from loading.
You could try preload='none' to test. I know that works.
As always, a good place to check is MDN web docs:
mdn web docs : The Video Embed element

Youtube Video In HTML5 <video>

I have made a windows store app using the Youtube Iframe API. I can handle events and play video fine but there is a major problem as it doesnt support full screen mode (amongst some other minor niggles).
I have been looking in the app store and I see that the majority of youtube player apps do not use the iframe API, they grab the video direct and put it into the standard HTML5 video player.
I have done a lot of searching and the only way I can see people are doing this is by parsing the youtube page to find the video file the Youtube player is going to play and loading this directly into the media player.
I have a few problems with this method.
I am not sure if this is legal as it may break youtubes terms and conditions
If page at youtube changes it can break app.
Neither of these situations are acceptable.
Is there any way to get full screen to work inside app or get a direct video stream legitimately?
Not sure about the copyright and youtube terms stuff but here is how you do it apparently:
Show Youtube video source into HTML5 video tag?
Looks like it's browser specific and youtube generates different html for different browsers.
I would make an ajax request to the youtube url appending html5-true then use jQuery to scrape the source for the video tag, add your attributes and then append to your page.
Now you have the tag that youtube uses so I'm assuming what works on their webpage will work o yours.
Probably violates all terms and conditions...

Is there any point in using the seamless and or sandbox attribute for YouTube iframes?

Update: This question is no longer valid. See comment below.
YouTube embedding is done using iframes nowadays.
HTML5 introduces the seamless attribute, that not only should affect presentation, but make the integration with the host page tighter. (It should not be announced to screen readers as a separate document.)
HTML5 introduces the sandbox attribute, that restricts the iframe and thus improves security.
In a world where browser support for these 2 attributes is complete, will they benefit or in any way adversely affect the page, when embedding YouTube videos? (Yes, the last half of the question is primarily about seamless.)
I am thinking about recommending my students to always use these 2 attributes for YouTube videos and benefit automatically as browser support becomes available.
I'll focus on just discussing the sandbox attribute.
To play YouTube videos in a sandbox you need to do the following:
Add sandbox="allow-scripts allow-same-origin"
Add ?html5=1 to the video URL
A problem with #1 is that Flash will not be loaded; whether Flash is required depends on a few things, such as the end-user's browser, their YouTube settings or when a video is simply not available as an HTML5 video (this is worsened by #2).
Another (more serious) problem with #1 is that the combination of allow-scripts and allow-same-origin effectively removes any security benefit you would have otherwise enjoyed.
Conclusion
Forget about using the sandbox attribute for YouTube video embedding.
Further reading
HTML5 Sandbox and some notes
Error playing embedded youtube video in a sandboxed iframe
No, fullscreen does not seem to work with both attributes enabled, if you are in the HTML5 beta check an example here:
http://bcmoney-mobiletv.com/view/2133/monty-python-tax-sketch/
However, when I leave the HTML5 beta program it plays back in the standard YouTube Flash player, which ignores those iFrame attributes completely.
So, it really depends what your goals are. If you want added security and an experience that feels more like an in-page web video that is controlled by your page, go ahead and use those attributes, however, if you want to give the user a full range of controls and options, leave off sandbox and/or seamless.

Use of <bgsound> tag in HTML

What is the use of the <bgsound> tag in HTML?
It is a non-standard tag which instructs the browser to load and play a sound file (famously, at least in the mid-90's, a MIDI file) while the user is browsing your site.
Except in a few very special cases, the real purpose is to time how fast the user can find his browser's "close" or "back" button. Seriously, don't use it, on almost every site sound is unwelcome.
If you do decide to use it, you'll want to consider marquee and blink as well. Also an animated-GIF construction worker "under construction" sign and purple text on a dark green background.
If you want to give the user an option of playing music on your site (e.g., because its a music site), I suggest that a flash widget is your best bet. Depending on the site, it may or may not be appropriate to auto-play the music. Alternatively, you could use the new HTML5 audio element (though support is lacking).
update: As pointed out by Adam Brown, HTML5 audio is now supported almost everywhere and should be used instead of Flash.
tells the browser to play a particular sound when the page is loaded.
link:
http://www.htmlcodetutorial.com/sounds/sounds_famsupp_18.html
The other answers are all wrong. This tag is used to get the user to close the page instantly.
A "background sound" is a sound that starts to play automatically when the web page is loaded.
This attribute is used to define what the source of the sound is. Insert the file name and file path if necessary here.
http://www.abiglime.com/webmaster/reference/html/tags/bgsound.htm

Use of Iframe or Object tag to embed web pages in another

In a web-based system I maintain at work that recently went live, it makes an Object element to embed a second web page within the main web page. (Effectively the main web page contains the menu and header, and the main application pages are in the object)
For example
<object id="contentarea" standby="loading data, please wait..."
title="loading data, please wait..." width="100%" height="53%"
type="text/html" data="MainPage.aspx"></object>
Older versions of this application use an IFRAME to do this though. I have found that by using the object tag the embedded web page behaves differently to when it was previously hosted in an IFRAME. In IE, for example, the tool tips don't seen to work (I will post a separate question about this!), and it looks like the embedded page cannot access the parent page in script, although it can if it was an IFRAME.
I am told the reason for favouring the object tag over the IFRAME is that the IFRAME is being deprecated and so cannot be relied on for future versions of browsers. Is this true though? Is it preferable to use the Object tag over the Iframe to embed web pages? Or is it likely that the IFRAME will be well-supported into the future (long after I am old and grey, and past the useful life of the application I maintain)?
The IFRAME element is part of the upcoming HTML5 standard. Also, HTML5 is developed by the major browser vendors out there (Mozilla, Opera, Safari, IE), that basically makes a guarantee that we will have an IFRAME element in the foreseeable future. Some of them have support for some HTML5 elements already, like AUDIO and VIDEO and some new JavaScript APIs.
It's also true that the OBJECT element is in the draft, but that's because IFRAME and OBJECT will have different purposes. IFRAMES are mainly designed for sandboxing web applications.
So, my advise is to use IFRAME instead of OBJECT.
If you are embedding a HTML page, here is one noticeable difference between iframe and object:
with iframe updating src will change the browser history (adding a new entry)
with object updating data will not change the browser history
Also it seems like drag&drop does not work if the page is embedded in the object tag, but works in the iframe tag. I noticed it personally using react-draggable, and I can see someone had the same issue (https://stackoverflow.com/questions/31807848/replacing-iframe-with-object-tag-drag-and-drop-not-working)
IFRAMEs are not part of the XHTML 1.0 Strict DTD. They are totally valid in in HTML 4 and XHTML 1.0 Transitional, I believe. For these reasons alone, IFRAME will continue to be supported for a long time.
A lot of bookmarklets and analytics code still use IFRAMEs.
Although the W3C specs may indicate that the IFRAME tag is being deprecated, (in XHTML at least anyway), browser developers do not necessarily follow exactly what those specs say (IE6 anyone?)
As use of IFRAMEs is so prevalent at the moment, and the W3C can't seem to decide if they are part of the future or not (HTML 4.01 vs XHTML), I am pretty sure they are the safer implementation to use for almost every browser.