I plan to design a web app with Phonegap. As I need to deal with different screen sizes, I will have to work with responsive design and CSS3 media queries.
I have a 1080x720 resolution android phone, and I want to start with this (large) resolution, and say the css is base.css. And for smaller screens, I will add something like small.css to overwrite base.css (places where needed).
Assume the css would be complicated, will it incur more workload for small screen phones (whose capability tends to be weaker than large ones)? Is it better to start with small.css as base.css, and overwrite it with big.css on large phones? Or it doesn't matter in web app scenario (as css file size is not a big issue)?
Any design considerations and hints?
I can only agree with #Lisbeth. Start with the bigger design and keep it all in one CSS file. If your jumping between designing wider screens and smaller, you'll easily get confused and the end result will suffer. Make a complete design for big screens and then move on to next size down. This is a mockup that I'm using for most my projects. Just add it to the bottom of your CSS file. A good article that descibes the details
// Code for "regular" computer screens
/*------------------------------------*\
$SMALL COMPUTER SCREENS
\*------------------------------------*/
#media all and (max-width: 1034px) {
}
/*------------------------------------*\
$IPAD AND TABLET
\*------------------------------------*/
#media only screen and (max-width: 767px) {
}
/*------------------------------------*\
$IPHONE 4S LANDSCAPE
\*------------------------------------*/
#media only screen and (max-width : 480px) {
}
/*------------------------------------*\
$IHPONE 4S
\*------------------------------------*/
#media only screen and (max-width : 320px) {
}
I usually start with a 1000px width and complete the design first.
Then I use media queries for 800px,600px and <400px.
While designing the page decide which elements are to be shrink and which elements to be float-removed. Then apply the appropriate changes in media queries. Instead of using two css, use one (This saves your number of requests). Make small tweaks to fit your small screen devices.
http://css-tricks.com/ have an excellent responsive design. Just note how they are changing the elements.
Or a simple answer, start from bigger width to a lower one !
Related
I've been working on a new responsive website design and I have a gallery containing a grid of images which when the browser viewport is 768px or above spans 4 columns wide (so each image is about 25% of the viewport). Anything 767px or lower is only 1 column wide (making it full width at lesser resolutions).
The images at desktop size (over 768px) should be 220px wide (4 image columns).
Between 480px and 767px should be upto 420px wide (1 image column).
And mobile size (under 479px) should be upto 260px wide (1 image column).
I have three sources for each image. 220px, 260px and 420px.
As you can see from the above, the sizes don't follow the normal conventions of the smaller the viewport the smaller the image, so I've been researching and trying various options.
Following suggestions, I've been using Google Chrome in incognito mode and also inprivate browsing for internet explorer, with the browser viewports started small before loading the page, etc... to ensure any changes I've been making get updated.
The current code I've come to is the closest I've got to making it work and it is following an answer to someone's query (similar to mine) here on stack overflow. However, when trying to implement it I can't seem to get the browser to load the right images still, it always loads the larger 420px wide image.
my code is currently like so:
<img sizes="(min-width: 767px) 420px, 100vm"
srcset="images/thumbs/image_420.jpg 420w,
images/thumbs/image_260.jpg 260w,
images/thumbs/image_220.jpg 220w"
src="images/thumbs/image_220.jpg"
alt="example image"
/>
A second query whilst I'm on the subject. Would it be best to set the default img src in my scenario to the 260px image? As this would cover both desktop and mobile browsers in the event the srcset isn't understood and only the middle sized viewport (460-767px) would suffer. Or is it always best to set the default image to the smallest size?
Any suggestions would be appreciated, thank you.
-- EDIT --
Just a quick update, I thought I'd logically figured it out yesterday but it didn't work so I'm not sure I still understand the whole concept of the calculations. My latest edit looks like so:
<img sizes="(min-width: 460px) 420px, (min-width: 768px) 220px, 100vm"
srcset="images/thumbs/image_420.jpg 420w,
images/thumbs/image_260.jpg 260w,
images/thumbs/image_220.jpg 220w"
src="images/thumbs/image_260.jpg"
alt="example image"
/>
So in my mind I think that the sizes section I've listed states... if viewport is at least 460px then use the 420px image, else if viewport is at least 768px use the 260px image. Then the last 100vm means otherwise use whichever is best at full viewport width.
I've also amended the default file to be the 260px file as this fits most of the viewport sizes if something hasn't been recognised.
However, the above edit still loads only the 420px image.
Any suggestions would be very appreciated. Even if its just to correct my logic!
sizes is evaluated left-to-right. So the order is important. If the viewport is 1000px, then the first media condition (min-width: 460px) will match, and so that size 420px is chosen, and the rest of the sizes attribute is not evaluated at all.
Also, the unit should be vw, not vm.
So it should be:
<img sizes="(min-width: 768px) 220px, (min-width: 460px) 420px, 100vw"
srcset="images/thumbs/image_420.jpg 420w,
images/thumbs/image_260.jpg 260w,
images/thumbs/image_220.jpg 220w"
src="images/thumbs/image_260.jpg"
alt="example image"
/>
As for your second query, technically you can choose any image you like (even one not listed in srcset), but your reasoning makes sense to me. The only thing I would recommend is to put your chosen src image first in srcset, because older WebKit with partial x-only srcset implementation will pick the first item when it doesn't understand the descriptors.
I have a webpage with different images of different proportions. I want to display in the best format for different devices: desktop, tablet, smartphone, etc.
Is it best to use CSS3 #media (mx-width: ** px ) or jQuery $( window ).resize(function() and $( document ).ready(function() { with a change in the size of the image?
The last step works very well and does not require to set a lot of different media sizes as in the case of CSS3, but if Javascript is disabled it will not work.
Basically, I want the images to be responsive, but not with re-scaling of the screen of the device, which is what I get with the Javascript code, but offering the full width of the container div when the page and images are displayed in a smartphone. I think that the approach would involve PHP code to get the Client data ( $_SERVER['USER_AGENT'] ) because don't want images to be too big to go outside the screen, and when using a smartphone I don't want the images to be too small to be seen, and here I have the problem of screen resolutio: the pixels of the image can be 1200 px, but it is shown very small because of screen pixel density or resolution.
The best approach these days is using a technique called "responsive image sizes" along with good old CSS to handle image scaling on devices with similar screen sizes.
Using 'resize' event to manipulate the DOM with jQuery is a staging way to bad performance and bad user experience.
The core idea is to load smaller images on smaller screens and down-scale them in browser if image is bigger than required, using:
img {
display: block;
/* You should never upscale raster images in browser */
max-width: 100%;
height: auto;
}
Here is a good article, that covers the concept in details: Responsive Images in Practice
I would recommend checking out lazysizes, it implements lazy-loading as a bonus.
This is how you use it in your markup:
<img
data-sizes="auto"
data-src="image2.jpg"
data-srcset="image1.jpg 300w,
image2.jpg 600w,
image3.jpg 900w" class="lazyload" />
I'm setting up images for a responsive web design and am adopting the recently-formalised responsive images syntax. I'm not using all aspects, just the srcset and sizes parts. Roughly-speaking, my markup is as follows:
<img src="/image.jpg" alt="my alt text"
srcset="
/image-sm.jpg 320w,
/image-md.jpg 480w,
/image-lg.jpg 600w,
/image-xl.jpg 742w"
sizes="
(min-width: 992px) 742px,
(min-width: 768px) 582px,
(min-width: 600px) 441px,
(min-width: 480px) 599px,
(min-width: 321px) 479px,
320px"
>
My design is built in a mobile-first way. So my question is this:
Does the order of the media queries make any difference to which image gets picked by the browser?
As you can see I have them going from largest breakpoint to smallest, because the default size is small and all the syntax examples I've seen put the default size at the end. But this is in contrast to my main CSS (compiled via SASS) which also uses min-width media queries, where I (correctly) have the smallest breakpoints coming first.
Should I have the smaller breakpoints first in this markup, also? Or does it make no difference within an image markup context?
Order does matter. In CSS later rules do override prior rules, if they have the same specificity. This might yield to the result, that later CSS is overriding prior ones.
In context of resp image the first size value is taken, which matches the media condition. This might result in the opposite ordering effect.
This means if you use min-width, your sizes list only makes sense, if it goes from higher min condition values to lower values (Your example).
If you want reverse your list (from lower to higher), you need to use max-width conditions instead to express the same CSS values thing.
At the end: Do it how you want, but keeping min-width condition and just reverse the list, won't work.
At the end, with sizes there is not a mobile first or desktop first approach, only a simple universal approach.
I've attempted several different css animations to move a large image up and down on the screen while I have music playing. I haven't found any variation on speed, distance translated, etc that results in a smooth transition.
I'm developing a chromecast application where I have a very large, absolute-positioned DIV that I'm animating on and off of the screen. It has a pretty complicated layout in it with html, css and images, even animated GIFs. However, as long as I make sure there are no reflows while the animation is performing, I've gotten good performance by using transform: translate() CSS to control it's position. Previously, I was modifying the top CSS property, but the performance was pitiful.
For an example to illustrate, here's some HTML:
<body>
<div>
... Main content ...
</div>
<div id="overlay">
... Overlay content here ...
</div>
</body>
And the corresponding CSS:
#overlay {
position: absolute;
top: 25px;
left: 50px;
width: 1180px;
height: 670px;
transition: all 1s;
transform: rotate(-2deg) translateY(750px);
}
#overlay.active {
transform: rotate(-2deg) translateY(0);
}
With this, all I do in my javascript is toggle the active class on and off to cause the overlay to show and hide itself. I can't get the timeline debugger to work with the remote chromecast, so I don't know exactly what the FPS is, but it objectively feels like at least 30fps. It definitely seems smooth. I hope that helps.
If you look at the Events in the Timeline panel of the Chromecast Chrome debugger, what you'll find is that any Paint to a reasonable amount of the screen takes about 100ms. Yes, 1/10 of a second! This makes any kind of animation (CSS, JQuery, etc.) very tricky and often jumpy.
For the movement of elements, I haven't seen any difference in CSS animation performance vs. JQuery animation() performance. I expect because the awful Paint times hide any differences.
One would have thought that Google would have used some of that great video hardware to improve the Chromecast browser paint performance, but this type of Chromecast app does not appear to be one of their uses cases.
Remember that a Chromecast device
has limited resources (both CPU and memory)
has a stripped-down version of chrome
As a result, you won't be able to do many fancy transitions/translations that you are otherwise able to do on a desktop or the performance (how smooth it is) is not going to be what you would like it to be, more so if you are playing a media concurrently.
My site has a fluid design between 800px and 1280px. (I appreciate many display resolutions exceed this now).
In 10 inch tablets the site displays best with a viewport width set at 800px allowing the tablet to scale this to its window size. This way fonts are a decent size and images are not much affected by blurring given the small display.
Desktop browsers ignore the viewport meta tag and display between 800px and 1280px, and a background beyond this.
IE10 on Windows 8 however implements the viewport tag on both desktops and tablets and therefore implements the 800px layout on desktops. This results in unacceptably blurred images and giant text on larger displays.
Using CSS the best I approach I have been able to find is something like this (assuming the Windows Surface has a width of 1366px):
#media screen and (max-width: 1023px) {
#-ms-viewport { width: 800px; }
}
#media screen and (min-width: 1024px) and (max-width: 1366px) {
#-ms-viewport { width: 1024px; }
}
#media screen and (min-width: 1367px) {
#-ms-viewport { width: device-width; }
}
This still means desktops will have zoomed images and text unless the display exceeds 1366px resolution. Using max-device-width in the media query does not seem to offer much given that the Surface has a similar native resolution to many desktops.
Alternatively, I could detect the tablet and set the viewport width with Javascript or detect it with PHP and deliver a different stylesheet.
No doubt there is a better way to do this, preferably with CSS?
Thanks, appreciate any suggestions.