[HN Gopher] Mobile-First CSS: Is It Time for a Rethink?
       ___________________________________________________________________
        
       Mobile-First CSS: Is It Time for a Rethink?
        
       Author : kiyanwang
       Score  : 37 points
       Date   : 2022-06-19 19:58 UTC (3 hours ago)
        
 (HTM) web link (alistapart.com)
 (TXT) w3m dump (alistapart.com)
        
       | asddubs wrote:
       | mobile first css was really useful when stuff like grid wasn't
       | well supported everywhere yet. you could stick stuff in a
       | @supports block, and older browsers just get the mobile view
       | instead, which usually doesn't need grid. But yeah, having done a
       | good bit of both ways, I do think the desktop first way is just
       | easier to write. You would think that "hey things are just
       | stacked on top of one another by default anyway, so mobile
       | default just makes sense", but mobile CSS tends to have a bunch
       | of spacing rules you end up having to undo again, whereas most of
       | the desktop stuff you overwrite is, in my experience, stuff you'd
       | usually have two different rules for no matter what.
       | 
       | Plus, the desktop design tends to be the more complex one, so the
       | HTML will be laid out to accomodate grids/flexbox elements, etc.
       | where necessary. for the mobile view, you usually don't have to
       | change the HTML as much.
        
       | V__ wrote:
       | I can't wait for container queries to finally get browser
       | support. I just want to write self-contained css which is
       | reusable and not dependent on a framework, a preprocessor, or a
       | methodology like bem. One file for my components, one file for
       | the responsive layout, and one for fonts and variables.
        
       | 1123581321 wrote:
       | I can attest to not thinking about either mobile or desktop much
       | in isolation since utility div classes in frameworks have become
       | muscle memory. The other beneficial change has been to just look
       | for visually weak browser width ranges, within content sections
       | or components, and adjust them, regardless of whether "mobile" or
       | "tablet" would be looking at them. It sounds like more work, but
       | it's better than trying to work to an arbitrary spec and usually
       | results in more thoroughly refined work than conceived by
       | designers.
        
       | keyle wrote:
       | Dumb Q: if you split them as in the example at the end of the
       | article... then you have a lot of duplicated rules obviously as
       | 90% of your CSS _should_ be the same?
       | 
       | Maybe the example at the end wasn't clear enough that you should
       | still have a base CSS that encompasses the common parts?
        
         | gnabgib wrote:
         | It looks like Patrick is proposing the `default.css` holds most
         | of the CSS (the 90% you're talking of), with
         | mobile/tablet/desktop/print holding only variances over those
         | base settings (so they'd only be the further 10% and only one
         | downloaded matching the media definition.. maybe two if you
         | print preview)
        
       | nojs wrote:
       | Having done a lot of both ways, I am still a fan of mobile first.
       | Otherwise inevitably the mobile site ends up being an
       | afterthought, with retrofitted elements that almost but don't
       | quite work on mobile (often everything on the desktop page is
       | just stacked, and it doesn't quite work but it's hard to put your
       | finger on why). This rarely happens in reverse, because the
       | default lazy desktop implementation is just that it's "too
       | simple" which is generally much less of a problem. It's more
       | obvious when something needs to be added than when it needs to be
       | simplified or removed.
        
       ___________________________________________________________________
       (page generated 2022-06-19 23:00 UTC)