I want to have huge background images on my site but without giving the user a hard time downloading them and the site looking ugly as the background loads.
They would be no bigger than 1920 X 1080 in size, however it's hard to say in terms of kilobytes/megabytes.
What are my options here and which are most effective?
I'm not too bothered about bandwidth, just want to user to think everything looks nice ;)
One option is to use multiple backgrounds. Have small background as bottom layer and cover it with larger background.
It might be tricky to have two backgrounds if you want it on body and want to support IE. Solution might be to start smaller body background use JS to change low-res background to high-res once it loads:
var i = new Image();
i.onload = function(){document.body.style.backgroundImage = 'url(' + i.src + ')';}
i.src = 'gigantic.jpg';
Keep in mind that such large background needs more RAM than some mobile browsers have (iPhones pre-3GS will either refuse to decode such image at all or will start purging cache/tab content in panic).
The latter problem can be worked around with CSS Media Queries:
http://lofotenmoose.info/css/destroy/media-queries-background-stretch/
Except query max-device-width instead of (virtual/zoomed) max-width.
Related
I know protecting images is far from foolproof. However, clients ask for it, so I have Javascript on a site which is designed to prevent right-click saving/downloading.
It appears that Reader View ignores both the Javascript and the site's CSS. I tried to add {display:none} based on a rule .moz-reader-content (Firefox). I've assumed this is the case in all browsers.
Searching hasn't turned up a means of detecting reader view either.
Does anyone have any suggestions or know of a solution for this problem?
As you know there are no full-proof solutions. No matter what you do, if it's visible it can be copied. (With a screenshot as a last resort).
With that being said, a simple and surprisingly effective solution is just to overlay each image a transparent .png file.
<div id="imagecontainer" style="position:relative;">
<img src="yourimage.png" style="position:absolute;top:0px;left:0px;">
<img src="transparent-overlay.png" style="position:absolute;top:0px;left:0px;">
</div>
Right-clicking on the image, would then click on the overlay and not the image itself. (Of course, you'll want to give the overlay a less obvious name).
Additionally, you should watermark the image itself.
For getting around Reader View issues (I'm not sure which Reader View you're talking about btw), you could try using javascript to actually fill the images themselves. (Assuming your reader view doesn't permit js).
eg:
var i = document.createElement('img');
var o = document.createElement('img');
i.src = 'yourimage.png';
o.src = 'transparent-overlay.png';
document.getElementById('imagecontainer').appendChild(i);
document.getElementById('imagecontainer').appendChild(o);
In the latter js example you'd also need to set your css styles to absolute position the two images within #imagecontainer.
In my hybrid Android app I use inline SVG to display images that are large (of the order of 2Mb) and complex (several hundred SVG elements per image). When I need to change the image I do the following
var puzzle = document.createElementNS(SVGNS,'svg'),
kutu = document.getElementById('kutu');
puzzle.id = 'puzzle';
puzzle.setAttribute('preserveAspectRatio','none');
puzzle.setAttribute('width','100vw');
puzzle.setAttribute('height','85.5vh');
puzzle.setAttribute('xmlns',SVGNS);
puzzle.setAttribute('xmlns:xlink',XLINK);
puzzle.setAttribute('fill-rule','evenodd');
puzzle.setAttribute('clip-rule','evenodd');
puzzle.setAttribute('stroke-linejoin','round');
puzzle.setAttribute('stroke-miterlimit','1.414');
puzzle.setAttribute('viewBox','0 0 1600 770');
puzzle.innerHTML = SVG;
//SVG here is the SVG image content shorn off the outer <svg>..</svg>
if (0 < kutu.children.length) kutu.children[0].remove();
//remove old image, iff any
kutu.appendChild(puzzle);
//append the new image
While this is working the process of displaying the new image is slow. I suspect it is because of the innerHTML assignment above. Recreating through a sequence of createElementNS, puzzle.àppendChild would require me to first parse the incoming raw SVG content etc. Is that the way to go or would there be a faster way to display the content.
Once again for clarity - SVG here is the content of the new SVG image to be displayed shorn of its outer <svg>...</svg> wrrapper.
Just a side note it would probably be better to use setAttributeNS in place of setAttribute for consistency purpose since createElementNS is used, though it might not make a difference in speeding up the SVG image change.
In the case of a native app, a tool like the Android Profiler if using Android Studio 3.0 and higher can be used to analyze performance bottleneck. However since your app is a hybrid app, some sort of performance profiler that's applicable to the hybrid app (Whether it's Ionic or Cordova, etc.) can help to pinpoint where your performance bottleneck is.
Since your app is a hybrid, without knowing the resource capacity of your android app session, the guess is it seems to be a possible cause that it calls something like .setAttribute to set session-level attributes on the fly during the change of the image and the session resource might not be enough, and also the DOM has to perform .innerHTML and appendChild, which are dynamic operations. DOM manipulation is known to be slow.
Conversion of attributes of all the SVGs and store the result in some sort of storage or cache, and when needed, call it from the persistent storage or cache might be helpful.
Or consider using AngularJS to do the SVG change beforehand and preload the SVG images, refer to easily preload images in your Angular app. Here is another similar code to yours except it's using AngularJS to add SVG for starters.
Another simpler way, without changing your code, if you could minify the incoming SVGs beforehand, is to use SVG Optimizer or SVGO, a node.js open source project to compress your SVGs. Quoted from the SVGO link it says:
"SVG files, especially those exported from various editors, usually contain a lot of redundant and useless information. This can include editor metadata, comments, hidden elements, default or non-optimal values and other stuff that can be safely removed or converted without affecting the SVG rendering result." Although the performance gain might not be obvious going this route.
I'm using OSD to display a few pages from a PDF. Each page is lined up one on top of the other.
I'd like the viewer to start at the top of the image, zoomed to fit. I've played with various settings, but what seems to work for one image of three pages, doesn't work for another image of five. I can get close to what I want with this command:
viewer.viewport.panTo(new OpenSeadragon.Point(.5, .5));
viewer.viewport.zoomTo(1);
But I'll be honest that I don't quite understand what that means, and I have no idea how to set this as the "home" bounds. I've been through the documentation several times, but this escapes me.
Appreciate any guidance!
Rather than using panTo and zoomTo, I recommend using fitBounds instead. You'll want to base it off of the aspect ratio of your viewer so the result is snug. Something like so:
var oldBounds = viewer.viewport.getBounds();
var newBounds = new OpenSeadragon.Rect(0, 0, 1, oldBounds.height / oldBounds.width);
viewer.viewport.fitBounds(newBounds, true);
The true in the fitBounds is to make it snap there immediately instead of animating.
I want to build a website that looks exactly the same across all screen width's, which means the whole website will scale according to the screen's, or more accurately, the viewport's width.
This is relatively easy to do for SVG images and I have all images correctly scaling according to the viewport's width. The viewport's width is the point of reference, from which all images scale. However, the point of reference for the text is different between any desktop browser and the iPhone's Safari (and I assume any mobile browser).
According to my research there seem to be two possible reasons for different sized text: a difference in the default CSS's or a difference in the rendering engines. Since I can't find any reference to pixel sized text on Chrome's default CSS or Firefox's default CSS, I assume this setting comes from the rendering engine.
My IP is dynamic so I can't provide a live example, but here are the screens comparing the same site in iPhone's Safari and Chrome on the desktop. Notice the huge difference in the size of the text.
Is there any way I can make the text have the same relative size in both these browsers?
I found the answer in JavaScript:
onresize=onload=function(){
document.body.style.fontSize=window.innerWidth/20+"px"
}
which sets the text size according to the viewport's width on the body element. Since all the text set in em's is sized in relation to their parents, all the text is sized correctly from the body element.
Furthermore, if you want to avoid the cascading hell by using rems and respect the original layout design from a let's say 1024px width you can stick with this:
onresize = onload = function(){
document.querySelector("html").style.fontSize = ( innerWidth * 100 ) / 1024 + "%";
}
You should try CSS Unit vw, like this:
body { font-size: 1.5vw; }
However, i am not sure it is supported by mobile browsers...
EDIT
Check for browser compatibility here.
On my website lukewattchow.zzl.org/ I have made it so that when the browser window scales down the website also scales down. However the text inside the divs need to scale down with the background, and images at the same time. Can anyone help?
i assume you will require some Javascript to adjust font size of the BODY based on some fraction of the browser's width:
(untested pseudo-code; since i never write anything HTML, CSS, or ECMAScript)
var body = document.getElementById("theBody");
var fontSizeInPixels = (16*1680)/document.documentElement.clientHeight;
//nominal font size of 12pt (16px) with a 1650px wide browser window
body.style.font-size = fontSizeInPixels+"px";
Edit:
Microsoft had a good article on handling dpi changes:
Making the Web Bigger: DPI Scaling and Internet Explorer 8
Maybe this answer that I just wrote in other question about the same problem can help you