7 ms·

In my work doing frontend web development CSS is the primary language I use. I don't use Less or SASS, I just write straightforward CSS. The only limitation I'

by err4nt 11y ago

In my work doing frontend web development CSS is the primary language I use. I don't use Less or SASS, I just write straightforward CSS. The only limitation I've run up against as far as responsive styling goes was that @media queries were always scoped to the browser's width/height, and I figured I could build much more advanced layouts if I had a way of scoping styles to individual elements. It turns out that's true, I have a plugin that lets me do this, so between regular CSS and these extra 'element queries' I have no issue styling anything I want. My plugin works down including IE8, so there's nowhere I need to write CSS where I can't use it. I'm not aware of how/why CSS needs to be fixed or replaced, it's a great solution for what it does. What do you propose instead of CSS? When you have well written HTML, it takes surprisingly few CSS declarations to add a good style!

talmand 11y ago
Most of the time when I see people complain about CSS it's because either they don't know how CSS works, or they want it to do something it wasn't designed to do in the first place. Most of the time it's because they don't know how it works.
- Bahamut 11y ago
  Lack of ability to nest rules in CSS makes it harder to organize styles. Not being able to create mixins and such makes all too easy to have to copy-paste and memorize cross-browser solutions & vendor specific rules for certain browsers. In short, there is a lot of inefficiency with the current system that preprocessors help alleviate.
  - talmand 11y ago
    They truthfully do help alleviate such things, but none of this is impossible nor too terribly difficult to handle with plain old CSS. Oddly enough, I've seen a number of people recently complaining about nesting in SASS claiming it creates problems. You just can't make everybody happy.
  - Raphmedia 11y ago
    Simply indent child rules one step to the right. This even allow you to use code folding to easily see what goes with what. Minify the code before it goes into production and you are ready to go.
  - err4nt 11y ago
    Why do you need to nest things? The 'C' in CSS stands for 'cascading'. Don't fear the cascade!
    - talmand 11y ago
      Well, it does clean up the code a bit, depending on your point of view. But it wouldn't necessarily interfere with cascade. It's just right now, because CSS doesn't support it, that SASS code gets compiled into large selectors if you aren't careful.
      - kolme 11y ago
        It helps a little in the code organization, however, it creates new problems. It makes deep nested code hard or impossible to reuse. It tightly couples style and markup, so a change in the latter can break the former, etc. So while it is a nice feature to have, I'd recommend using it scarcely and with great care.
        talmand 11y ago
        That's not a problem, that's not understanding how it works. Any nested SCSS is impossible to reuse outside of its parent scope. If someone is using nested SCSS and expecting to reuse that code elsewhere then they are doing it wrong. It's the same problem that exists if one were to create a class as a child of an ID and then expect to use that class outside of the ID's scope.
      - err4nt 11y ago
        Who needs code organization when Inspect Element gives you the filename and line-number, and all editors have Control-F :) You can edit minified code if you've had enough coffee!
- coldtea 11y ago
  If you frequently see people not knowing how CSS works, then that could be a sign that CSS is fundamentally broken, over engineered, etc for what it does... (rather than those devs being "stupid", "ignorant", "incompetent" etc).
Raphmedia 11y ago
Curious question from one frontend dev to another. Why don't you use Less or SASS? If server side compilation / javascript mode are a problem, you can simply set up a watch locally on your files using grunt or gulp.
- err4nt 11y ago
  I think there's a short list of situations where using a higher level language to describe CSS makes sense: - when demonstrating a pattern present in CSS at a higher level, to educate people who write CSS - when dealing with CSS animations where different browsers also use different properties - when it's your job to output lots of different pieces of CSS based off the same pattern Most of the time I'm either building new websites from scratch, or retrofitting old existing websites with responsive CSS and fixing problems. The web is written in three languages and only three languages: HTML, CSS, and JavaScript. If you're not writing one of those, you aren't writing the web. I can never be sure of the stack of the projects I'm going to be asked to fix, so if my requirement is: "Well I can fix it, but only as long as you use SASS" I'm going to be very hungry in life. I can (and do write) CSS from my phone, tablet, and multiple computers - but if I had a SASS/Less workflow, that would severely limit the situations where I could write new code. Frontend web shouldn't need to be compiled! Also, unless/until things like colour variables can also be used from JavaScript, I don't how useful CSS-only variables can really be. In my experience, specializing specifically in responsive CSS - I've just never run into a situation where I needed or could make use of the features of SASS or Less (or Stylus, or others) where it didn't create more work for me, plus introduce technical debt into my projects, while simultaneously restricting which devices I could work from and on which sites I could work. I could work that way, but I feel like I'd get 'Less' work done compared to the flexibility of pure CSS. Frontend to frontend dev: what is it you reach for in SASS or Less that can't be done by CSS, JavaScript, and HTML?
  - Raphmedia 11y ago
    I understand where you stand from, I've done quite a lot of work on support / upgrades of existing websites. I still think you may benefit from a workflow that uses a local build system... and once you use a build system, why not throw a preprocessor in? I can give you an exemple of my workflow for simple websites using Gulp.js (I used to use grunt.js, but really, it's all the same) I have a frontend folder structure that I carry around projects. There's a components folder and a build folder. The build folder is for minified files only. The components folder is split between components of the website, a bundle folder and a common folder. So I have /frontend/bundles, /frontend/common and let's say, /frontend/core-navigation. Under frontend/core-navigation, I have /styles (and scripts but let's ignore scripts for now). Under /styles, I have a main-menu.scss file. This allow me to have in there only the styles of the menu of the website. However, I don't want to burden this stylesheet with font-sizes, browser hacks, media queries definitions, etc. That's where the /frontend/common/styles folder come into play. In this folder, I have a config.scss file. This is where the preprocessor really shines. All the reusable and common variables, styles and mixins are there. Let's say $brand-color: #b41e3c; which is a blood red. Then, I have all the colors that starts from this color. The color for the titles of my website has to be the brand color but a bit lighter. That would be $light-title-color: adjust-hue(desaturate(lighten($brand-color, 20.58824%), .47553%), -4.28571deg);. Repeat for every color. Then, I have my font variables, $text-font: 'pier sans', sans-serif; $light-weight: 300; $extrabold-weight: 800; $letter-spacing-normal: .05em; I also have a bunch of mixins that are going to be used all over the website. @mixin icon-bag-white {@include scalable-icon-mixin('icon_bag.svg', 'common', $color: $white);} %hover-transition {transition: all #{$konstan-transition-hover}ms ease-out, z-index 1ms;} %form-label { display: inline-block; font-size: rem-calc(11); text-transform: uppercase; &.required em, .required { float: right; color: $brand-palette; } } etc. My media queries are also all predefined. $xlarge-up: "#{$screen} and (min-width:#{lower-bound($xlarge-range)})"; which allow me to easily use mediaqueries this way: @media #{$xlarge-up} { /styles for xlarge-up/} Back to frontend/core-navigation/main-menu.scss. Now that I have all those variables, I can easily style my main menu using the existing variables and styles definition that are in my config file. If I want to have a form label, I can simply @extend %form-label and I don't have to rewrite all those style definitions. I work in team with other developers, so it really help to have those definitions written only once so that we don't end up with code duplication. All of those styles sheets are bundles under the /frontend/bundles folder. In this folder, I have multiple files filled with @import definitions. All those are bundles and using Gulp.js, I can output them wherever I want. Most of the time that's going to be under /frontend/build/stylescore.css. However, if I'm working on a CMS website, I can output the minified stylesheet in let's say, /magento/skin/styles. I use gulp.js to minify my stylesheets, to compress my images, to generate multiple versions of my share icon for every device out there, etc. Something really cool too is a task which write browser prefix and browser hacks for me. I simply write display: flex; and when I save the file, it's going to put display: -webkit-box; display: -webkit-flex; display: -ms-flexbox; display: flex; in the build file for me. There's one for polyfills too, so you can use rounded corners on IE7, etc. All of my files are put under a watch task, so whenever I save a file, the workflow starts by itself. If make changes to main-menu.scss and save it, it's automatically going to minify the file and send it in the right folder. I can work as if my .scss file is a normal .css file. And the beauty of it? It's all done locally, no dependancy on a server or a backend guy. I don't need to install any php module on the server or anything. I simply throw the /build file on the production server and everything is going to work the way I want it to. I have a similar workflow that use the same folder structure for my scripts.

by err4nt 11y ago

talmand 11y ago

Most of the time when I see people complain about CSS it's because either they don't know how CSS works, or they want it to do something it wasn't designed to do in the first place. Most of the time it's because they don't know how it works.

Bahamut 11y ago
Lack of ability to nest rules in CSS makes it harder to organize styles. Not being able to create mixins and such makes all too easy to have to copy-paste and memorize cross-browser solutions & vendor specific rules for certain browsers. In short, there is a lot of inefficiency with the current system that preprocessors help alleviate.
- talmand 11y ago
  They truthfully do help alleviate such things, but none of this is impossible nor too terribly difficult to handle with plain old CSS. Oddly enough, I've seen a number of people recently complaining about nesting in SASS claiming it creates problems. You just can't make everybody happy.
- Raphmedia 11y ago
  Simply indent child rules one step to the right. This even allow you to use code folding to easily see what goes with what. Minify the code before it goes into production and you are ready to go.
- err4nt 11y ago
  Why do you need to nest things? The 'C' in CSS stands for 'cascading'. Don't fear the cascade!
  - talmand 11y ago
    Well, it does clean up the code a bit, depending on your point of view. But it wouldn't necessarily interfere with cascade. It's just right now, because CSS doesn't support it, that SASS code gets compiled into large selectors if you aren't careful.
    - kolme 11y ago
      It helps a little in the code organization, however, it creates new problems. It makes deep nested code hard or impossible to reuse. It tightly couples style and markup, so a change in the latter can break the former, etc. So while it is a nice feature to have, I'd recommend using it scarcely and with great care.
      - talmand 11y ago
        That's not a problem, that's not understanding how it works. Any nested SCSS is impossible to reuse outside of its parent scope. If someone is using nested SCSS and expecting to reuse that code elsewhere then they are doing it wrong. It's the same problem that exists if one were to create a class as a child of an ID and then expect to use that class outside of the ID's scope.
    - err4nt 11y ago
      Who needs code organization when Inspect Element gives you the filename and line-number, and all editors have Control-F :) You can edit minified code if you've had enough coffee!
coldtea 11y ago
If you frequently see people not knowing how CSS works, then that could be a sign that CSS is fundamentally broken, over engineered, etc for what it does... (rather than those devs being "stupid", "ignorant", "incompetent" etc).

Raphmedia 11y ago

Curious question from one frontend dev to another. Why don't you use Less or SASS? If server side compilation / javascript mode are a problem, you can simply set up a watch locally on your files using grunt or gulp.

err4nt 11y ago
I think there's a short list of situations where using a higher level language to describe CSS makes sense: - when demonstrating a pattern present in CSS at a higher level, to educate people who write CSS - when dealing with CSS animations where different browsers also use different properties - when it's your job to output lots of different pieces of CSS based off the same pattern Most of the time I'm either building new websites from scratch, or retrofitting old existing websites with responsive CSS and fixing problems. The web is written in three languages and only three languages: HTML, CSS, and JavaScript. If you're not writing one of those, you aren't writing the web. I can never be sure of the stack of the projects I'm going to be asked to fix, so if my requirement is: "Well I can fix it, but only as long as you use SASS" I'm going to be very hungry in life. I can (and do write) CSS from my phone, tablet, and multiple computers - but if I had a SASS/Less workflow, that would severely limit the situations where I could write new code. Frontend web shouldn't need to be compiled! Also, unless/until things like colour variables can also be used from JavaScript, I don't how useful CSS-only variables can really be. In my experience, specializing specifically in responsive CSS - I've just never run into a situation where I needed or could make use of the features of SASS or Less (or Stylus, or others) where it didn't create more work for me, plus introduce technical debt into my projects, while simultaneously restricting which devices I could work from and on which sites I could work. I could work that way, but I feel like I'd get 'Less' work done compared to the flexibility of pure CSS. Frontend to frontend dev: what is it you reach for in SASS or Less that can't be done by CSS, JavaScript, and HTML?
- Raphmedia 11y ago
  I understand where you stand from, I've done quite a lot of work on support / upgrades of existing websites. I still think you may benefit from a workflow that uses a local build system... and once you use a build system, why not throw a preprocessor in? I can give you an exemple of my workflow for simple websites using Gulp.js (I used to use grunt.js, but really, it's all the same) I have a frontend folder structure that I carry around projects. There's a components folder and a build folder. The build folder is for minified files only. The components folder is split between components of the website, a bundle folder and a common folder. So I have /frontend/bundles, /frontend/common and let's say, /frontend/core-navigation. Under frontend/core-navigation, I have /styles (and scripts but let's ignore scripts for now). Under /styles, I have a main-menu.scss file. This allow me to have in there only the styles of the menu of the website. However, I don't want to burden this stylesheet with font-sizes, browser hacks, media queries definitions, etc. That's where the /frontend/common/styles folder come into play. In this folder, I have a config.scss file. This is where the preprocessor really shines. All the reusable and common variables, styles and mixins are there. Let's say $brand-color: #b41e3c; which is a blood red. Then, I have all the colors that starts from this color. The color for the titles of my website has to be the brand color but a bit lighter. That would be $light-title-color: adjust-hue(desaturate(lighten($brand-color, 20.58824%), .47553%), -4.28571deg);. Repeat for every color. Then, I have my font variables, $text-font: 'pier sans', sans-serif; $light-weight: 300; $extrabold-weight: 800; $letter-spacing-normal: .05em; I also have a bunch of mixins that are going to be used all over the website. @mixin icon-bag-white {@include scalable-icon-mixin('icon_bag.svg', 'common', $color: $white);} %hover-transition {transition: all #{$konstan-transition-hover}ms ease-out, z-index 1ms;} %form-label { display: inline-block; font-size: rem-calc(11); text-transform: uppercase; &.required em, .required { float: right; color: $brand-palette; } } etc. My media queries are also all predefined. $xlarge-up: "#{$screen} and (min-width:#{lower-bound($xlarge-range)})"; which allow me to easily use mediaqueries this way: @media #{$xlarge-up} { /styles for xlarge-up/} Back to frontend/core-navigation/main-menu.scss. Now that I have all those variables, I can easily style my main menu using the existing variables and styles definition that are in my config file. If I want to have a form label, I can simply @extend %form-label and I don't have to rewrite all those style definitions. I work in team with other developers, so it really help to have those definitions written only once so that we don't end up with code duplication. All of those styles sheets are bundles under the /frontend/bundles folder. In this folder, I have multiple files filled with @import definitions. All those are bundles and using Gulp.js, I can output them wherever I want. Most of the time that's going to be under /frontend/build/stylescore.css. However, if I'm working on a CMS website, I can output the minified stylesheet in let's say, /magento/skin/styles. I use gulp.js to minify my stylesheets, to compress my images, to generate multiple versions of my share icon for every device out there, etc. Something really cool too is a task which write browser prefix and browser hacks for me. I simply write display: flex; and when I save the file, it's going to put display: -webkit-box; display: -webkit-flex; display: -ms-flexbox; display: flex; in the build file for me. There's one for polyfills too, so you can use rounded corners on IE7, etc. All of my files are put under a watch task, so whenever I save a file, the workflow starts by itself. If make changes to main-menu.scss and save it, it's automatically going to minify the file and send it in the right folder. I can work as if my .scss file is a normal .css file. And the beauty of it? It's all done locally, no dependancy on a server or a backend guy. I don't need to install any php module on the server or anything. I simply throw the /build file on the production server and everything is going to work the way I want it to. I have a similar workflow that use the same folder structure for my scripts.