Yeah, cool! Multiple files are ridiculous alright, I’m not going to do that. ;)
Regarding vendor prefixes, I was thinking about including prefix-free http://leaverou.github.com/prefixfree/ (basically removes the need to put prefixed properties in, as this thing will do it on runtime. But I decided against it because there are not super-many places with prefixes, and this will probably impede loading speed. When there is a declaration which needs a bunch of prefixes, all those attributes are going to be on one line. So yeah, I’ll check it out in the next days. It will be a gradual improvement also – I want to reduce the selector length a bit also, but in this first step I’ll do 0 code changes and only move around to not break anything. On Sat, Aug 11, 2012 at 5:54 AM, Bernhard Posselt <[email protected]> wrote: > I think the idea is good. The readability doesn't suffer from 2-3 > properties per line. Then again think about browser prefixes :D. > > I like the grouping by relevance, just dont split it into multiple > files. IIRC phpbb did that some years ago, e.g. one file for colors, one > for position etc. and it was a huge pain to develop and debug, since you > had to open 3-4 css files for the same elemnent. > > Maybe it would be best to say: stick to one line and when it goes over > 80 characters, use multiline. > > On 08/11/2012 02:02 PM, Jan-Christoph Borchardt wrote: >> True story. This was good in the beginning, but as the CSS grows >> bigger and bigger and more people work on it, it stops scaling. I’ll >> go through the CSS files the next days and clean it up. >> >> I’ll not do pure one-line-per-attribute though but rather a mix, as >> one-attribute per-line is a pain for scannability of selectors. >> Instead of alphabetic sorting (which makes 0 sense), attributes will >> be grouped by relevance. One row for position-related things, one row >> for typeface, one row for colors, one row for additional. >> If there are only one or a few attributes in the selector, it will >> still be single-line though. >> >> Also, the selectors will be indented to visualize their relation a bit >> better. >> >> >> >> Let me know what you think. >> >> >> >> On Sat, Aug 11, 2012 at 3:05 AM, Bernhard Posselt <[email protected]> >> wrote: >>> Hi, >>> >>> I've just started to dig into some app developement and i came across >>> this code styling rule: >>> >>> * CSS in single-line notation >>> >>> I normally don't have anything against coding style guidelines but I >>> think this one really hurts readability, as it requires you to not only >>> scroll vertically but also horizontally. Further problems are: >>> >>> * Less readability for single CSS statements >>> * Unreadable diffs (git shows that the whole line has been replaced, >>> instead of a single statement) >>> * Looong lines if you go for CSS prefixes, especially animations >>> * Harder to add new statements to a CSS rule >>> >>> The only advantage is that you can quickly scan for certain rules, but >>> to be honest, this should be provided by your Editor/IDE (Theres >>> normally a symbol browser that also works for CSS rules like >>> http://www.micahcarrick.com/mc_images/screenshots/gedit/gedit.png) >>> >>> To provide further arguments: >>> http://www.robbiemanson.com/articles/reasons-to-avoid-single-line-css/ >>> http://neutroncreations.com/blog/single-line-vs-multi-line-css-plus-textmate-tips/ >>> >>> Also take a look at: >>> http://www.python.org/dev/peps/pep-0008/#maximum-line-length >>> >>> I usually style my CSS like this: >>> https://github.com/Raydiation/oberthmedia/blob/master/oberthmedia/homepage/static/homepage/style/style.css >>> but I'm not sure if its the best method :P. >>> >>> regards >>> >>> Bernhard Posselt >>> >>> _______________________________________________ >>> Owncloud mailing list >>> [email protected] >>> https://mail.kde.org/mailman/listinfo/owncloud > _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
