- This topic is empty.
June 9, 2014 at 4:51 pm #172264
I usually pride myself on being able to find information online (especially through Google) however, after an exhaustive search and even a purchase of an online book, I have no answer to this question, so I’m turning here.
Basically it has to do with how does one determine the resolution of the screen in order to only generate the code needed for the current “size” the responsive site is in?
ie, if there are 3 breakpoints in my design, on a page load, how can I tell that the browser is at the “second breakpoint” so that not only do I generate that content only, but if/when the browser changes, I have the code/resources in place to support those responsive sizes.
Did I explain that well enough? I had a book discuss: Fluid Layouts, Media Queries, Responsive Media, Design Workflows, Responsive Content and RESS, but provided absolutely no solutions for how to do this.June 10, 2014 at 1:52 pm #172322
Well if you have three breakpoints, you should be able to tell where you’re at by simply resizing the browser.
But the good answer is by inspecting the DOM. In Chrome, for instance, when you right-click and inspect element, you’re looking at the DOM (which is not the same as the source), this is the thing that the browser actually rendered after all scripts, CSS, etc., were compiled.
When you review any element in this way, you can see where in the CSS you’re at on the right side – including which media query.June 10, 2014 at 5:23 pm #172351
I’m familiar with the DOM, but would I not have to wait til the page loaded to determine the size of the screen, to then send back to the server to generate only the content which is needed for that breakpoint? See my conundrum here? I have to wait for the browser to load before I then make an additional request to tell it what code to load (at least with my current mindset)June 10, 2014 at 5:36 pm #172352
Are you attempting to do server-side code based on the size of the viewport? I’m afraid that’s a non-starter, hence why AJAX exists.
The server will never know the size of the viewport, even if you do a quick refresh for some reason there’s nothing to stop the user from changing the size of their browser or switching from vertical to horizontal on their phone.
Tell me precisely what you’re trying to accomplish (I realize you want to do something based on viewport size), and we can go from there.June 10, 2014 at 7:11 pm #172358
OK, let’s go on the premise that I might just be naive to an obvious answer here, but here goes. I also find myself having a hard time just putting into words my issue here, but here goes:
My responsive site loads up. Lets say I tell my server side code to generate content that, when viewed on the mobile device, looks great. Problem is, as tablets and laptops view the site, the site expands, wastes content, etc. This is where breakpoints come in. As more room is available, my media queries can alter CSS styles to change the look, right?
But that’s my issue. At some point, there is markup and media that exists at larger resolutions that should NOT be generated or loaded at smaller resolutions (it would just waste bandwidth). So is the solution here to generate the markup needed for all breakpoints, and then to just hide things by default, determine the current breakpoint and programmatically enable only the content that should be needed by the current layout?
My question seems to revolve around management and “how to introduce” extraneous markup and resources. Was I any clearer in that explanation, or is it still mud? (btw, thank you for your help)June 10, 2014 at 7:27 pm #172359
Nope I get it – you have content that you want visible for smaller resolutions, but not larger resolutions (or vise versa).
That’s quite simple using CSS media queries and something like
When trying to wrap your head around this stuff, it might help to see how the pros do this. There are many popular frameworks that have this built in, but one I really like how they do this type of thing is Foundation.
If you were to inspect the various elements you can see how they’re doing it. This will work for text, a whole block of code, whatever.
This is all happening client-side mind you, no need to tell the server to give different code.
What you might want to do is start a codepen and try to get text to show and hide based on the viewport size… once you have that, you’ll be on your way for this aspect of what you want. Any issues you have we can tackle with real code (which always helps).June 10, 2014 at 7:36 pm #172360AlenParticipant
Start with a mobile first mindset and, think about content strategy and information architecture. You can then use various techniques to conditionally load data, hide/show it, etc., depending on view-port size.
I think we understand the overall issue, we would need more info about the specific problem you’re facing. Do you have code examples? or anything that will help us diagnose the problem or at least offer suggestions.June 10, 2014 at 8:14 pm #172362
Hey Alen. I have read through Luke Wroblewski’s “Mobile First” book (loved it and agree fully about embracing the constraints of mobile), but you nailed the issue on the head about conditionally loading data.
Let’s just take this a step at a time. When the site loads, does the markup for all breakpoints need to be loaded (even if CSS is making things invisible or changing layout properties)? Forget, for a moment, extra resources (like lo-res images vs hi-res) let’s just start with the basics.June 10, 2014 at 8:18 pm #172363
OK, so having read what you said, they DO render all markup despite the initial rendering breakpoint. So if I have 3 different breakpoints, I should load their markup, allow the CSS to determine which CSS to load via queries, and then look into additional methods by which resources can be loaded. By that I mean large-resolution images, conditional scripts depending on browser capabilities, etc, right?
I had been going under the belief that you should only render the markup needed by the current breakpoint and nothing more. But as I pondered over that, I knew that the server had to have responded by the time the client-side code would know what breakpoint the site was at. Do I have this correct so far?June 10, 2014 at 10:59 pm #172368
Well – why would you want markup to be so different?
Consider this example: http://getbootstrap.com/examples/navbar/
When you resize your browser, content changes, but all the content is still there. In other words, the markup itself didn’t change, only the styling.
There are times where you might want the markup itself to be different, but that should be the exception and not the rule.June 11, 2014 at 7:26 am #172412
So. Create all the markup. Let the CSS apply what is pertinent depending on the breakpoint rules in the media queries, and then find loading resources for things like images, scripts, and styles to only make the request for those resources when the current viewport dictates it. Does this sound more concise?June 11, 2014 at 7:52 am #172418
You’re getting closer.
Images are tricky right now, but they’re working on it: http://www.w3.org/community/respimg/
I think what you want is to be as efficient as possible by only loading certain scripts and styles based on the viewport, but what you’ll find is that all viewports share the same resources , with rare exceptions.
When building from the ground up and starting simple at “mobile”, then adding enhancements as you can, you’ll find that those core defaults from the simple site bleed through all the way up if you do it right. Doing less HTTP requests and keeping everything all together I’m sure is much more efficient than trying to keep separate code bases for your break points. Both for maintenance for you, and speed to the client.June 11, 2014 at 9:42 am #172436
OK. So, with keeping requests to a minimum (combining JS, CSS where needed) and then utilizing image loading resources until a solid solution begins to take a foothold, my hurdle here is to determine the components that the mobile design uses, design its layout, functions, and then envision how the layout will adapt visually and functionally as the viewport expands.
I guess it’s only natural, being my first attempt, that the designing process (though vitally important) takes the most amount of time in planning out. I definitely feel that the ounce of design is worth a pound of re-design.June 11, 2014 at 10:33 am #172440nixnerdParticipant
I think the MAIN sticking point here is an issue of how responsive design is approached.
The BEST way to design responsively is to use all the same content for all screen sizes. You should not have a bunch of different elements/assets for various screen sizes. As @shaneisme stated, your markup/content/elements/assets should all be the same and then just get resized based on the screen size.
Sometimes this isn’t possible.
I am well, well aware of the fact that is is INSANELY difficult with images because they can only be resized to a certain extent. If you design your site with a HUGE background photo that will accommodate a 27″ iMac or a Macbook Pro with a retina display, it makes NO SENSE to load that same image on a small screen, that doesn’t need SUCH a huge photo and will likely have a slower connection speed. Likewise, you can’t use a really small photo and stretch the hell out of it and let it get all pixelated. I get it. I’ve been there. The only REAL solution I’ve found, is to get waaaaaay more creative with how I incorporate images.
Here is a really great resource for learning about how images specifically are loaded/handled by various browsers:
I’m assuming that images are your main problem, as they are by far the most bloated element/asset we use.
Again, you’re talking about NOT loading certain things at certain screen sizes, which would lead me to believe you’re not using all of the same content at every size.June 11, 2014 at 1:31 pm #172454
Well, I can definitely see images as being a challenge down the line, but yes, I’m talking about selective loading of markup.
I’m just not sure whether I’ll find that the design as it is on a mobile device vs. how I have it look via a tablet device will be doable with a simple expansion of elements and changing of their properties. Instead, there may be ranges of markup which are just outright hidden/shown depending on the viewport, because enough of the design changes that it would not be possible to make slight adjustments and have the elements layout in the new design appropriately.
- The forum ‘Other’ is closed to new topics and replies.