So, I'm just trying to put a simple html5 video player on this clients website while I do the rebuild.
Thought it would have been a straight forward thing to do but when I checked it in FF all I see is a dark box with a grey "x" in it.
I am using the latest FireFox 3.6.12.
You can see for yourselves here.
This is the code Im using - I thought it was valid html5 - maybe not?
CODE :
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="reel2.css" type="text/css" media="screen" />
<title>Christopher Stewart - Theatrical and Commercial Reels</title>
</head>
<body>
<div class="main">
<div class="header">
<div class="back">
<img src="http://thechristopherstewart.com/REEL_files/ChrisStewart_Website.jpg" />
<span class="backbtn">——back</span>
</div>
<span class="page_title">Christopher Stewart: Video Reel</span>
<div class="theatrical">
<span class="title">Theatrical Reel</span><br><br>
<video width="640" height="480" preload controls>
<source src="reelvids/120610-reel.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
<source src="reelvids/120610-reel.webm" type='video/webm; codecs="vp8, vorbis"'>
<source src="reelvids/120610-reel.theora.ogv" type='video/ogg; codecs="theora, vorbis"'>
</video>
</div>
</div>
</div>
</body>
</html>
* EDIT 12/6/10 - 3:00pm *
After following a a tip that the video did not seem to be on the server I investigated; the video is on the server but is only accessible if ftp is entered into the browser - otherwise a 404 error is generated. Not sure why this is happening - if anyone out there knows how to fix this please let me know!
Thanks for all the great help!
It seems that out of those three only the .mp4 file exists on the server. Is that on purpose? Firefox probably doesn't support the codec used in the .mp4 file, and tries to fall back to your fallbacks which don't exist.
Edit: I can see that you're using IIS as your HTTP server of choice. I'll avoid going into your choice of software for now, but if the files actually exist on the server, this is likely caused by IIS's policy with unknown file extensions. IIS is made so that it refuses to send any files with unknown extensions to the client. If the extension is unknown, it returns a 404 error. IIS has a subcode of sorts for this, which it may show on its own error pages, but obviously the true HTTP error code is always 404. The code for "file not found" is 404.0, while the code for "unknown file extension" is 404.3 (here's a complete list of error codes).
You need to add those file extensions into your IIS configuration with the correct MIME types.
The problem was fixed by configuring the IIS as Matti Virkkunen suggested. The IIS for GoDaddy's hosting does not include the theora (.ogg, .ogv, .oga) file extensions or the .webm extension by default. This means that if you put a file with any of these extensions onto the server they won't be recognized and thus (in an effort to protect the user) will not be allowed to be viewed/interacted with by the user.
One way to solve this is to create a web.config (aka an xml file with a config extension on it) to force the server to accept certain MIME types. Then upload it onto the root hosting folder. Be careful you do not overwrite an existing web.config as it could cause your site to crash. Also, telling the IIS to allow a file type that it already allows (.mp4 for instance) will also cause unexpected errors. Before creating/editing your web.config file be sure to check in with the IIS's default permissions.
This is what my web.config file looks like to fix the GoDaddy IIS problem :
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension=".ogg" mimeType="audio/ogg" />
<mimeMap fileExtension=".oga" mimeType="audio/ogg" />
<mimeMap fileExtension=".ogv" mimeType="video/ogg" />
<mimeMap fileExtension=".webm" mimeType="video/webm"/>
</staticContent>
</system.webServer>
</configuration>
As far as I know FF3.6.x does not have HTML5 support. It does support HTML5 video tag, but only for specific codecs.
This is from http://support.mozilla.com/en-US/kb/Youtube%20HTML5%20does%20not%20work%20in%20Firefox
Youtube is currently testing HTML5,
but does not list Firefox as a
supported browser. While Firefox can
display HTML5 video, Youtube uses a
patented codec to encode the videos,
making it unusable by open-source
software like Firefox.
I used your code with my own videos, and if the referenced video files exist and are of the proper format, everything works.
Related
I am trying to leverage the rich text messages with open graph meta tags. So I have included my meta tags in my website head and it passes all of the Facebook debug and iOS API validation tool.
Yet when I text the link to people either on Android or iOS it doesn't often work. It works typically with Facebook messenger
Does anyone know if this is a cell carrier issue or do I have something configured wrong?
<meta property="fb:app_id" content="********" />
<meta property="og:type" content="website" />
<meta property="og:url" content="https://dameranchdesigns.com/" />
<meta property="og:title" content="Dame Ranch Designs" />
<meta property="og:description" content="Divinely inspired logo graphics and
website design. A whole new way of being ... on the internet." />
<meta property="og:image"
content="https://dameranchdesigns.com/images/logos/DRDSunLncropped.png" />
Yetter,
A couple of quick things to help you out here:
Apple Support Open Graph for rich SMS messages only since iOS 10+, so make sure that the device you are testing the sent text message to is at least iOS 10 (or higher)
Apple only supports og:title and og:image. It ignores the rest (so in your example above, og:description is completely disregarded. Furthermore, if your og:image is a gif image, Apple doesn't support that.
Your url in the text message needs to be on it's own "word" meaning there needs to be at least a space between it and any other word in the text. Furthermore, and perhaps most importantly, it needs to specify a scheme, so either: http:// or https://.
You can only have one hyperlink to your site with the og:tags. More than one shuts this functionality down.
Lastly, I don't believe Android supports such rich messaging functionality in it's SMSs (at least not with Open Graph) -- at least as far as I know as of this writing (Nov-2017). It would be great if they adopted OG as a standard.
So for example These wouldn't work:
you were invited. You can join on: grapevite.com //no scheme present
you were invited on http://grapevite.com. Care to join? //Link is between text.
Whereas these would work:
you were invited on Grapevite. http://grapevite.com
http://grapevite.com. The world's premier platform for creating, sharing and joining experiences
Reference Reading:
Some sites like these would provide you with some insight as to the above: https://uplandsoftware.com/mobile-messaging/resources/blog/what-ios-10-means-for-mobile-messaging/
https://www.tatango.com/blog/ios-10-what-sms-marketers-need-to-know-and-do/
A bit of an update for anyone dealing with this mid-2019. I was dealing with this today. I was trying to specify a certain thumbnail to be shown in the rich message preview across Facebook messenger, iOS messages and android messages.
Using actual code from the website I was working on. Be sure to replace content with your own.
These 4 tags made it work for me on Facebook messenger and iOS messages:
<meta property="og:title" content="Software to manage leasing and rental applications" />
<meta property="og:type" content="website" />
<meta property="og:url" content="https://geteagle.com.au/products/leasing-tools/" />
<meta property="og:image" itemprop="image" content="https://geteagle.com.au/site/templates/images/logo-og-white-big.jpg" />
For some reason, android messages refused to show the thumbnail I specified. I did a lot of research and tried everything I could find in this other question: Showing Thumbnail for link in WhatsApp || og:image meta-tag doesn't work
My tags bloated to 9 (8 meta, 1 link), but it was actually the link tag that made it work in android messages:
<link itemprop="thumbnailUrl" href="https://geteagle.com.au/site/templates/images/logo-og-white-big.jpg">
I'm not sure if the other tags are needed in addition to the link tag to make it work on android messages, but here is the full block if you want to try:
<meta property="og:title" content="Software to manage leasing and rental applications" />
<meta property=”og:description” content="Eagle offers a suite of of leasing tools and application management features to power-up your rental team!" />
<meta property="og:type" content="website" />
<meta property="og:url" content="https://geteagle.com.au/products/leasing-tools/" />
<meta property="og:image" itemprop="image" content="https://geteagle.com.au/site/templates/images/logo-og-white-big.jpg" />
<meta property="og:image:secure_url" itemprop="image" content="https://geteagle.com.au/site/templates/images/logo-og-white-big.jpg" />
<meta property="og:image:width" content="1000" />
<meta property="og:image:height" content="500" />
<link itemprop="thumbnailUrl" href="https://geteagle.com.au/site/templates/images/logo-og-white-big.jpg">
Many thanks to this particular answer from the question mentioned above that resolved my frustrating situation.
Hope this helps. Good luck!
I've browsed through all other IE8/Respond.js questions here on SO, but no luck so far.
When I test on localhost in IE8 emulator, I get the same error as in production, but Respond works despite that. First we see a broken page for a second, then Bootstrap's grid comes in place and everything is okay. However, in production it stays broken.
The error I get comes from respond-proxy.html file, line 46 (ajax): Permission denied
This is what I got in my base html file:
<!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
<script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
{# <!-- Respond.js proxy on external server -->#}
<link href="https://maxcdn.bootstrapcdn.com/respond-proxy.html" id="respond-proxy" rel="respond-proxy" />
{# <!-- Respond.js redirect location on local server -->#}
<link href="{% static "img/respond.proxy.gif" %}" id="respond-redirect" rel="respond-redirect" />
{# <!-- Respond.js proxy script on local server -->#}
<script src="{% static "js/respond.proxy.js" %}"></script>
<![endif]-->
I've tried moving it around (end of head, end of body etc.) but nothing seems to work in production.
We host our static files on S3 (CloudFront). We copied CORS config from here: https://github.com/scottjehl/Respond/issues/152
I also tried copying the respond-proxy.html into a file hosted along with our static files, but still get the same "Permission denied" error.
Any solutions, workarounds, hints and suggestions are more than welcome.
Edit: I also tried some substitutes like css3-mediaqueries-js, but that didn't work at all.
A site I am working on: http://ninthmind.com, looks good remotely in all browsers except Firefox 29.0.1. I have cleared my cached and searched for syntax errors. The weird thing is it looks as expected locally on my machine in the same Firefox browser.
There is a video element within the site that is also not appearing (only remotely in firefox) despite having both mp4 and webm sources. In the code below the class "invis" changes the mask's and the video's display to none for mobile devices.
<div class="header">
<img class="invis" id="mask" src="images/mask.png">
<video class="invis" id="brain" autoplay loop>
<source src="video/brain.mp4" type="video/mp4">
<source src="video/brain.webm" type="video/webm">
</video>
<div class="welcome">
<h1>Welcome to</h1>
<img id="logo" src="images/logo.png" alt="Logo">
<h3>subheading</h3>
</div>
</div>
That webm file is being served with the wrong mime type. It should be "video/webm" but it's being served as "text/plain". You probably have this set up correctly on your local machine (or you're using "file://") but not the remote server.
These instructions should help you:
http://voice.firefallpro.com/2012/03/html5-audio-video-mime-types.html
On microsoft's site they claim that simple doctype declaration is enough. But even a document as short as this falls back to IE7 mode:
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
</body>
</html>
http://d.pr/i/fvzb+
Internet Explorer makes the assumption that most webpages were written to target earlier versions of IE and looks at the doctype, meta tags and HTML to determine the best compatibility mode (sometimes incorrectly). Even with a HTML5 doctype IE will still place your website in compatibility mode if it's an intranet site.
To ensure that your website always uses the latest standards mode you can either make sure Display intranet sites in Compatibly is turned off. However you have to do this on each machine local to the web server (instructions are below).
Alternatively, and better yet, you can use the X-UA-Compatible header to turn this off from the server. It's important to note that using the meta tag will not work!
<!-- Doesn't always work! -->
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
Throughout MSDN it's mentioned that using a host header or a meta tag should override even intranet sites. The article Understanding compatibility modes in internet explorer 8 says the following.
A large number of internal business web sites are optimized for Internet Explorer 7 so this default exception preserves that compatibility.
...
Again if a Meta tag or http header is used to set a compatibility mode to the document it will override these settings.
However, in practice this will not work, using a host header is the only option that works. The comments section of the article also shows numerous examples of this exact issue.
Using a Meta tag also has several other issues such as ignoring the tag if it's not directly under the <head> tag or if there is too much data before it (4k). It may also trigger the document to be reparsed in some versions of IE which will slow down rendering. You can read more about these issues at the MSDN article Best Practice: Get your HEAD in order.
Adding the X-UA-Compatible header
If you are using .NET and IIS you can add this to the web.config, you could also do this programmatically:
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-UA-Compatible" value="IE=edge" />
</customHeaders>
</httpProtocol>
</system.webServer>
If you're not using IIS it's easy to do in any language. For example, here's how to do it in PHP:
header('X-UA-Compatible: IE=edge');
As long as the X-UA-Compatible header is present with the HTML5 doctype, a site will always run in the latest standards mode.
Turning off Compatibility View
It may still be useful to turn off Compatibility View. To do so untick Display all intranet sites in compatibility view in the Compatibility View Settings.
You can bring this up by hitting Alt to get the menu.
Edit
This answer also pertains to IE9.
This works for me..
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
Try adding the following tag to the head
<meta http-equiv="X-UA-Compatible" content="IE=11,IE=10,IE=9,IE=8" />
The meta tag doesn't do anything for intranet sites and my issue was IE10 rendering in IE10 compatibility mode. What tackled the issue for me was taking #Jeow's answer further and using that value in an http header by adding the following to web.config under IIS:
<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<!-- <add name="X-UA-Compatible" value="IE=edge" /> not good enough -->
<add name="X-UA-Compatible" value="IE=11,IE=10,IE=9,IE=8" />
</customHeaders>
</httpProtocol>
</system.webServer>
For IE purposes, intranet sites include public-facing sites that are not routed to externally - for example a Stackoverflow employee working from the office would probably see stackoverflow.com in compatibility mode.
It worked perfectly for me when i did the folowing:
On http://msdn.microsoft.com/en-us/library/gg699338(v=vs.85).aspx
Used the exact example they provide in the first box(added the missing </html> at the bottom), opened it in IE10 and standards was forced, i think you may need actual content in the html for it to force standards not sure though.
My suggestion would be to replace your empty code with actual content(something simple) and see what it does.
I've been testing the open graph tags for facebook and I can't get my logo to show when I share my website link on facebook.
If I use the lint debugger (https://developers.facebook.com/tools/debug) I get:
**Open Graph Object Properties**
og:url http://www.movimenting.me/
og:type website
og:title http://www.movimenting.me/
og:updated_time 1318267537
**Raw Open Graph Document Information**
Canonical URL http://www.movimenting.me/
Meta Tag <meta property="fb:app_id" content="210576275672723" />
Meta Tag <meta property="og:image" content="http://www.movimenting.me/images/logo2.jpg" />
Meta Tag <meta property="og:title" content="Movimenting.me" />
Meta Tag <meta property="og:type" content="website" />
Meta Tag <meta property="og:url" content="http://www.movimenting.me" />
Meta Tag <meta property="og:site_name" content="Movimenting.me" />
You can see that it gets the og:image on the raw part, but doesnt on the object properties..
Why is this? I always specify the same URL and opengraph.in gets the right tags..
thanks in advance.
everything comes out clean now on lint:
https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fwww.movimenting.me%2F
image, locale, you name it. no errors or warnings or others.
BUT STILL, when you share the link (www.movimenting.me) on facebook, no image apears.
What can I do now, or what should I look for now?
Oh, btw now i recall: if I remove the og:image tag, it will indeed find 30 images to share, but not the logo. It's so strange, since the logo is the first one..
what now?
thanks in advance
Is there any errors in the debugger? Maybe the app_id doesn't match that domain?
Late reply but I've been having the same problem even though Facebook debug would report no issues and finally fixed it.
Nothing would show up when I had a 50x50px image which Facebook didn't complain about in the debugger. I finally changed the image URL to use a 128x128px one. It worked even though Facebook complained that the image should be at least 200x200px which I then used.
You can see the fix working here. https://www.thesuiteq.com