I've got a image... and if the image's height is greater than maxHeight, or the width is greater than maxWidth, I'd like to proportionally resize the image so that it fits in maxWidth X maxHeight.
While this can be done, what happens when the user's screen is much bigger than the native size of the image? Do you stretch it to the point of it degrading into pixels?
What happens with people with smaller screens - do they have to waste time and bandwidth downloading an image that is much larger than they're capable if displaying, then depending on the browser to scale the image down?
In many browsers, especially older ones, scaling images degrades them, whether making them bigger or smaller. It's best to scale them on the server, based on a large image and deliver the "right" sized image to the client. This is much more complicated.
While all of this is possible, one must ask whether this really adds much value to the user experience in the first place and whether all this effort is worth it.
You can set the attributes of the image tag using JavaScript.
The properties you may like to set are height, width.
Related
I was having a hard time figuring out how to phrase this. Sorry if this is a noob question, I'm new to responsive design and mobile web design in general.
My phone (Galaxy s10e) will render my webpage as if it's 360 pixels wide, with all elements positioned appropriately based on this width. I have several image tags on the site that are the same width. I was using src images that are 360px wide, and this looks fine on desktop because it is actually rendering my images at 360px, but on mobile the images alone appear to be rendering at a much higher resolution, causing it to look terrible due to upscaling.
If someone could explain to me what is happening here it would really help, since I can't find information on this specific behavior. Some questions I have:
Is the browser choosing to position the elements based on a 360px width while rendering the actual content at the screen's resolution?
How do I account for this in my design? I considered rendering the images at the higher resolution and then having the page dynamically scale those images down (so even though the actual div is 360px, the browser can use the 'extra space' allotted by max-width to render the image at a higher resolution), but I want the images to remain 360px wide on desktop, not the higher max-width for mobile rendering.
Where can I learn all about this behavior so I know how to tackle responsive image scaling in the future?
Thank you for your time. Let me know if you have any other questions. I'm using ReactJS to develop the site.
OK so in a nutshell pixels are relative sizes. One pixel is not literally one pixel on your phone.
What happens is PPI kicks in and basically zooms in to make things readable.
Because if you actually tried to view 360px on a phone with that pixel density you'd see nothing really.
So lets look at some phone specs:
6.1 INCH
5.90 x 2.77 x 0.31 INCH
Resolution 1440 x 3040 PX ~ 550 PIXELS PER INCH
Viewport 360 x 760 PX 138 PIXELS PER INCH
Now the viewport is what you actually see on screen. in this case it give you a pixel ratio of like 4. So that means your phone has a resolution 4 times that of it's viewport.
so for a web app where a div is set to 200px wide it will display 200px as you'd expect it based on the viewport but this div is actually 800px wide relative to your phones resolution.
Now pictures don't need this limitation. Whats the point in a high res display if your pictures only display 200px with a pixel density one fourth of your screens capability.
So a picture lives in a dual reality on your phone. It has a box size which is the size of the image relative to your viewport but the image itself inside the box lives within your resolution relative to your devices total screen pixels.
So when you have and image that's 200px in the viewport its display resolution is actually 800px. So when you put a picture that's only 200px and have it on a screen that does viewport scaling which nowadays is pretty much everything you're effectively stretching that image to four times its actual size. or what ever the screen pixel density ratio to viewport is. AKA it looks like crap.
And to answer your needs on this I'm just going to direct you here to MOZ who will go over the whys and how's as well as show you what to do to combat this.
Moz on Viewports
Combating element position is pretty easy you just use :
<meta name="viewport" content="width=device-width, initial-scale=1" />
In your <head>,
Moz on Image Scaling
I would like to gather some statistics about what the range of default font sizes are, that users set in their browsers if they do not wish to use the standard 16px.
This information might be helpful in deciding up to which font size our layout needs to not break.
There are a lot of similar-ish questions on SO that ask for the effective font-size on the body element, but that is of not much use to me, as I'm interested in collecting data about the browsers default font size before CSS kicks in.
Or does anybody know if statistics like these already exist?
The best practice is to set the font sizes in ems which scale accordingly to the browser font size, but you can read this article : Users DO Change Font Size
This is actually one that isn't as simple as you may think as their is no JavaScript hook etc. you can call.
The way to get a reasonably accurate value is:-
create a <div> that has opacity:0 and set padding to 0.
Add a word that is in a specific font that you know the exact dimensions of, a word that can fit on one line on a small screen even at 200% font size.
Add the word to that div.
Set the font size of that div to be 1em or 100% (so that it scales with user font size)
Measure the width of that div in pixels with your browser set to normal font size.
Then when the user loads the page measure the width of the div and compare it to the size you know is 16px / default.
You can then use the width of the div (via JavaScript) to estimate the font size they are using. (so if it is normally 160px wide and the user has 200px wide you can estimate that they are using 20px font size or 125% (200 / 160).)
The above is reasonably accurate, it isn't perfect due to different browsers handling kerning slightly differently but would be sufficient for most needs.
I'm attempting to make a page that will be compatible both with a PC browser and a browser on a phone.
Essentially, I want to size my elements as large as I can on the smaller screens (ideally, even a little bit larger), while confining everything to a narrow vertical band in the center on a PC browser window.
You can see the look I'm trying for here:
http://www.hoggy.com
I've attempted to read the browser's width to tweak the data on the fly, but I find I cannot get a reliable width on all platforms.
So I've attempted to center things, and make the image and table sizes be a percentage of the page size... but on a phone it's too small (thus I would like it to be actually a little wider than the phone screen) whereas on the PC, I want my width to be, effectively, min(100%,500px).
Is there any way to do that?
Simplest answer:
html
{
max-width: 1024px
}
These days there's a big difference between pixels and points (CSS pixels, DIPS). On my particular computer its the same, but on retina macs and a lot of phones, there's 4 or 8 pixels per point. http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html
That is, the “pixels” that are used in CSS declarations such as width: 300px or font-size: 14px,have nothing to do with the actual pixel density of the device, or even with the rumoured upcoming intermediate layer. They’re essentially an abstract construct created specifically for us web developers.
I want to get the screen resolution (the real screen resolution, you get it by now), and then serve an image scaled to maximally fill the screen. This means no need to get 2000x2000 pixels images on mobile devices, while still getting good resolutions on a large mac.
Hover, when using screen.height it returns CSS pixels not the screen resolution, meaning a retina mac will get an image that is half the size of the screen, resulting in pixelation. Any way to get the actual screen resolution, or the pixels-to-points ratio in javascript?
This will give you the actual screen height, regardless of pixel density which is altered by including the viewport tag...
screen.height * window.devicePixelRatio
Macs with retina renders pages in 2x scale, and so screen.height returns actual height divided by 2. See answers here
I have 2 images on top of each other.
When the top one moves to a different spot, both of them become kind of distorted/blurry. After a second, the images return to normal.
How do I stop this from happening?
http://jsfiddle.net/jenga/W59c4/
The image has an actual size of 140 x 198. You are shrinking and expanding it to a different size. Because of the way raster images work, this causes blurriness and/or distortion. Use a bigger source image, higher DPI, or don't expand it beyond the base size of your source image.
Otherwise, the perceived "smoothness" of any javascript animation is very dependent on the client computer's resources. If your browser thread is running high on memory (Firefox+Firebug can balloon up to 1gb of resident RAM consumption after a few hours of work!), or if your system doesn't have a lot of available resource to start with, animations can be jerky and screen rendering can be slow or glitchy.
Other than the distortion caused by the scaling, your animation runs smoothly on my own computer (I have a lot of resources to work with :P)
Documentation
Raster Graphics on Wikipedia - http://en.wikipedia.org/wiki/Raster_graphics
Resize the black card down to the desired dimensions. You're working with an original that's 600px wide and shrinking it to 75px wide; that's the cause of the distortion.
My guess would be that the browser doesn't anti-alias the black card because it's not in view. During the animation the browser is rapidly updating position and scale of the blue card. As a performance measure, anti-aliasing might be put off until there's room for the browser to breath beyond what the tight setTimeout looping provides.