Responsive HTML Design

Hello Dpers,

I am about to start designing my site and I want to make it responsive. Well, I already have design the site in Photoshop for 1200px. My question is, will I need to make several designs with different width in photoshop or this will be done using HTMl/CSS by the coder?

I would also like to have an idea of the width sizes(in pixels) that I will need to make a responsive design. I know I need to make 1024, 768, 480. What are the other sizes?

Thanks.

 

960 width size is standard size for 1024 and upper screen sizes and this size is mostly used in many websites.

 

That's a good thing...

... and there's the bad thing. Drawing goofy pictures of a website before you have semantic markup and a responsive layout -- well, it's tying your hands behind your back. With all the new features of CSS3, taking that route to 'design' is pretty much the road to failure -- you are setting yourself up for "but I can do it in photoshop" idiocy that can and most likely will piss all over your site in terms of accessibility, maintainability and functionality.

You need to figure out what's going on the page for actual CONTENT (or at least a reasonable facsmile), markup that content semantically with ZERO concern for how it's going to look with your layout and every effort made to have logical document structure... then and only then do you build your layouts by bending that markup to your will with CSS. Only after you have all your working layouts do you bring in the photoshop junkie to draw their goofy broken graphics over it... assuming you need them at all given what you can do with CSS3 these days.

Drawing some goofy picture of a website is most always the road to /FAIL/ -- because no matter how pretty it is by the time you try to turn it into an actual working page, it is inaccessible, bandwidth hogging, with little to no graceful degradation -- and that was true LONG before they started throwing around the phrase "responsive layout".

For those of us who've told the PSD jockeys where to shove their idiocy the past decade, and never were DUMB ENOUGH to declare content area fonts in PX, avoid fixed height elements in flow, do not crap out a fixed width design, embraced separation of presentation from content and STRICT markup, and in general followed guidelines like the WCAG and bothered understanding why HTML and CSS should be separate and bothered using the MEDIA attribute -- "responsive layout" is just the next logical step.

While for the people who've been sleazing out HTML 3.2 and slapping a tranny doctype on it (and now slap HTML 5's lip service on it while still having their heads wedged up 1997's backside) for over a decade, working from goofy psd files designed with zero understanding of accessibility or flexibility with px metric fonts and crappy fixed widths... "responsive layout" might as well be an alien language.

 

Just for your information ..

Many users are now switching to LCD & LED panels. The maximum resolution currently in use with LEDs is 1080 x 1920 pixels. We know this as High Definition.

Here are two links to get an idea about usage statistics of screen resolutions.

http://www.w3counter.com/globalstats.php

http://www.w3schools.com/browsers/browsers_display.asp

If you design your site with fluid layouts you can minimize the CSS style sheets for various resolutions. One fluid layout can handle them all. Here is a good link on how fluid layout works.

http://coding.smashingmagazine.com/2009/06/09/smart-fixes-for-fluid-layouts/

Good Luck!

 

I suggest you use a responsive framework.
Search "responsive framework on google", or search the term bones framework and skeleton framework and start from there.

 

Ouch...

ARGH... NOTHING pisses me off more than lightbox when you can't even get the image at a decent size... Not wild about the very notion of it in the first place, but when people do **** like that it does NOTHING but piss me off. Part of why my own implementation (boxSir) goes out of it's way to make sure it provides zoom and panning controls, in addition to the forced resize.

I swear, the only thing lightbox has done for me is train me to always middle-click on links.

Though if you're serving text inside it? For **** sake just make another page on the site. There is NOTHING more annoying than when a designer makes a crappy little box with it's own scrollbar on a page... well, apart from auto-playing music, animated gif's as tiled backgrounds, fixed width layouts, and entire contents of a page in px metric fonts.

 

Laughing at the LED-tards... listing vertical before horizontal (NOBODY who knows *** about computers does that, well, unless you're running them in portrait), at such a piddly low resolution -- and saying LED when that's just the backlight. (It's still an LCD panel dumbasses)...

Much less that I've been running 1920x1200 for over six years, and just a few months ago upped to a 27" 2560x1440 IPS... which now that you can get them at 'normal' quality for around $300 (yamakasi) and guaranteed dead pixel free for $30 more (Potalion)... expect to see more people rocking the IPS than just the folks with more $$$ than brains buying stuff with apple logo's on them.

But what does one expect from ignorant ten word wonder-posters just trying to get their post counts up so they can spam links... 1080p maximum resolution my ass...

 

Death, what do you suggest me. I just started learning HTML5/CSS3. I don't know older html or css. I just started.

 

First, forget HTML 5 until you have a firm grasp of HTML 4 Strict... which if you do you'll come to the same conclusion I did about 5 -- what's the point. They had to throw all the cool stuff that has NOTHING to do with writing markup -- like the new JavaScript features, canvas and CSS3 -- under HTML 5's banner because without them, the Emperor is running around in Leia's slave girl outfit. (I paint pretty pictures with words).

HTML is simple, and people keep trying to make it difficult. (Kind of like C syntax languages in a way... programming is simple... C syntax isn't). The HTML side is NOT rocket science... It's even SIMPLER in XHTML 1.0 since you have clearer more well defined structural rules.

Gonna give you some advice here: HTML basics in 5 minutes -- much of this is stuff that even experienced developers seem to keep forgetting, never bothered learning, or are too busy being sleazeball predators on ignorant clients to even bother trying.

You have two types of tags in terms of closing... normal and self closing. The HTML specification refers to the latter as "empty elements" -- which confuses the hell out of people. When they say an empty element, they mean one that CANNOT contain other tags or text, NOT one that does not contain tags or text.

Normal tag:
<li>Line Item</li>

Self Closing/empty tag
<hr>

Self Closing/empty tag XHTML 1.0
<hr />

That's IT.

Inline Level vs. Block Level -- The two main structural types of tags. Block level tags can GENERALLY hold any other type of tags or data. Inline level tags can only hold plaintext or other inline-level tags.

Example block level tags:
DIV, DL, UL, OL, H1 through H6, BLOCKQUOTE

Example inline level tags:
A, B, EM, STRONG, I, SPAN

Do NOT confuse block/inline-level with display:block or display:inline -- while by default those are their behaviors, they are NOT the same meaning. Simply making a span display:block does NOT mean it can suddenly hold a block level element.

(There's a lot of places in the spec where they use the same words for two different meanings, or vague/obscure meanings/words for christmas only knows what -- I think they did it just to confuse nubes. It's like it was written by a public accountant and a patent lawyer)

Reference -- You should have a decent tag reference and take the time to read what all of them do and are for... The one I like is really old (over a decade now), but it's as close to the intent of the spec as you'll find in actually comprehensible English instead of weirdo legalese.

http://htmlhelp.com/reference/html40/
Be sure to click on "hide non-strict elements" so it does NOT show you the tags you have zero business using after 1998. (like FONT, CENTER, IFRAME, etc, etc)

Go through the organizational list, pay attention to the "Contents" and "contained in" sections under each tag's page -- if you forget, go to the reference... keep it open in a tab in the background while working so you can flip to it quickly. Take the time to study what tags are available and what they are for... and if it says "deprecated", DON'T USE IT! There's only around 80 tags total you have ANY business using on a modern website, and to be frank you'll probably never use about half of those. (when's the last time anyone here used TT, SAMP or KBD? Hell, we're lucky there are people out there who even know what TH is or what a LABEL is for...)

You'll find that for example, BODY and HEAD can only go inside HTML, LINK and META can only go inside HEAD, P, H1, etc, etc, can only go inside BODY or block level tags inside BODY.... so on and so forth. It's all there, and I find it easier to just look at the reference than try to remember every last little rule. When in doubt, look it up -- I've been coding for almost 35 years now, and writing HTML for more than a decade, it is IMPOSSIBLE to remember everything unless you're some sort of savant, but if you can at least remember "hey, isn't there a tag for variables in code/mathematical expressions", you can go look up the details on it.

Semantics -- If you are chosing your HTML tags based on their default appearance, you are choosing them for all the wrong reasons. Modern practice is called "separation of presentation from content" which means your HTML is for saying what things ARE, NOT what they look like. This mantra should even be extended to your ID's and classes as much as possible... this way you can use one set of HTML for many different appearances and layouts. This means paragraphs go around flow text -- NOT images (unless the image is inline with the text like a smilie), not headings, not form elements, flow text! The grammatical paragraph that existed for centuries before the invention of moveable type. If you have short lists, put them in list tags -- if the list is big enough that they end up with headings, it's probably better NOT to put them in a list as that's redundant... to the headings.

A word on headings and horizontal rules:
Heading tags exist to indicate the start of a new section/subsection of the page. You'll often hear people say you should only have one H1 per page, this is because that's the heading under which all content of the page are subsections! A h2 indicates the start of a subsection of the h1, H3 indicates the start of a subsection of the H2, and so on and so forth. They should fan out like a tree... H1 is the trunk, h2 the branches off the trunk, h3 the twigs off those branches, etc, etc... until you get to H6 which are the nuts. As a rule of thumb if you need to go deeper than a H4, you either skipped a heading level or there's something wrong with your structure.

Most people think of the horizontal rule for it's default presentation, but it's long been held since we switched to semantic markup that it indicates a break in the content, indicating the text that follows is NOT a subsection of the header preceeding it. It's best used for that semantic reason, treating it like it was a empty H2 where an actual heading is undesired or inappropriate. You don't like how it looks, you can always hide it with display:none; in the CSS for your screen layout -- that way you have good CSS off semantic markup, and your desired appearance!

Which, if you use headings and horizontal rules as I outlined above, HTML 5's "section" tag is pointless bloat, HTML 5's NAV tag is redundant to heading navigation, and FOOTER is redundant to just putting a HR in before it!

DIV and SPAN -- these tags are considered "semantically neutral" -- which is to say they do NOT change the meaning or imply any form of meaning to whatever they are wrapping. That's WHY we use them. The markup inside them should convey all the meaning you need if you follow the simple rules of paragraphs for paragraphs, and headings/hr to indicate section starts (and ends), etc... They exists for the sole purpose of being hooks to apply style to - WITHOUT saying what that style is. They should be added with an eye-dropper only when you absolutely NEED them -- do not simply start slapping DIV around everything just to apply style... you see that idiocy all the time with things like menus... Menus are a list of choices, we have tags for lists, with the parent tag (typically a UL) being a perfectly good block-level container all by itself. There is little you can do to a DIV you can't do to a UL, so why put a DIV or any of the idiotic HTML 5 'structural' tags around it? Let the poor thing do the job it was intended to, and save yourself some code!

IMG should only be used for CONTENT images -- which is to say things like gallery thumbnails, article pictures, etc, etc... any other images like borders, presentational versions of text, etc... have no business in your markup -- that's CSS' job.

STYLE as a tag, should NEVER BE USED ON A SITE -- I know this disagrees with what Google's been telling people lately, but honestly they've gone more than half a bubble of plumb the past couple years on this stuff. Putting all your CSS in external files lets them be cached across page-loads, subpages and revisits, you can even leverage it to pre-cache the appearance of subpages. Where they get the idea that inlining static CSS (or scripting for that matter) in the markup is a good idea is beyond me... I had my way, the STYLE tag would be deprecated.

STYLE as an attribute should ALSO be used with an eyedropper -- STYLE is presentation, 99% of the time that means STYLE has no {string of expletives omitted} BUSINESS IN YOUR HTML! However, there ARE exceptions to the rule, like when things like size or color are actually conveying data. Width for example can be used to make a bar chart -- the size of the element is part of the data, so then style="width:40%" can be justified in the markup. Tag clouds are another example where font-size can relate the importance of the data... But those are relatively rare exceptions. 99% of the time you see people using STYLE in the markup, it's nothing more than bloat, bad coding, or a failure to realize this is 2012 not 2002.

You follow most of the above, and you'll find that despite not caring about appearance when choosing your tags, the non-css appearance of your page... won't be half bad... and you'll find it MUCH simpler to make your multiple layouts WITHOUT tossing endless/pointless classes on everything... you'll end up using five to ten DIV/SPAN instead of five to ten dozen of them.

... and I'm willing to bet you won't find any of the above advice in any of the books and tutorials out there written by the people who still haven't pulled their heads out of 1997's arse, still vomiting up HTML 3.2 and until recently were slapping 4 tranny on it... and now just slap HTML 5's lip service on it while still pissing out the same half-assed idiotic 1990's style code... and yes, I'm including those brand spanky new HTML 5 books/tutorials in that statement!

HTML 5 sure as shine-ola wasn't crafted for anyone who embraced STRICT markup, separation of presentation from content, or any of the dozen other improvements in coding practices and site development methodologies of the past decade... Hence why I actively campaign against the use of HTML 5. The only parts that are actually USEFUL in it, have nothing to do with writing markup, or re-introduce all the redundancies that were supposed to be the POINT of HTML 4 Strict!

One more bit of advice: developing clean, consistent and clear code formatting habits can do more for making it easier for you and others to deal with anything your write than anything else. It is one of the most neglected yet most essential skills you can develop. Some time ago I wrote a post here (wow, that was four years ago?) that touched on the subject.
http://forums.digitalpoint.com/showthread.php?t=1036280

Admittedly the information's a bit out of date, and talks about more advanced topics like PHP, but the general rules/ideas outlined there are still important. Clear code not using stupid cryptic abbreviations on classes, ID's or filenames can make the code so clear you don't even NEED comments, consistent indenting/de-indenting practices just makes it clearer what goes where... and yet you'll still have the endless horde of sleazeballs who will argue they can't be bothered, or that it's unimportant, or "I just do it my way".

Though I think that plays more to apathy, ignorance and just plain wishful thinking. There seems to be this noodle-doodle idea you'll see some idiots out there spouting where they say strict clear rules make it harder to do things... Because being told how to do it thanks to clear easy to follow rules makes it difficult? Gehugafugah? On what planet? That's the type of thing that just needs to be filed away alongside all the other lame excuses for not being a web professional. (love that article)

Sorry for the ranting, but hoping this will clarify some things and get you pointed the right direction.

 

For the responsive HTML website for web browsers and smartphone users will help below URL.

http://stackoverflow.com/questions/10061572/responsive-layout-tutorial