Cleaned up the code and made it table/table-cell route instead. http://codepen.io/ryanreese09/pen/vOLajW
The 550px width was just an example. You can use any width for that.
Hi Ryan - thank you! Does the “@media screen and (max-width:550px)” mean that boxrgt will drop below boxlft in any device where browser width is less than 550px - so iphone at 320px will drop the box to next row?
Please can you tell me the reason why table is better than two floating boxes?
Val, should the image remain the same height at different widths or can it scale? It would be best if you could post some kind of a graphic showing what you want and describe how you want it to behave.
For example: Take a look that the header (company name) on this site-in-progress. Drag the edge of your browser from page width to narrow (320px or so) and notice how the header image/s change. What is needed for your site depends on your requirements.
Hi Ron, I hadn’t thought of scaling. It’s when I advertize a program on my site - then the vendor provides banner images in a variety of sizes. So I thought to display the 728px banner as the default and display a 300px banner in mobile using @media. If all images can scale automatically then that would be the ideal. It’s fine to increase the height so long as the info can still be read in the banner, as per your example - thanks for giving that!
Is there a reason Ryan suggested a table rather than 2 floating boxes – for 2 boxes side-by-side?
Ryan didn’t exactly recommend a table… he recommended assigning CSS table behaviors to divs.
He did so because it is a reliable, easy, very flexible, cross-browser compatible, hack-free, clearfix-free technique.
Most images can scale automatically. Whether or not they should, is another matter. In other words, how legible is the image when it is scaled smaller? Do you want the image to be scaled larger than its native size (if so, it becomes fuzzy)? If the range over which the image is scaled is not too great, then scaling will probably be a satisfactory technique. Otherwise, swapping images and scaling might be better. Depends on your requirements.
It’s very easy to scale a foreground image:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>scale foreground image</title>
<!--
http://www.sitepoint.com/community/t/responsive-floating-boxes/189399/8
-->
<style type="text/css">
*, *:before, *:after {
-webkit-box-sizing:border-box;
-moz-box-sizing:border-box;
box-sizing:border-box;
}
img {
display:block;
border:2px solid magenta; /* TEST Border */
max-width:100%; /* scales from actual image width smaller */
/* width:100%; /* scales larger and smaller than actual image width */
height:auto; /* aspect ratio is respected */
margin:0 auto;
}
</style>
</head>
<body>
<div>
<img src="http://placehold.it/960x200">
</div>
</body>
</html>
which is a real drag, it’s so long-winded for bandwidth. But I’m busy changing my entire site to wordpress so it’s mobile responsive, can do trackbacks to other wordpress sites (my entire industry is on wordpress), etc.
No, I don’t mean that at all. Foreground images should be configured with the alt, width, and height, attributes, although there are now occasions when the alt attribute is considered optional. The trailing slash in empty tags is an XHTML requirement, not an HTML requirement, so it is not needed on an HTML page. It has nothing to do with Wordpress. Just DOCTYPE.
There is no ideal or usual breakpoint, period.
No, that would not work. Logically, you would be telling all of the breakpoints to do the same thing at the same. That’s not how page layouts flow nor how the code might be written. Each breakpoint is independently chosen and coded to solve your immediate needs at certain widths. @media screen and (max-width:768px) {selectors targeted and styles needed} @media screen and (max-width:1024px) {selectors targeted and styles needed} @media screen and (max-width:1200px) {selectors targeted and styles needed}
(I’m not advocating these numbers; just showing how the media queries might be written.)
IMO, one should not plan to use a predefined breakpoint or group of breakpoints. The page should be fluid first with breakpoints added where needed to support the flow of the page on smaller (or larger) devices. In other words, choose breakpoints that serve your design instead of designing around predefined breakpoints. FWIW, I typically use 2 breakpoints, and sometimes 3. They breakpoints are not decided (they are not known) before a page is designed.
