Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Hi,
I've been doing some thinking about Respond.js vs No Query Fallback and mobile-first vs desktop-first in terms of development (not design).
Even though I agree that designs should be thought with a mobile perspective, personally I still prefer writing my CSS starting with the desktop because :
1/ it is the platform I am working on... so it's logical for me
2/ that way IE8 only loads desktop CSS not mobile or wide CSS which is exactly what I need... no need for respond.js or no-query fallback.
But I read this thread http://www.reddit.com/r/webdev/comments/20pp8p/every_time_i_get_pissed_t... and I realized that coding mobile first is important because that way you don't load unnecessary CSS and assets for mobiles. So I am willing to code mobile first :)
So now the question is No Query Fallback or Respond.js ?
I know that you guys recommend No Query Fallback... but if I am right, the no-query.css file is loaded all the time and everywhere even on modern browsers but above all on mobiles... And if I am right, because the no-query.css file is here for IE8 and below, it contains all the CSS that is needed to render the website for desktop...
I mean... the reason why I am willing to write my CSS mobile-first (which is not intuitive for me) is so that unnecessary CSS and assets don't get loaded on mobile devices so I don't want no-query.css to do just that!
I prefer to force all IE8 users to load an additional JS library... IE8 does not mean slow internet connection but mobile does.
Am I missing something or am I right here? So I guess loading no-query.css only for IE8 and below could be a start... or a requirement!
But another thing I don't like about no query fallback is that I need to write all my @include breakpoint with the 'true' parameter for their content to be rendered in no-query.css. I mean all the breakpoints from 0 to desktop. Not those for wide screens. I personally don't like to have to do that + the day we don't need to support IE8 all these 'true' parameters will have no reason to be and I am not gonna remove them all... even with find and replace...
On the other hand, adding respond.js only for IE8 and below the way Zen does in html.tpl is very easy and can be easily removed in the future.
One problem with Respond.js seem to be the fact that we must enable CSS aggregation... but this actually is something that should be done in production anyway... And I wonder if the problem still exists when all the SCSS are compiled in only one CSS file ?
What do you think?
Comments
Comment #1
fubhy CreditAttribution: fubhy commentedComment #2
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedThis nice feeling when you ask a question, someone reads it and the only thing he has to say is... "Major > Normal"... really makes you wanna ask more questions right ^^
For the record, the reason why I considered this major is because if I am right about what I say, if no-query.css indeed loads all desktop CSS and assets to mobile devices, well this is a major problem for everybody not including no-query.css ONLY on IE8 and below. If I am wrong, well at least a simple "I will get into details later but for now just be reassured that no-query.css does not affect mobile devices performances" would have been nicer than just "Major > Normal".
Comment #3
fubhy CreditAttribution: fubhy commentedThis is just a normal, automated thing I do when I browse the issue queue. Support request are never "Major". I just update the issue summary. Drupal.org treats that as a comment while it's clearly not. So yeah, just issue queue managing.
If you look at the output of the rendered page, you will notice that .no-query.css files are always added with a IE conditional comment. So, no... IE8 and below load no-query.css but any other browser doesn't. respond.js is an ugly polyfill (most, if not all polyfills are to be treated carefully because they easily break your site and slow it down tremendeously. I try to avoid them at all cost. Gracefull degradation and fallbacks are the way to go. The no-query fallback technique gives us a nice and convenient way to solve this problem satisfactorily. And besides that, there is absolutely no point in respond.js - Why would you want to force an extremely intrusive polyfill on a non-mobile browser that doesn't even need to serve your website mobile-optimized? IE8, IE7, etc. are all desktop browsers. There is no benefit of making them understand responsive other than causing a short "wow" effect when you demo your site on the shitty old computer of your client ;).
The 'true' in the breakpoint mixin doesn't hurt you *at all*. If you decide at some point in the future, that you don't want to provide no-query fallbacks anymore then simply remove the .no-query.scss file, recompile, done. There is nothing that leaks into the main style sheet... literally *nothing*.
Comment #4
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedBecause I write my CSS mobile first and wrap my desktop specific CSS in breakpoints. So without No Query Fallback or Respond.js IE8 and below will render the mobile version. I don't care about the responsiveness, just need media queries to render desktop version.
The 'true' in the breakpoint mixin doesn't hurt you *at all*.Well it hurts me :) I like to know that every bit of code I write has its importance. When IE8 support drops and I read my code and see those useless 'true' parameters that will bug me. Also I simply don't like to have to not forget to add 'true' everytime I write a breakpoint except for wide screen breakpoints when I could simply add one respond.js file once and for all. And last, I create website for web agencies that will take care of the future maintenance... so what will happen when this agency hires someone new in three month and he/she does not know that 'true' must be added to all breakpoints?
I personally don't like graceful degradation :)
I hate IE. I hate the fact that some people are still using old IE versions and anything I can do to make them upgrade I should do. If making them load a heavy Polyfill can make them feel like their computer / browser is slow, well this is perfect. Plus fallback means more work for me, well I am not going to work in favor of something I'm against! :)
Same goes with CSS3 PIE that I discovered thanks to omega btw :) I'd rather force IE8 users to load it and feel like "damn this browser is slow" rather than "dawn this browser is still fast but this website is ugly". I think IE8 users would never suspect that the website is slow because of a polyfill, not because of IE or winXP. Clients too will easily understand that loading a page in IE8 can be slow, but they have a harder time understanding that some shadows or border-radius won't be visible in IE8 and below.
So I hope Respond.js and CSS3 PIE will still be available in the next Omega version :)
Comment #5
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedI guess it all depends if you really need IE8 users to have a good experience or not... government websites for example must apply graceful degradation no doubt about it because everybody needs to be able to use them... but for some website IE8 users are not really the target and the look and feel is really important for the client.