I may not be using the proper terminology but hopefully I get my question across properly. What I'm wondering is if it's possible to "delay" the "creation" of a specific div, rather than just delay the FadeTo or Show jquery command.
I ask because I'm using the Vimeo API which is completely mind-boggling and frustrating (at least for me - it's a source of endless shame and I wallow in self-pity when attempting any such Vimeo API coding). What I'm trying to do is just delay the autoplay of the iframe code for an embedded Vimeo video. The problem is that I have the div containing the vimeo iframe set to hide for a good three seconds after the page loads before it fades in, but since it's just hidden the video starts playing anyway before the visitor can actually see it. I'm just using &autoplay=1 for the vimeo embed...
So, I suppose the only other solution besides getting this confusing Vimeo API to try to delay the video that way is to be able to just use a jQuery command to delay the vimeo iframe from even loading/being created on the page, until the container div fades in.
If this is possible I will bless my lucky charms. And double points if someone answers in the next few hours! Thanks so much!!!
I just editted my answer and applied it to fit your code you provided:
So what I did here is: 1) load jquery into your page2)when jquery sees your div with id="div" as 'ready', it will fire an alert that says loaded (you can remove this it was just for testing purposes), and then delay the src from loading in your iframe for 2 seconds (2000 miliseconds)
3) So you can change the 2000 to whatever time you want, and make sure the "player_1" matches your iframes id
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
<script>
$(document.getElementById('div')).ready(function()
{
alert('loaded');
setTimeout('document.getElementById("player_1").src="http://www.youtube.com/v/82CYNj7noic?autoplay=1"', 2000);
});
</script>
<div id="div" class="div">
<iframe class="iframe" id="player_1" > </iframe>
</div>
Does this work for you?? I hope I've helped!!
Related
I am trying to copy the embed code from a single Instagram reel by clicking the ... menu and clicking Embed. However, the code never loads and I get this screen. Anyone know a workaround to embed an Instagram reel on a website? The specific reel is: https://www.instagram.com/reel/Cd56By5FxBF/
See screenshot for what loads when I try to use to embed function on instagram. I have tried on multiple browsers.
Thanks
The integration code is made up of two elements. A long <blockquote> followed by a short <script>.
The <script> element should look something like this:
<script async src="//www.instagram.com/embed.js"></script>
Just add https: to the value of the src attribute, thus:
<script async src="https://www.instagram.com/embed.js"></script>
And everything should be working fine.
I understand that the background page of a Chrome extension is never displayed. It makes sense to me that a background page should contain only scripts. In what situations would HTML markup ever be needed?
At https://developer.chrome.com/extensions/background_pages there is an example with an HTML background page, but I haven't been able to get it to work (perhaps because I am not sure what it should be doing).
Are there any examples of simple Chrome extensions which demonstrate how HTML markup can be useful in a background page?
Historical reasons
The background page is, technically, a whole separate document - except it's not rendered in an actual tab.
For simplicity's sake, perhaps, extensions started with requiring a full HTML page for the background page through the background_page manifest property. That was the only form.
But, as evidenced by your question, most of the time it's not clear what the page can actually be used for except for holding scripts. That made the entire thing being just a piece of boilerplate.
That's why when Chrome introduced "manifest_version": 2 in 2012 as a big facelift to extensions, they added an alternative format, background.scripts array. This will offload the boilerplate to Chrome, which will then create a background page document for you, succinctly called _generated_background_page.html.
Today, this is a preferred method, though background.page is still available.
Practical reasons
With all the above said, you still sometimes want to have actual elements in your background page's document.
<script> for dynamically adding scripts to the background page (as long as they conform to extension CSP).
Among other things, since you can't include external scripts through background.scripts array, you need to create a <script> element for those you whitelist for the purpose.
<canvas> for preparing image data for use elsewhere, for example in Browser Action icons.
<audio> for producing sounds.
<textarea> for (old-school) working with clipboard (don't actually do this).
<iframe> for embedding an external page into the background page, which can sometimes help extracting dynamic data.
..possibly more.
It's debatable which boilerplate is "better": creating the elements in advance as a document, or using document.createElement and its friends as needed.
In any case, a background page is always a page, whether provided by you or autogenerated by Chrome. You can use all the DOM functions you want.
My two cents:
Take Google Mail Checker as an example, it declares a canvas in background.html
<canvas id="canvas" width="19" height="19">
Then it could manipulate the canvas in background.js and call chrome.browserAction.setIcon({imageData: canvasContext.getImageData(...)}) to change the browser action icon.
I know we could dynamically create canvas via background.js, however when doing something involving DOM element, using html directly seems easier.
I am building a Spotify App with four tab pages. The content of all tabs are loaded on initial load of the app. Each tab contain one or more playlists that are being populated with data from 3rd party web apis that are resolved into spotify tracks.
The selected tab works fine. the playlist show up a expected. The problem is with tabs that are initially hidden but later selected. Here the playlist looks like this when selected:
not fully rendered playlist
Looking in the Inspector I can see that the content has not yet rendered:
<div class="sp-list sp-light" tabindex="0">
<div style="height: 100px; ">
</div>
</div>
When I do a resize of the Spotify desktop app, the playlist is finally rendered:
rendered playlist after resize
To populate the playlist I use the 'standard' spotify models and views:
var playlist = new views.List(tempPlaylist);
//where tempPlaylist is a new models.Playlist();
//that has been populated with tempPlaylist.add(search.tracks[0].uri);
playerPlaylistDiv.append(playlist.node);
I am only seing this issue when using tabs. When displaying all content on one long page all playlists are fully rendered. I wonder if it has to do with timing: that I am hiding content that has not yet fully rendered? Any thoughts much appreciated.
I handle tab changes this way:
/* Handle URI arguments */
models.application.observe(models.EVENT.ARGUMENTSCHANGED, tabs);
/* Handle tab changes */
function tabs() {
var args = models.application.arguments;
// Hide all sections
$('section').hide();
// Show current section
$("#" + args[0]).show();
}
FYI I am using the Spotify preview 0.8.10.3.
I am not sure this is the same thing, but I ran into similar issues trying to create tracklistings from playlist-uris on the fly; also couldn't track it down any closer (the containing DOM was certainly rendered and ready); and it only happened on certain playlists, never e.g. on albums.
I was able to circumentvent this problem by "cloning" playlist - obviously there's a "performance" hit ...
// assuming uri is the playlist's URI
models.Playlist.fromURI( uri, function(originalPlaylist) {
var tempPlaylist = new model.Playlist();
$.each(originalPlaylist.tracks, function(t) { tempPlaylist.add(t); });
var tracklist = new views.List(tempPlaylist);
// etc...
}
I am not sure what's on here, but maybe that helps you along :)
PS. Also - make sure you have a doctype-declaration in index.html (), the spotify client does some weird things if you don't.
The solution I've found is this:
I arrowed it down to being an issue with showing/hiding the content since showing the full content without tabs never causes issues. So instead of using .show()/.hide() I now hide and show the content by setting the height of the sections to 100%/0:
// Hide all other sections
$("section#" + args).siblings().height('0');
// Show current section
$("section#" + args).height('100%');
Not sure why this works, but it does (for me at least).
I had the same problem (see Spotify List objects created from localStorage data come up blank) and fixed it by doing the hide()/show() of divs before any processing. Previously I was constructing the playlist and then show()ing the div after which led to a blank list.
I think I've actually managed to solve this and I think it's bulletproof.
Basically I was trying to solve this by trying to convince the API that it needed to redraw the playlist by hiding things/scrolling things/moving things which worked occasionally but never consistently. It never occurred to me to change the playlist itself. Or at least make the API think the playlist has changed.
You can do so by firing an event on the Playlist object.
var models = sp.require('$api/models');
...
// playlist is your Playlist object. Usually retrieved from models.Playlist.fromURI
playlist.notify(models.EVENT.CHANGE, playlist);
These are just standard Spotify functions and the list updates because it thinks something has changed in the playlist. Hope this helps someone!
Suppose I want the browser to load an image right on the first connection it makes to my website. How do I do that, considering that by default the image loads later on when it's actually called for?
Also, after the whole page finishes loading, suppose I want to load more objects (say images) that aren't required yet but are just for buffer. How do I do that? Help me people, I've been at it for quite a long time.
I'm somewhat successful with the first problem by adding a script tag while actually calling an image at the beginning of my index.php's html head part which goes like:
<script src="http://www.mysite.com/my/image/url.png"></script>
But this I realize is bad scripting.
As for "Why would you want to do that?", it's for educational purposes and also because when someone visits my site, I need to load and display certain things before other things get loaded.
For preloading you probably could start with
<body onLoad="Preload('image1.jpg', 'image.gif', 'image.png', ...)">
And preload is a JavaScript function which adds each of the array of images to DOM like
document.imageArray[i].src = args[i];
I have an HTML/JS app running in a webview in an iPad app. The app uses the HTML5 video tag. Videos work fine in iOS4.3 but today I've tested on iOS5 and the videos simply do not show up.
I have verified that it is not a layout related issue by setting background color and borders on the video element.
The same behaviour is evident irrespective of whether the app is run directly in mobile safari /from the home screen or within the webview.
The template for the video is simply:
<video controls src='{url}'></video> //where {url} is substituted at runtime.
The relevant video url plays correctly directly in the mobile Safari on iOS5.
I have tried to proxy the app comms and it seems that it does start loading the video but then stops, no video controls show and only the background color I have set shows thru.
Any ideas would be greatly appreciated. Thanks.
Have you tried create an empty webview, without additional parameters and scripts and make sure that you call it only once? I had the same issue when i call it twice without clearing previously created one - just audio was played.
Try to look at http://blog.millermedeiros.com/2011/03/html5-video-issues-on-the-ipad-and-how-to-solve-them/ and see if the fix works for you...
he he - should have read the fine print - did not notice you had answered yourself - remember to tick the thread off as answered
I've fixed this in code by changing the width and height by a pixel once the video element is created. Must invoke a repaint or something to that effect