6 ms·

Interestingly they don't seem to have a rule against one line declarations. I alwats use this style, which imho is very handy, because of the tree structure an

Interestingly they don't seem to have a rule against one line declarations. I alwats use this style, which imho is very handy, because of the tree structure and admittedly because I have a super cool macro in Vim that copies the characters from the line above, word by word so create rules that afect children of the rule above it requires just a few keystrokes: #some-div { margin:1em 0; } #some-div .inner { padding:5px 10px; } #some-div .inner p { font-size:90%; } This makes the structure of the declarations more obvious imho, and I tend to have a nicely organized series of structures like that that are logically grouped together. Obviously this applies more to components/widgets than the basic rules and layout. If a declaration is long then I use newlines.. but even then I tend to group things together eg. #some-div { display:inline; margin: ...; padding: ...; border-radius: ...; border-color: ...; font-size:90%; text-align:center; } Basically within a css rule I'll group together the layout properties, the text properties, etc.

teach 10y ago
I'm very interested in that vim macro.
- johndoe4589 10y ago
  Sure. This is one of the most useful macros I found online :) I'd love to link to the original page but I can't remember where it is from. Here it is: " Piece-wise copying of the line above the current one :imap <C-L> @@@<ESC>hhkywjl?@@@<CR>P/@@@<CR>3s
ebbv 10y ago
The first example is fine, if you're only setting one property then doing it in a single line isn't a big deal. Your second CSS example is no bueno. Don't put multiple properties on a single line. It might make sense to you to put display and margin and padding on a single line but it might not make sense to me. These should all be on separate lines, it's not worth "saving lines" to make your CSS harder to parse for someone who doesn't already know that you like to group X, Y and Z properties.
- johndoe4589 10y ago
  Well that is the whole point, I wish I made the example better. How is it harder to parse? Putting everything in separate lines make the CSS file 10 times longer, and it's more difficult to see groups of rules that fit together along with their common structure. Nowadays unless you edit on a tablet your text editor probably handles 120 columns or more. But I really can't see the argument for readability. When I navigate a stylesheet for a website I'm working on, I want to see the larger structure. I don't need to see clearly the properties within a single rule. I want to see from top down. Still, this could be argued forever. Apples and bananas :) I guess it's the same discussion as space vs tabs, or 2 space vs 4 spaces. Here's a better example from one project which used YUI2 (it's old, but I think it shows my point of view, that the dtk-skin-dlg structure is very obvious along with the hd/bd/ft structure YUI 2 uses and the styles applied to them, that's the structure I want to see readily when I work in a stylesheet without having to scroll to understand it's all connected together): /* dialog body */ .dtk-skin-dlg .yui-panel { outline:none; } .dtk-skin-dlg .yui-panel .hd { font:16px/1em Verdana, sans-serif; color:#ddd; padding:10px 10px 0; background:none; } .dtk-skin-dlg .yui-panel .bd { padding:10px 10px 10px; background:none; font-size:12px; line-height:19px; color:#000; } .dtk-skin-dlg .yui-panel .ft { padding:5px 10px 10px; background:none; font-size:12px; line-height:1.2em; color:#000; } /* dialog footers, right aligned */ .dtk-skin-dlg .ft-right { clear:both; width:100%; padding:5px 0 0; text-align:right; } /* left align buttons INSIDE ft-right */ .dtk-skin-dlg .ft-left { float:left; text-align:left; /*padding from ft-right*/ } /* dialog body wrapper for extra css styling */ .dtk-skin-dlg .body { background:#fff; padding:10px; border-radius:3px; box-shadow:0 1px 3px rgba(0,0,0,0.2) inset; } .dtk-mobl-dlg .body { background:#fff; padding:10px; }
  - ebbv 10y ago
    > Putting everything in separate lines make the CSS file 10 times longer, and it's more difficult to see groups of rules that fit together along with their common structure. You block them together just like we do with code. Good code doesn't put multiple statements on a line, good CSS doesn't either. File length means nothing, if someone's looking for a specific class there are tools to do that, saving a few lines and making the CSS harder to read and edit isn't worth it. The examples above are much more readable like this (margin added for illustration of grouping related properties): .dtk-skin-dlg .yui-panel .hd { font: 16px/1em Verdana, sans serif; color: #ddd; background: none; padding: 10px 10px 0; margin: auto; } Written that way, when someone finds that rule in the file they can easily parse the relevant property without having to scan a 200 character long line.
combatentropy 10y ago
I like to put many attributes on one line too. It fills the page better, making it easier for me to take in: 80 characters wide by 50 lines long, instead of 20 characters wide by 200 lines long.
- johndoe4589 10y ago
  Agree, this is one of the reasons going for it. Unless someone works on mobile or some small laptop, the text editor should display 120 columns or more easily. And I'm not writing a git commit message, I'm writing css rules. Besides I like that it also gives me a better sense of how verbose some of the rules are and if some of the properties could be removed entirely. When the hierarchy of those rules is more apparent with the more compact style, I'm more likely to see unnecessary properties (which are inherited) and therefore trim up the code.

teach 10y ago

I'm very interested in that vim macro.

johndoe4589 10y ago
Sure. This is one of the most useful macros I found online :) I'd love to link to the original page but I can't remember where it is from. Here it is: " Piece-wise copying of the line above the current one :imap <C-L> @@@<ESC>hhkywjl?@@@<CR>P/@@@<CR>3s

ebbv 10y ago

The first example is fine, if you're only setting one property then doing it in a single line isn't a big deal. Your second CSS example is no bueno. Don't put multiple properties on a single line. It might make sense to you to put display and margin and padding on a single line but it might not make sense to me. These should all be on separate lines, it's not worth "saving lines" to make your CSS harder to parse for someone who doesn't already know that you like to group X, Y and Z properties.

johndoe4589 10y ago
Well that is the whole point, I wish I made the example better. How is it harder to parse? Putting everything in separate lines make the CSS file 10 times longer, and it's more difficult to see groups of rules that fit together along with their common structure. Nowadays unless you edit on a tablet your text editor probably handles 120 columns or more. But I really can't see the argument for readability. When I navigate a stylesheet for a website I'm working on, I want to see the larger structure. I don't need to see clearly the properties within a single rule. I want to see from top down. Still, this could be argued forever. Apples and bananas :) I guess it's the same discussion as space vs tabs, or 2 space vs 4 spaces. Here's a better example from one project which used YUI2 (it's old, but I think it shows my point of view, that the dtk-skin-dlg structure is very obvious along with the hd/bd/ft structure YUI 2 uses and the styles applied to them, that's the structure I want to see readily when I work in a stylesheet without having to scroll to understand it's all connected together): /* dialog body */ .dtk-skin-dlg .yui-panel { outline:none; } .dtk-skin-dlg .yui-panel .hd { font:16px/1em Verdana, sans-serif; color:#ddd; padding:10px 10px 0; background:none; } .dtk-skin-dlg .yui-panel .bd { padding:10px 10px 10px; background:none; font-size:12px; line-height:19px; color:#000; } .dtk-skin-dlg .yui-panel .ft { padding:5px 10px 10px; background:none; font-size:12px; line-height:1.2em; color:#000; } /* dialog footers, right aligned */ .dtk-skin-dlg .ft-right { clear:both; width:100%; padding:5px 0 0; text-align:right; } /* left align buttons INSIDE ft-right */ .dtk-skin-dlg .ft-left { float:left; text-align:left; /*padding from ft-right*/ } /* dialog body wrapper for extra css styling */ .dtk-skin-dlg .body { background:#fff; padding:10px; border-radius:3px; box-shadow:0 1px 3px rgba(0,0,0,0.2) inset; } .dtk-mobl-dlg .body { background:#fff; padding:10px; }
- ebbv 10y ago
  > Putting everything in separate lines make the CSS file 10 times longer, and it's more difficult to see groups of rules that fit together along with their common structure. You block them together just like we do with code. Good code doesn't put multiple statements on a line, good CSS doesn't either. File length means nothing, if someone's looking for a specific class there are tools to do that, saving a few lines and making the CSS harder to read and edit isn't worth it. The examples above are much more readable like this (margin added for illustration of grouping related properties): .dtk-skin-dlg .yui-panel .hd { font: 16px/1em Verdana, sans serif; color: #ddd; background: none; padding: 10px 10px 0; margin: auto; } Written that way, when someone finds that rule in the file they can easily parse the relevant property without having to scan a 200 character long line.

combatentropy 10y ago

I like to put many attributes on one line too. It fills the page better, making it easier for me to take in: 80 characters wide by 50 lines long, instead of 20 characters wide by 200 lines long.

johndoe4589 10y ago
Agree, this is one of the reasons going for it. Unless someone works on mobile or some small laptop, the text editor should display 120 columns or more easily. And I'm not writing a git commit message, I'm writing css rules. Besides I like that it also gives me a better sense of how verbose some of the rules are and if some of the properties could be removed entirely. When the hierarchy of those rules is more apparent with the more compact style, I'm more likely to see unnecessary properties (which are inherited) and therefore trim up the code.