Making an old site responsive

Continuing the discussion from Responsive design has totally ruined desktop web experience (rant) - #100

Obviously, I want the site to look good no matter what it’s viewed on. But I do want to keep the present design for desktop PC’s or any larger screen device that can show it as it was designed.

Question: Is that possible? Can an existing site be made “responsive,” or is a total redesign required?

In exploring W3.CSS, I was getting the impression that it is possible. How much work is involved is another question, but I’m up to the task, and I have a good solid understanding of CSS (been working with it for a long time), so let’s go.

2 Likes

Me too! Personally, I don’t understand (other than for texting and email) how anyone can stand using those small screen devices for Web “surfing” or doing any serious searching for products or services.

Same here. That’s what I like about being able to build my own templates using PHP. And designing with CSS.

But, here is a site that I really need to consider to be made “responsive.” (as well as the other site for Clyde Construction) This is one I built several years ago for a local pizzeria owner. Her marketing guy (I’ve never met him) told her she had a great Website (patting myself on the back), but said something to her about “mobile” (and I’m assuming he meant what you all are talking about; ‘responsive.’

This site is a database driven site, because it’s basically her menu online: http://auntievspizzeria.com

I have a question right off the bat: Are we locked into using only the w3 colors (blue, teal, green, red, etc.)? What about my background gradients etc? What happens with them?

Maybe I’m getting too far ahead at this point.

I’ve moved these posts into a new topic of their own, in a more relevant category. No doubt @SamA74 and @ronpat will be along later. Meanwhile:

[quote=“WOtis, post:3, topic:205596”]
Are we locked into using only the w3 colors (blue, teal, green, red, etc.)?
[/quote]No. It’s not been necessary to restrict yorself to “web safe” colours for a long while now.

[quote=“WOtis, post:3, topic:205596”]
What about my background gradients etc? What happens with them?
[/quote]I expect you can keep them. You might choose to load something simpler (a solid background colour) for small screens, but it depends partly on your design. (However, some older devices may not support CSS3.)

Ah, XHTML Transitional.

I don’t know if you’re like me and actually like XHTML mark-up.

One of the things about HTML5 that initially unsettled me a bit is that it allows what I feel is “sloppy” mark-up. (just about any mark-up it seems)
So the good news is that it also allows “strict” mark-up.

For example (this is my current template that I use for local testing on my machine) The meta viewport line is an essential “keystone” to RWD

<!DOCTYPE HTML>
<html lang="en">
<head>
<title>Template</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<style type="text/css">
</style>
<script type="text/javascript">
// script needed before the DOM is loaded here
</script>
</head>
<body>
<h1>Template</h1>
<script type="text/javascript">
// script that needs the DOM to be loaded here
</script>
</body>
</html>
1 Like

@Mittineague

I am pleased to say your template passed these tests:

W3C CSS3 Validation Service

W3C Markup Validation Service

Google Mobile Friendly Test

Anymore developer tests available?

2 Likes

It is possible, although it depends on the site. I have been making a number of my sites responsive over the past few months. Some have proved easier to do than others.

Yes.

That’s exactly what I have been trying to tell you, RWD done properly will not compromise your full size desktop design.

I find it easier to create a responsive site from scratch, but it’s quite possible to convert a site, which will be quicker if it is of any significant size.
In many cases it’s just altering the css, though there may be instances where you will want to alter the html structure a little, depending on how it was done.
I think the best approach it to take it one element at a time, working through each until all issues are gone.

That’s an advantage, you just need to alter the rules you apply to make the site fluid, not rigid.
Like I mentioned before, instead of width: 960px; say max-width: 960px; on a screen bigger than that it will appear no different, but on one smaller it will be 100%, not 130% or 180% width. Eg:-

body {
   background: #fff;
   margin: 0 auto;
   max-width: 960px;
   width: 95%;
}

Your main wrapper may look something like like that, the % width make the smaller screens have a little bit of the background showing at the edges, if you want that, that is.
Then test it in the browser by dragging the left edge in and out to make the window narrower. The aim is to never see a horizontal scroller, and keep the site looking good and readable at any size, down to a sensible minimum.

This could be what they mean.
When you have that page with green bits instead of red bits, you have cracked it.
The fisrt thing you need it the viewport meta tag:

<meta name=viewport content="width=device-width, initial-scale=1" />

Then change the css to less rigid, more fluid rules. For example the header mentioned before, which had no content, just a background, could be something like:

header  {
                background: #666 url(header-image.jpg) center no-repeat;
                background-size: 100%;
                padding-bottom: 30%;
}

The padding-bottom is replacing the height setting, it uses are more fluid % value rather than fixed pixels allowing it to scale down on smaller screens. The % value would be adjusted to create the correct aspect ratio for the image. I left out any width setting as it will naturally fill its parent container which has a max-width set.
And thirdly, the chances are at some point the design/layout just won’t work at some size, then it’s time add a media query, Eg:

@media screen and (max-width: 600px) { }

This is a game changer, everything inside the brackets applies only to screens less than 600px (or whatever value you set), so you can change the rules for smaller screens, adding new rules or overriding ones already set.

1 Like

I have started dabbling with the home page to the pizza site. I’m slow, so give me a day or two to see what I can come up with.

<aside>
I would like to ask @PaulOB if there are any advantages or disadvantages to limiting the width of the page in the body tag as shown in SamA74’s example? I have always applied the page width styles to a wrapper inside the body, but maybe I’m behind times.

EDIT: Notes found. See #14 below.
</aside>

I’m puzzled by that too. I just tried a Codepen with that CSS applied to it, changing the white background to red - it still filled the full width of the screen with red. Applying it to a container with a white background, gave me a 960px width content area I was expecting.

Me too, but I have latched on to the idea of treating the <html> element like you would the <body>, and the <body> like you would the <div id="maincontainer"> or however you label it.

Try this:-

html {
                background: red;
                
            }
body    {
                background: #fff;
                margin: 0 auto;
                max-width: 900px;
                width: 95%;
 }

Interesting…

I’m not aware of any adverse effect of this, but someone may know better. As far as advantages go, it’s one less <div> tag, a huge saving on page weight. :smile:

I found my notes to a thread and an article in which Paul commented about the background-color, plus the article mentions width applied to body. So, unless there have been new developments, these answer my concerns.

The thread:
http://www.sitepoint.com/forums/showthread.php?1125898-super-simple-background-question-(i-think)&p=5507542&viewfull=1#post5507542

Comments by @PaulOB and @ AutisticCuckoo follow the article
http://www.sitepoint.com/styling-the-html-and-body-elements/

There is a good bit of discussion in the thread.

In summary, applying background-color or width to the <body> and background-color to the <html> elements work but there are caveats (and I tend to avoid stuff with "gotcha’s that I might forget about)

1 Like

I answered my own question about background colors after I had posted that and gone about my other business (I have roof repairs to do … fun, huh? :slight_smile: ) But I thought about it and realized it was a silly question, because it’s an image, for one thing, that repeats across the screen. Duh!

Thanks, I’ll read it all later. I only checked in for a minute to see what was happening. Tomorrow, I’m up on my roof again while the good weather holds.

Thanks, everyone, for all your help, and willingness to assist. Looking forward to this discussion.

“Page weight?” Now there’s a term I’m not familiar with.

WOtis, may I ask what browser you have on your desktop? What browser do you use when you create your sites? And what range of browsers do you support (usually measured in older versions of I.E.)?

I had a brief look at the http://auntievspizzeria.com5 CSS file and used this Free Online Word Count Tool to analyse the CSS file

As you can see there are numerous duplicated properties. These duplicates could be replaced by a single class. This will considerably reduce CSS filesize and simplify global web-pages changes:

As an example I chose to add a single class and delete all duplicated CSS properties:

CSS filesize saving:

Method 1 - remove about a dozen duplicates and add common class

/* REMOVED:   font-family: verdana, arial, sans-serif; */

/* ADDED common class */
.ffv {font-family: verdana, arial, sans-serif;}	

Results:
CSS filesize before:   3,919 bytes
CSS filesize after:      3,667 bytes
CSS filesize saved:       252 bytes (6.5% approximately)



Method 2 - Combine elements

h3,
.date,
.ulmain,  
#infobar,
#coupon1,
#coupon2,
p.footer,
p.leftColumn,
#copyright,
#bulletlist ul, 
#maincontent,
#headercontent {font-family: verdana, arial, sans-serif;}

Conclusion:

There will be a considerable CSS filesize improvement but a necessary downside is to add the common class to the relevant HTML attributes.

I consider it is well worth the CSS filesize saving especially when many mobile pages are used.

just my two Satang :slight_smile:

Hi Ron,

I think you found the answer to the question and historically it was bad practice but as long as you know the gotchas then it can be useful to avoid a page wrapper these days.

Of course if you want a background to the centred element then you need to apply a background colour to the html element to stop the background you set on the body propagating to html. By the time you’ve done that you’ve already wasted the benefit of just having a page wrapper anyway :smile:

Also html4 and xhtml strict doctypes doesn’t allow inline elements to be direct children of the body anyway so you would need a block wrapper around every image and inline element if you used the body centring approach (html5 is ok with it though).

The zoom issue seems to be fixed in IE11 but I don’t have a real IE9/10 to test older versions.