6 ms·

Finally! I've been consistently bothered when people hype preprocessors like SASS and LESS as "the future of CSS" or "fixes to the CSS problem." Yes, they make

Finally! I've been consistently bothered when people hype preprocessors like SASS and LESS as "the future of CSS" or "fixes to the CSS problem." Yes, they make things somewhat nicer by adding variables and macros and the like, but it's still fundamentally CSS, a language that was designed to style documents rather than implement complicated and dynamic layouts. My bar for programming/markup languages is how close they come to intent. For example, centering something in CSS is a mess of absolute positions and table-cells -- it couldn't be farther from the simple intent of "I'd like to center this." So, that's why I'm so excited about this. Writing normal CSS seems like writing Assembly, and SASS/LESS just adds some nice macros... to your Assembly. This feels like writing real code.

hiphopyo 13y ago
For sure. I've always refused SASS and LESS as well. The reason being, if your design is simple enough, you don't need that stuff in the first place.
- scarecrowbob 13y ago
  Much as if your program is simple enough, you shouldn't need C? FWIW, I think that CSS is no great language, and yes, writing LESS feels very much like writing macros rather than using a language, but the requirements of the designs I have to implement are generally complex enough that a preprocessor and CSS framework greatly simplify my work, leaving me more time to focus on intent (which I think is a reasonable goal) rather than details of implementation. If it works well for you to refuse to learn a preprocessor, then that is a good thing, but the fact that one makes my life easier doesn't necessarily imply that the designs I am implementing are overly complex, as your statement seems to imply (though perhaps I am misreading so...)
- nicklovescode 13y ago
  You seem to be saying the opposite of what the parent comment is.
rimantas 13y ago
> #container {display:flex;} > #foo {margin: auto;} or > display: table-cell; > vertical-align: middle; Where is the mess in these?
- RaphiePS 13y ago
  Imagine you didn't know anything about CSS and look at your examples. What the heck is margin, and why is it auto? Why would that center something? What are table cells doing in here? To me, it's just completely divorced from the actual meaning. At the risk of repeating my original comment, CSS poorly encapsulates the intent. Yes, it works and it's short, but it's sorta hacky, sorta circuitous. Instead of just telling the computer to center something, you're giving it detailed instructions, instructions it easily could (and thanks to GSS, can) figure out.
parksy 13y ago
I agree. In addition, with each year comes a new "super-duper-real-correct-semantic" way of doing it. That word semantic. It grates me. Everyone uses it to back their argument, then throws their hands up and "case closed". The meaning has been lost. Like now we have to: <div class="write"> <div class="write__our"> <div class="write__our__classes"> <div class="write__our__classes__like"> <div class="write__our__classes__like__this"> </div> </div> </div> </div> </div> <div class="instead"> <div class="of"> <div class="like"> <div class="this"> </div> </div> </div> </div> Which "old me" says is disgusting and breaks the rules of semanticism. The DOM loses meaning and becomes a vessel for the form / appearance. But I get why people do it. It's pragmatic. I don't like it, but it works. Regardless of the real real true real true way of doing things and all the arguments that people like to have about that, it's obvious why people are constantly trying to find these conventions and rules of thumb. It's because form and function are not properly separated with CSS alone. Using the DOM purely as a vehicle of function makes forming difficult, while pulling form into the DOM level muddies up the goal of semantic documents - the idea that a machine should be able to comprehend the nature of (X)HTML content has fallen to the wayside but that's a separate argument (should documents be sources of truth, isn't that what REST is for, are entities documents, etc). The thing is that XML & XSLT got us oh-so-close. Nice, lovely pure XML documents with clean semantic tags and attributes with strongly typed definitions that had meaning to both humans and machines. A transform step converted these into an XHTML presentation format, adding whatever DOM sugar was needed for the CSS and JS to do its thing. It was almost there. Where it fell down is where I think you hit the nail on the head. Both CSS and JS are needed currently to do very basic things, with a lot of overlap for things like positioning or animating transitions. A single layout language that handles _everything_ in an intuitive way without having to navigate the CSS+HTML+JS love triangle would be fantastic. Sorry for the somewhat longwinded response for what is otherwise a "me to" comment. I guess I just needed to vent a little - long day at the office and all :/

hiphopyo 13y ago

For sure. I've always refused SASS and LESS as well. The reason being, if your design is simple enough, you don't need that stuff in the first place.

scarecrowbob 13y ago
Much as if your program is simple enough, you shouldn't need C? FWIW, I think that CSS is no great language, and yes, writing LESS feels very much like writing macros rather than using a language, but the requirements of the designs I have to implement are generally complex enough that a preprocessor and CSS framework greatly simplify my work, leaving me more time to focus on intent (which I think is a reasonable goal) rather than details of implementation. If it works well for you to refuse to learn a preprocessor, then that is a good thing, but the fact that one makes my life easier doesn't necessarily imply that the designs I am implementing are overly complex, as your statement seems to imply (though perhaps I am misreading so...)
nicklovescode 13y ago
You seem to be saying the opposite of what the parent comment is.

rimantas 13y ago

> #container {display:flex;} > #foo {margin: auto;} or > display: table-cell; > vertical-align: middle; Where is the mess in these?

RaphiePS 13y ago
Imagine you didn't know anything about CSS and look at your examples. What the heck is margin, and why is it auto? Why would that center something? What are table cells doing in here? To me, it's just completely divorced from the actual meaning. At the risk of repeating my original comment, CSS poorly encapsulates the intent. Yes, it works and it's short, but it's sorta hacky, sorta circuitous. Instead of just telling the computer to center something, you're giving it detailed instructions, instructions it easily could (and thanks to GSS, can) figure out.

parksy 13y ago

I agree. In addition, with each year comes a new "super-duper-real-correct-semantic" way of doing it. That word semantic. It grates me. Everyone uses it to back their argument, then throws their hands up and "case closed". The meaning has been lost. Like now we have to: <div class="write"> <div class="write__our"> <div class="write__our__classes"> <div class="write__our__classes__like"> <div class="write__our__classes__like__this"> </div> </div> </div> </div> </div> <div class="instead"> <div class="of"> <div class="like"> <div class="this"> </div> </div> </div> </div> Which "old me" says is disgusting and breaks the rules of semanticism. The DOM loses meaning and becomes a vessel for the form / appearance. But I get why people do it. It's pragmatic. I don't like it, but it works. Regardless of the real real true real true way of doing things and all the arguments that people like to have about that, it's obvious why people are constantly trying to find these conventions and rules of thumb. It's because form and function are not properly separated with CSS alone. Using the DOM purely as a vehicle of function makes forming difficult, while pulling form into the DOM level muddies up the goal of semantic documents - the idea that a machine should be able to comprehend the nature of (X)HTML content has fallen to the wayside but that's a separate argument (should documents be sources of truth, isn't that what REST is for, are entities documents, etc). The thing is that XML & XSLT got us oh-so-close. Nice, lovely pure XML documents with clean semantic tags and attributes with strongly typed definitions that had meaning to both humans and machines. A transform step converted these into an XHTML presentation format, adding whatever DOM sugar was needed for the CSS and JS to do its thing. It was almost there. Where it fell down is where I think you hit the nail on the head. Both CSS and JS are needed currently to do very basic things, with a lot of overlap for things like positioning or animating transitions. A single layout language that handles _everything_ in an intuitive way without having to navigate the CSS+HTML+JS love triangle would be fantastic. Sorry for the somewhat longwinded response for what is otherwise a "me to" comment. I guess I just needed to vent a little - long day at the office and all :/