CSS or Separate Mobile Site?
CSS does provide mechanisms for altering style based on display size (@media rules). Since the content of the site would (presumably) be the same in either case, only the styling would vary.
Doing a redirection will involve duplicating content, and hence duplicated work.
There are at least three different ranges of display size to consider, and the aspect ratio of at least two of them could be either portrait or landscape (and may even change while the page is being viewed).
Weedpacket;11049487 wrote:CSS does provide mechanisms for altering style based on display size (@media rules). Since the content of the site would (presumably) be the same in either case, only the styling would vary.
Doing a redirection will involve duplicating content, and hence duplicated work.
There are at least three different ranges of display size to consider, and the aspect ratio of at least two of them could be either portrait or landscape (and may even change while the page is being viewed).
It was pretty much the plethora of sizes and aspects that led us to what we did to prepare for Mobilegeddon ... we didn't duplicate content, per se, but used the same classes and main scripts with different templates for mobile ....
I've wanted to ask this same question.
I think the answer sort of depends on the content. Is your page simple text & pictures? That seems easy enough. Is it an elaborate input form? Hmmm...that's a different consideration.
And the penalty of duplicated work is sometimes less than the penalty of writing adaptive code. Nothing contributes to a code maintenance burden like thickets of if/then logic or browser capability sniffing code or a nightmare of conditional CSS.
The industry is moving in the direction of (if it hasn't already) creating one site with one set of content and changing its appearance via CSS media queries. Managing multiple sets of content is a nightmare.
I have created several reactive/responsive websites and really you shouldn't need complicated JavaScript, browser sniffing or feature detection, or conditional CSS. Pretty much every new site that we sell now has some kind of reactive/responsive component (if not the entire site). We've never had to create multiple sets of content or do anything crazy. Some of our old sites we would create two menus (desktop and mobile), but that practice has fallen out of favour a long time ago. That's the closest we have come to creating multiple sets of content.
Bonesnap;11049553 wrote:The industry is moving in the direction of (if it hasn't already) creating one site with one set of content and changing its appearance via CSS media queries. Managing multiple sets of content is a nightmare.
I certainly won't refute it's headed that way, but would point out that youtube has an entirely distinct subdomain for mobile devices: m.youtube.com versus youtube.com. I don't know if this means they have an entirely different file come down for mobile devices, but I wonder what the point is of using a separate subdomain if not to offer a different system entirely.
Bonesnap;11049553 wrote:I have created several reactive/responsive websites and really you shouldn't need complicated JavaScript, browser sniffing or feature detection, or conditional CSS. Pretty much every new site that we sell now has some kind of reactive/responsive component (if not the entire site). We've never had to create multiple sets of content or do anything crazy. Some of our old sites we would create two menus (desktop and mobile), but that practice has fallen out of favour a long time ago. That's the closest we have come to creating multiple sets of content.
I'm not sure that I agree with this assessment for all sites. If you don't need browser sniffing, then what's the point of a project like Modernizr[/ur]? Also, I'm having trouble picturing how I can set up my [url=http://board.phpbuilder.com/showthread.php?10393891-Porting-10-yr-old-drag-amp-drop-flash-app-to-the-modern-era]drag and drop app with one codebase that simple works on screens both large and small.
If there is a way to do this once and have it work on all machines, I'll be gobsmacked.
I would recommend using CSS. I would strongly suggest using something like bootstrap or foundation along side less or sass. Once you get used to it it is a very powerful combo.
css is best
sneakyimp;11049595 wrote:I certainly won't refute it's headed that way, but would point out that youtube has an entirely distinct subdomain for mobile devices: m.youtube.com versus youtube.com. I don't know if this means they have an entirely different file come down for mobile devices, but I wonder what the point is of using a separate subdomain if not to offer a different system entirely.
Having a distinct subdomain or top-level domain (.mobi) was the thing to do a few years ago. Don't forget the earliest version of IE to support media queries was IE9. Even to this day IE8 has a reasonable market share. A few years ago it was much higher. In the past we have used a JavaScript library to recreate @media queries but I believe the library a more recent thing because supporting legacy browsers is still, unfortunately, "a thing" (luckily some companies are trying to move forward by dropping support for older browsers, but as we all know in this industry, it's a slow and painful process). Also, if the user has JavaScript disabled then you're out of luck entirely.
My guess is the m.youtube.com subdomain is legacy code that will eventually be deprecated and no longer used. Even Wikipedia has a mobile "version". These are probably "relics" from an older Internet. They have just not been updated yet, probably because while they may not be on the cutting edge, they're not technically broken. Google used to use Open Sans in its official branding but has since slowly moved over to Roboto. Takes time, though.
sneakyimp;11049595 wrote:I'm not sure that I agree with this assessment for all sites. If you don't need browser sniffing, then what's the point of a project like Modernizr[/ur]? Also, I'm having trouble picturing how I can set up my [url=http://board.phpbuilder.com/showthread.php?10393891-Porting-10-yr-old-drag-amp-drop-flash-app-to-the-modern-era]drag and drop app with one codebase that simple works on screens both large and small.
If there is a way to do this once and have it work on all machines, I'll be gobsmacked.
The real purpose for a library like Modernizr is to test for specific browsers in specific scenarios, usually when you're doing some kind of functionality. The truth is though that responsive/reactive websites rely on screen resolution, window/device size, pixel density, and device orientation - all of which are completely independent of browsers and therefore browser sniffing or feature detection doesn't apply. They can also all be taken care of via CSS and therefore JavaScript isn't even required.
Sometimes things can't work on all devices. When I recently redid the quote form on my company's website, I put in a drag-and-drop file uploader. But on mobile devices it's replaced with a standard file upload because there is no "desktop" on a phone. Everything is "full screen". Sounds like this may change with Windows 10 or maybe it already has elsewhere. But one thing I have learned while making responsive websites is you don't have to make it behave identically in every scenario - you just have to make it behave logically and still have access to your content/functionality that you need. It just needs to be presentable and work reasonably well.
Also I would argue that responsive/reactive layout is more about presentation than functionality. It's about how your pages are laid out in a much smaller container/window. If you have specific functionality that needs to be either a) replicated, or b) replaced, that's where something like Modernizr comes into play.