Hey all! š Iām Ryo, a Sr. Design Technologist at PlayStation. I do web dev with React/TS/Node and game dev with Unity/C#/C++/OpenGL/DirectX. Feel free to ask me any questions! š¤
Since mobile development tends to be one, maybe two col max, if I'm only provided a desktop version of the design, I just run with it and simplify/distill the design down. If there's any elements that don't work on mobile, they get cut out completely until the designer complains and sends over a more mobile-friendly design š Unless you're hired as the designer, or you're included in the design process, it's not your job to "get creative" or "invent" solutions to design problems that should have been resolved in the wireframe/mockup phase.
No preference on grid size really. I tend to use 5 and 24 cols, since they're most prevalent in grid systems, but I'll use 3/4/8/16/anything that looks right/makes the design work best.
At minimum for any project, one media query (either for desktop or mobile), and the base CSS defaults to the other. If the design is more complex, I add media queries as necessary to correct issues at the problem breakpoint (usually at uber-wide resolutions if the site's audience is rocking 4k double-wide monitors, or small fixes for absolutely positioned elements)
CSS/SASS for most animations, unless it's so complex that it requires JS (JS functionality like checking animation frames or DOM elements, or using a lib like GreenSock). Going CSS-first usually ensures the highest level of browser compatibility, particularly since animations will work even when JS is disabled client-side.
I use SASS when the project is so large I'll be using variables across the app (which could be replaced with CSS vars) and when I need the power of mixins to simplify CSS generation (like grids, complex animations, or repetitive actions). Otherwise pure CSS run through a minification process (Gulp/Grunt/Webpack/Parcel) before it's deployed to prod works fine. I tend to use BEM combined with OOCSS, so I have non-conflicting CSS styles (.HeaderMenu with .HeaderMenu > .list and .HeaderMenu .item nested classes). That way I get non-conflicting base styles, with without the verbose BEM sub-classes (.HeaderMenu__item) and my shorter CSS classnames work fine thanks to specificity. Similar to Airbnb's CSS style guide (BEM component-style names), combined with Semantic UI's (OOCSS).
Thanks for the thorough answers Ryosuke! Re: 5. This is giving me clear insight on why to use SASS. I've given it a half-hearted shot at learning but never felt a personal project of mine needed it. I forgot about mix-ins too, which could be fun. I do enjoy the facility of using minifiers and maybe that is the appeal of preprocessors/CSS libraries. I have also leaned towards using CSS for animations because I heard JS forces the browser to do more work, but never really animated anything that complicated anyway.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Since mobile development tends to be one, maybe two col max, if I'm only provided a desktop version of the design, I just run with it and simplify/distill the design down. If there's any elements that don't work on mobile, they get cut out completely until the designer complains and sends over a more mobile-friendly design š Unless you're hired as the designer, or you're included in the design process, it's not your job to "get creative" or "invent" solutions to design problems that should have been resolved in the wireframe/mockup phase.
No preference on grid size really. I tend to use 5 and 24 cols, since they're most prevalent in grid systems, but I'll use 3/4/8/16/anything that looks right/makes the design work best.
At minimum for any project, one media query (either for desktop or mobile), and the base CSS defaults to the other. If the design is more complex, I add media queries as necessary to correct issues at the problem breakpoint (usually at uber-wide resolutions if the site's audience is rocking 4k double-wide monitors, or small fixes for absolutely positioned elements)
CSS/SASS for most animations, unless it's so complex that it requires JS (JS functionality like checking animation frames or DOM elements, or using a lib like GreenSock). Going CSS-first usually ensures the highest level of browser compatibility, particularly since animations will work even when JS is disabled client-side.
I use SASS when the project is so large I'll be using variables across the app (which could be replaced with CSS vars) and when I need the power of mixins to simplify CSS generation (like grids, complex animations, or repetitive actions). Otherwise pure CSS run through a minification process (Gulp/Grunt/Webpack/Parcel) before it's deployed to prod works fine. I tend to use BEM combined with OOCSS, so I have non-conflicting CSS styles (
.HeaderMenuwith.HeaderMenu > .listand.HeaderMenu .itemnested classes). That way I get non-conflicting base styles, with without the verbose BEM sub-classes (.HeaderMenu__item) and my shorter CSS classnames work fine thanks to specificity. Similar to Airbnb's CSS style guide (BEM component-style names), combined with Semantic UI's (OOCSS).Thanks for the thorough answers Ryosuke! Re: 5. This is giving me clear insight on why to use SASS. I've given it a half-hearted shot at learning but never felt a personal project of mine needed it. I forgot about mix-ins too, which could be fun. I do enjoy the facility of using minifiers and maybe that is the appeal of preprocessors/CSS libraries. I have also leaned towards using CSS for animations because I heard JS forces the browser to do more work, but never really animated anything that complicated anyway.