I have a set with webp and jpg files as alternative images for incompatible browsers.
Do I understand correctly that in the column "Initiator" the entry "imageset" means the loaded image and "vendor-main.chunk..." means the alternative image?
I have inspected the DOM element and it shows me under current source that the webp image is being loaded correctly.
Both have the status 200.
Will the alternative image still be loaded, even if the browser uses the webp image?
Here are 2 Screens from the DevTools:
edit 1:
Here is some jsx (react) code for selecting the appropriate image:
<ImgContainer>
<ImgItem animate={animationImg1}>
<picture>
// if the browser support webp images
<source srcSet={img1Webp} type="image/webp" alt="Praxis Hauptraum" />
// if the browser does not support webp images
<source srcSet={img1Jpg} type="image/jpeg" alt="Praxis Hauptraum" />
// Fallback if the browser does not support the picture tag
<img src={img1Jpg} alt="Praxis Hauptraum" />
</picture>
</ImgItem>
....
edit 2: screenshot showing the images on the site:
edit 3: Screenshot from Dom of the section "Praxis". This Section contains 3 images as picture tags.
"imageset" in the Initiator column basically means an image loaded from a given set of images to choose from defined within HTML. In your case it means via <source srcSet="..." /> in your <picture> elements.
"vendors~main.chunk.js" in that column means the related image got loaded through a JavaScript call. The request for that image happens on line 25114 of that script.
So both requests obviously happen independently from each other and the one caused by the script is redundant.
In order to find out what exactly is causing the request to the JPEG image, you need to click the last line in the call stack (main.chunk.js:1:89). That switches to the Debugger where you can see what statement is the origin of the request. (You may want to pretty-print that script.)
From that line you can step into the function calls that lead to the request.
Related
Please, I use a small fixed [btm right of page] pair of buttons (an up and a down) for in-page navigation. I also have a larger return arrow with the code snippet below meant to go back to the previous html page menu:
<div id="Div-icon-returnback-indiv" class="IconOpacityControl-p5">
<a href="#Previous" onclick="history.back();">
<img id="icon-returnback-indiv" src="./Button-PREVIOUS-AD151D-E.png" alt="Previous"/></a>
</div>
Emanating from the parent page and intended return to page of
[eg.] http://gladheart.royalwebhosting.net/Menu%20-%20Rivers%20of%20Mind%20and%20Heart.html
the problem then develops on the child page when its up or down buttons are used. Using them effectively adds my associated id(s) of #Top and #Bottom to the initial child page URL string of [ie]:
http://gladheart.royalwebhosting.net/Poetry%20-%20Alive%20and%20Living%20in%20this%20Body.html
and it thus becomes appended as a new 'history' entry of [ie.]
http://gladheart.royalwebhosting.net/Poetry%20-%20Alive%20and%20Living%20in%20this%20Body.html#Bottom
There could, if the child page up and down arrows are used more than once, even then be more than one unwished for '#'(id) ending up being stacked in 'history.back'. Is it possible to javascript parse the stack until the first result that is free of any '#'(id) string at the end of the path [in my case specifically eliminating '#Top' and/or '#Bottom' if it makes it easier and dealing with the original unappended URL of the of the child page being navigated up and down on] to then use that result in the above 'onclick="history.back()' code snippet I am presently using to send it back to the parent html page where it really came from, not the top or bottom of the current child page?
As I commented below, perhaps #Will Peavy 's suggestion [in another thread] of 'document.referrer' (instead of 'history.back') might be the shortcut silver bullet if I used the correct syntax dragon. In my above code snippet, I have tried to no avail substituting the syntax of:
<!-- failure -->
<a href="#Previous" onclick="document.referrer();">
<!-- failure -->
Good Afternoon, I created a banner ad in HTML5 using div containers and css3 animation. I submitted my banner to who i needed to submit it to and they responded they want a gif file. I'm a little confused as to what they need. how do i convert the html5 to a gif. It seems they're following XAXIS/Google ADX criteria. I know that they do not actually want an animated gif, but are looking for a backup of sorts. Never dealt with this type of stuff so your help is greatly appreciated. Here's the documentation:
Initial Load - 200kb
Secondary Load
Max Additional Load - 1 MB
Max number of file requests – 15
Backup static image must be supplied separate from the HTML5 zip for trafficking
DCM doesn’t accept HTML files which are made using the SWIFFY tool
HMTL must include at least 1 clickTAG (See Below for the clickTag supported by DCM)
<html>
<head>
<meta name=”ad.size” content=”width=300,height=250”>
<script type='text/javascript'>
var clickTag = 'https://www.google.com';
</script>
</head>
<body>
[The rest of your creative code goes here.]
</html>
Please ensure that your creative uses the clicktag variable as the click-through URL:
<a href='javascript:window.open(window.clickTag)'>
<img src='images/dclk.png' border=0>
</a>
</body>
</html>
All banners require a static backup gif (or jpg, or png) that displays when the animated version fails to load. If you don't have a Photoshop layout to make a static version from you can do this:
Run the banner locally in your browser
Take a screenshot of the frame you want for the static version
Crop the image down to banner size & save as gif, jpg, png or whatever
So the new Picture element looks like this:
<picture>
<source ... />
<img browsers will fall back to this width="10" height="10" />
</picture>
In our CSS, we want to set say a background color.
picture {background-color: red};
img {background-color: yellow};
Will a Picture enabled browser just show a red background, while non enabled browsers show a yellow background? Or a combination of the two. Likewise, will an Picture enabled browser see the height/width attributes on the img element, or is the img element ignored completly?
The idea of the picture element is that that it simply provides source information for its enclosed img element, and that it is always the img element that is rendered, not the picture element.
However, I can't see anything normative in the spec that suggests that the picture element will be treated by default as anything other than an inline element, so I expect that you will be able to style it with a different display setting, give it padding etc., in the same way as you can do with span elements, in which case, the background-color will behave in the same way as a span element around an img element does today.
So targeting both might be appropriate. The backgrounds will simply layer as normal. But the img will be rendered, so in your scenario, the background behind the image will be yellow, assuming of course that the img has at least some degree of transparency.
Since no browser supports it, guess we'll need to wait to see the implementation, but by the looks of it so far, and according to current docs, it seems img tag will be completely ignored and only used as fallback.
The new implementation is as follows:
<picture>
<source media="(min-width: 64em)" src="high-res.jpg">
<source media="(min-width: 37.5em)" src="med-res.jpg">
<source src="low-res.jpg">
<img src="fallback.jpg" alt="This picture loads on non-supporting browsers.">
<p>Accessible text.</p>
</picture>
since you'll need to define the images inside <picture> element as sources and you won't have an img tag, implementation in browsers with Picture implementation shouldn't recognize anything inside an img tag unless the media src isn't defined.
However, it's easy to see this approach will cause a double download of images since browsers download all <img> tags first. Because of this, there's a proposal by David Newton: to use <object> or <embed> as fallback image containers to avoid duplication of images being downloaded.
All the above being said, we just need to wait, but in short, my answer is that your first option picture {background-color: red}; is the correct one
Good day.
When we use Google Analytics on site wordpress, we get point on page:
Tell me plase why and how create this point and how delete her ?
You might have CSS that automatically adds borders to all the images on your site.
You are using a No Javascript version of Google Analytics with an image (1x1) like this one:
<img src="http://nojsstats.appspot.com/UA-123456/your-website.com" height="1" width="1" >
You could try to adjust your CSS to remove the borders of this image.
For example you could target the relevant image source (not supported by all browsers):
img[src*="nojsstats.appspot.com"]{visibility:hidden;}
I am using a HTML5 video tag in my website. That video is playing perfectly with all browsers, but in IE9 it shows a black border(black extension). It is like the one usually the video players will show some black color extension on its both the side when the size of the player is more than the size of the video.
This is the solution we use.
For video, we display HTML5 by default backed in CDN storage. We also have fall back for Flash and then fall back for non-flash. So it checks HTML5 first, then flash failing that and then no content for non-flash support indicating some message about the user to upgrade their Fred Flintstones machine, we also offer an alternative so they can move out of BedRock!
Code
<style type="text/css">
.videobox{position:relative;width:300px;500px}
#video_box_id_css, .video_box_class{border:0px !important}
/* BACKGROUND SHOULD BE PAGE BACKGROUND */
.left{position:absolute;width:3px;height:500px;left:1px;z-index:10;background:#fff}
.right{position:absolute;width:3px;height:500px;right:1px;z-index:10;background:#fff}
</style>
<div class="videobox">
<video id="video_box_id_css" class="video_box_class" autoplay loop width="300" height="500">
<source src="http://video.cdn.com/xxxxxxxxxx/704_black_VP8.webm" type='video/webm'/>
<source src="http://video.cdn.com/xxxxxxxxxx/704_black_libtheora.ogv" type='video/ogg'/>
<source src="http://video.cdn.com/xxxxxxxxxx/704_black_x264.mp4" type='video/mp4'/>
<!--
ALTERNATIVE CONTENT LIKE SWF
VIDEOS FOR NON HTML5 BROWSER
//-->
</video>
<div class="left"></div>
<div class="right"></div>
</div>
Code Info
Our code is above (removed the flash so it is more readable). A side thing to note is we add a left and right div column which goes over the video black borders. You can tweak these and even add a bottom and top if needed.
Photo
The green border is actually the white div in opacity so you can sit the effect. It may be hacky but it the best solution we found.
Final
The result is much better as you can see below:
I've had this issue before, usually the problem lies within the video itself. When you encode your video try to match the settings as closely as possible to what you will use in your tag. It shouldn't be a roadblock for you, once you inspect the video a bit closer you should see a discrepancy.