Responsive Web Design Techniques

Well, we have:

100% = 1 em ~= 16px ~= 14pt

Flawed methodology since it doesn’t always apply, and somebody can’t do their math as that’s 12pt aka 6 lpi, NOT 14pt.
http://battletech.hopto.org/html_tutorials/fontCompare/template.html

12pt, not 14… it goes downhill from there.

HTML 5 rubbish, endless IE version sniffing, design elements like the ‘three across equal height’ subsection that reeks of the “but I can do it in photoshop” nonsense (exactly the type of thing I mean when I say “not viable for web deployment”)… throw in the memory hogging webfonts and it’s annoyingly slow to render on desktop; a disaster in the IOS emulator so I don’t even want to think what it would be like on the real hardware. (iOS simulator is NOT timer accurate)

Though yeah, webkit is an idiot about zoom; not too surprising given they’re new to it on the desktop; LAST of the browsers to join us in resizing content like Opera has for a decade, and they handle it about as well as IE does, which is to say not at all. Again, zoom sucks.

I have my own opinion on things, yes @deathshadow60; you might be right on many many things, but this does not mean we should ignore them. HTML5 is the future, just like jQuery is now the present. I agree they are bloating the web up, but that’s what’s happening. We cannot change the trends, all we can do is follow them enhancing what we do. I really like the way you base your arguements but I feel we have to seriously look more into following what’s already there and enhancing it. If you separate yourself so much from what’s normal in web design in the end you’d be left on the outside of what’s going on.

Sorry, never been much of a lemming, much less one to simply roll over and take it… especially when it boils down to forgetting the past and being told to BOHICA.

… and there ARE advancements worth using; media queries is one of them, much of CSS3 is another; but simply hopping on the bandwagon of pointless site-flushers thanks to card stacking of facts, transfer, glittering generalities and manufactured testimonials? At that point might as well put on the white wool sweater and go “baaah”; probably why I fight right back with name calling, plain folks, lesser of two evils and my own glittering generalities. Fighting fire with fire.

The reasonable man adapts himself to the world, the unreasonable one persists in adapting the world to himself. Therein, all progress depends on the unreasonable man. – George Bernard Shaw.

Honestly, if “HTML 5 is the future” I want no part of that future, and will wait for HTML 6 to deprecate all the redundancies, idiocies and mistakes just as HTML 4 did for HTML 3.2 – since that’s really what it boils down to! HTML 5, the new 3.2. If you’ve been coding tranny the past 14 years, you’ll feel right at home.

@deathshadow60

You do have a point, and I agree with you whole-heartidly, but things are evolving on the web and we have to evolve with these changes. If we don’t we will be left behind wondering where we went wrong.

Agreed, but those people have to be in a position of power to make the changes, unless they have some crazy Tony Mantana-like aura on the world. I agree with this statement and I practice this everyday. This is probably why I am here doing what I do, instead of cuped up in a 9 - 5 office job riddled with office politics and idle worship to get me noticed by somebody a little higher up the hierarchy.

Thanks for the link - so their maths is a little out, the layout still works despite 16px baseline assumption. Does even matter if you use the baseline assumption? All fonts are proportionately scaled off the baseline. So if the fonts scale smaller because of smaller baseline it doesn’t matter because the layout functions exactly the same as it would if you didn’t make a base line assumption in the first place. So what that different devices have different em baselines, the 16px assumption helps create the correct proportion to display on desktops that is also scalable. It’s just a more controlled way of using ems. So why does the baseline assumption matter? It still works. Is there any practical reason why I shouldn’t use it? Can you show me a layout the breaks with the 16px assumption?

These are moot points - we’re only talking about responsive layouts here. If you can produce a web page design quickly in photoshop (I use illustrator mostly for web) I see not reason no to use it - I don’t believe it to be a reason for bad coding.

Anyway the em media queries - It’s a bit buggy (has some extra padding to the right side of layout) in portrait on both my iphone and my ios simulator set to iphone - assume this is just clumsy coding more than anything else. Works fine in landscape as well as everything else I’ve tried it on. It doesn’t media query on rotating the the device but you can naturally pinch zoom out with ios devices.

To me you’re still making assumptions you shouldn’t. What huge graphics? Why do you assume things never mentioned once? These ‘evil’ assumptions are not grounds for actual tech talk.

Back to tech talk. Sliding is about actual content. Where you take chunks out of the normal content and make slides out of it. It’s called progressive enhancement. Together with graceful degradation, they seem to be missing from your views on developing.

<hr>

And I have the opposite personal example, where my desktop is better. Additionally, I can’t help but question your so called low speed on home connection versus your high speed on 4GLTE. You’re saying you can’t use your smartphone as a modem or as a mobile spot and get faster internet at home, on your desktop?

<hr>

But they do. No matter how fast is their mobile connection, their much smaller screen and the different types of user interfaces makes for completely different needs. In fact, that’s your job, as a developer, to realize that mobile users have different needs.

<hr>

Agreed on the first part. The second part you need to give more thought. You forget about accessibility. It actually means adding content and features for some groups, while removing the same content and features for some other groups.

Now extend this concept, of accessibility, and think of mobile users like a group that has special needs. Because that’s how it works.

I’m sorry, but I do. :slight_smile: Unless you mean the full modified site, which no one ever argued against. Removing content was never about removing essential, core content.

<hr>

Completely and totally theoretical views are known to quickly fail in real world. You can’t deny design from a web page. That is bubkis.

Not sure what you mean. Could you be more specific? Thanks.

But if you mean you can’t actually find a definition for <hr> in HTML5, there it is: http://developers.whatwg.org/grouping-content.html#the-hr-element.

The hr element represents a paragraph-level thematic break, e.g. a scene change in a story, or a transition to another topic within a section of a reference book.

This is what I’m trying to do: to mark a change, a transition. For those that understand HTML, that is. :wink:

Also, beats the hell out of the “-------------------------” or “====================” in one’s posts, don’t you think?

Yeah, I know what you mean. This is my first instinct too. But it’s not the only way to get things done, nor the only way that gives good results.

Starting in the middle gives you lots of problems you need to overcome: some unsupported CSS in IE8- and other older browsers, quirks about implementations in them browsers, when it comes to more advance CSS. And the middle has a way of moving around, while the base is more stable.

Who says mobile first doesn’t resolves these issues better? Certainly not just one oversimplified template, with not much CSS to show for, and certainly not just one single opinion, based on a personal narrow view on developing. You just can’t ask all to surrender their CSS to a bottom line or all to agree on just one way to do things.

Not at all.

It goes like this:

One says:
“I’ve heard TehYoyo not only technically destroyed every itmitică’s response in Responsive Web Design Techniques thread, but he also made itmitică cry for days by being so mean and harsh to him! Can you believe that guy?!”

The other responds:
“That’s slander about things you don’t even know about. TehYoyo it’s a stand up guy. If you’ve bother to read the Responsive Web Design Techniques thread, it’d be very obvious that’s not true. TehYoyo never got into any technical matters whatsoever with itmitică, in that thread.”

Hey guys (you know who you are) - let’s avoid the personal sniping that has been going on in this thread and stick to making your points in a civil manner.

This is a great thread that has good arguments on both sides so lets not get personal.

Thank You

Uhm… the site you linked to? I thought that was part of why you were pointing out it’s approach as part of it’s zoom problem; since it also falls to shreds on large fonts/120dpi here – hence my “they used EM without understanding it” comment and general ragging on the page:

http://www.cutcodedown.com/images/broken/cloud4broken.png

Hence my comments about it. LOVE the content blowing off the right side of the screen without a horizontal scrollbar… and that’s just off this laptop; no I didn’t zoom that’s at default zoom but 120dpi/large… It’s even more mangled over on the workstation.

But again, when they allow whatever pile of manure CMS is underneath it make code like this:

<body class=“single single-post postid-2439 single-format-standard”>

or this:

<article class=“post-2439 post type-post status-publish format-standard hentry category-cloud-four-stories category-emerging-technology tag-fluid-layouts tag-media-queries tag-mobile-web-design tag-responsive-web-design” id=“post-2439”>

… results like that aren’t all that much of a shock. Goes hand-in-hand with their nonsensical and broken use of heading tags messing up heading navigation.
<h1>Cloud Four Blog</h1>
<h5>Technical notes, War stories and anecdotes</h5>

Really? REALLY? really…

… of course it has problems!

That’s a pain in the ass iOS behavior screwing with us. They insist on trying to handle content resizing even when you’ve made media queries to target it, and this can really mess up rotations as if you design for one rotation, the other will be screwed up.

You can get around that by disabling zooming altogether:


<meta
	name="viewport"
	content="width=device-width; initial-scale=1.0; minimum-scale:1.0; maximum-scale=1.0;"
/>

But does one really want to disable zooming?

They wrote the browser to first and foremost allow you to use websites NOT designed for mobile; as such trying to design for mobile on it has all this extra crap you have to do – pain in the ass. Viewport meta, -webkit-text-size-adjust:none; – etc, etc… and even with all that it still doesn’t behave and insists on resizing things when it shouldn’t… things that should probably be disabled the moment it sees a media query for 480width or narrower.

It’s like it ‘lying’ about how many pixels wide the display is if you don’t set that width=device-width thing…

Hmm I also tested it at 120 dpi & got different results:
http://img72.imageshack.us/img72/7222/120dpi.png

and at 192dpi:
http://img841.imageshack.us/img841/5539/192dpi.png

What’s happening differently on your system? I’m running windows 7 & latest version of Opera. Do you think that sidebar you have going on to the right affects the media query?

Same… I’m not even seeing the queries kick in properly here… on the laptop. It appears to render on my desktop how your screencaps do, so that’s kinda strange too. Something about my laptop?

Not the first time I’ve gotten RADICALLY different appearances across machines on same level OS/browser – I tend to get a LOT of broken layouts that seem to be related to methodologies like the ones they are using; See Paul O’B’s version of the 100% min-height layout that uses a negative top margin on the wrapper – which has not once rendered properly for me on any machine… or the display:table trick for inline-blocks, which doesn’t work for me in Safari. Cute tricks, but not what I’d call something to go around advocating as a way to build a site.

… also what I expect from 45k of whitespace compressed CSS going ape-**** with NINETEEN @media targets, and using @media inline in the stylesheet; so needlessly complex it’s a miracle the site works at all.

For so simple a site if they need more than 32k without whitespace stripping I’d be shocked! Looks like another case of whitespace stripping to cover up bad code… though one look at the HTML screams that anyways; NOT that all of it’s their fault – thanks turdpress!

Not quite as radical as DS’s layout, but the search bar is still kind of funky.

~TehYoyo

Yeah turns out that search bar is always bung. To bad it’s the only example I’ve found of em based media queries.

These em based media queries just make perfect sense to me. I’m going to have to try this method in the not to distant future - I don’t see why it shouldn’t work. And I’ll probably employ this 16px baseline technique (whilst rounding the numbers and adding some flexibility) despite the fact that it doesn’t lead me to understand the “point of ems” (I have my own purpose for them) - I think it’s a useful tool for figuring out the relationship between the elements and I understand that 1em != 16px.

If I get this working I’ll give you a shout-out if you could test them on one of your non-conformist machines.

[ot]ps. I like this new calmer, happier, more thoughtful deathshadow, that isn’t bashing everything he sees (… at least not as frequently) - it certainly get me less worked up & defensive.
I imagine he looks like this: http://th01.deviantart.net/fs71/PRE/i/2011/186/5/a/smiling_shadow_by_koigirlie-d3l32z9.jpg[/ot]

Off Topic:

Yes but you are the only one who has had a problem with it (although I’ve never seen en example where it was broken for you) and indeed examples you have shown have previously have been broken for us so it is a two way thing. There is nothing at all wrong with the sticky footer code as it is built on sound methodology (tried and tested thousands of times now) and indeed not one single person (apart from you) has had a problem with it (or the display:table fix either). You just have to accept (as I do) that there is no perfect solution for everyone and as Rayzur has pointed out many times it seems to be your exact system set ups that cause some things to behave differently.

Indeed I would like to know why the top negative margin approach doesn’t work for you and see an example where it doesn’t work and try to narrow down what the cause is as there surely must be one as it’s nothing more than a negative top margin instead of a bottom one.