[HN Gopher] Ordering CSS Declarations
___________________________________________________________________
Ordering CSS Declarations
Author : sysadm1n
Score : 21 points
Date : 2022-05-04 12:42 UTC (1 days ago)
(HTM) web link (blog.jim-nielsen.com)
(TXT) w3m dump (blog.jim-nielsen.com)
| gherkinnn wrote:
| If you can't automate it, don't bother. Fussing with enforced
| ordering costs me more than it gives in return. And I prefer
| rough grouping of related declarations anyway.
| draw_down wrote:
| nathias wrote:
| CSS is ordered by definition, it's cascading so that's how it
| should read in order of speciticity
| jamal-kumar wrote:
| I mean yeah, that's how the rules work... that's the cascading
| part, the fact that it's ordered in a cascading manner is right
| in the name of the language.
|
| Alphabetical ordering sounds hilarious
| somishere wrote:
| Yet, if you take a closer look at the language you'll see that
| it doesn't just work but is also a practical method for
| debugging, consistency, and working with larger teams.
|
| Where it would be hilarious is at a selector level. lol. [edit]
| (that is, unless you follow a bem-like methodology. non-lol.)
| caseyross wrote:
| I started using alphabetic ordering for CSS some time back, and
| have found it much easier and more reliable than trying to keep
| CSS organized by importance / relevance / semantic content.
|
| One correction to the article I want to make is that
| shorthand/longhand properties are more naturally alphabetized by
| placing the shorthand property first (rather than the opposite,
| as suggested by the author), so overriding them shouldn't ever be
| a problem.
| somishere wrote:
| Completely agree. Apologies I made a separate comment re. the
| short/longhand concern. I wonder if this is an IDE specific
| issue or is the author referring to manually ordering?
| lelandfe wrote:
| I've seen places order only box model properties (first
| height/width, then padding, then border, etc, then everything
| else), order by responsibility (first fonts, then box model,
| etc)...
|
| Here's what that gave us: crummy PR reviewers get a silly thing
| to complain about, developers get an extra thing to think about
|
| Here's what that didn't give us: any reduction in bugs, any
| meaningful improvement in code legibility
|
| I'm firmly in the camp of "order properties as needed."
| micromacrofoot wrote:
| yeah it's pure pedantry, the worst thing to introduce to pr
| reviews
| ramesh31 wrote:
| >Here's what that gave us: crummy PR reviewers get a silly
| thing to complain about, developers get an extra thing to think
| about
|
| Exact same experience working on a team that had this as a
| standard. It's absolute nonsense. It can be enforced with CSS
| linting at this point... but why? Never in my decade of writing
| CSS have I ever ever wished that the declarations in a codebase
| were alphabetically sorted for any reason. If your class
| declarations are that large in the first place, you should be
| breaking things down better.
| somishere wrote:
| Completely agree with the sentiment here that property
| declaration order matters (and automation is not ideal). That
| said, none of the examples ring true for me personally. The
| author correctly debunks the vendor prefixes (tooling) and
| duplicate declarations (debugging) non-issues, however they
| appear to hold firm on the short / long hand natural sort order
| conclusion. At least in sublime text, hitting f5 to alpha-sort
| CSS results in the longhand properties correctly appearing after
| their shorthand versions. Needless to say, unless I'm being lazy
| (often), alpha sort is not just a pedantic feature in my
| stylesheets but a practical one too.
| fiddlerwoaroof wrote:
| One aspect of this is that, if your codebase has a consistent
| ordering rule like "alphabetical", then you can be confident that
| deviations from the rule are intentional. If your codebase is
| inconsistent, you can never be sure whether a particular ordering
| represents an important edge case or is just careless
| liquidise wrote:
| I order my declarations and have for years. Like many
| personalized code styles, are much easier to maintain on
| codebases you fly solo in.
|
| My ordering is by my mental model of "impact" of the declaration.
| Generally: Display -> Position -> Box Model -> Text/Font ->
| Background -> Misc. /* Example from css file i
| have open */ .officeBlock .email { display: inline-
| block; padding: 14px 10px 8px; background-color:
| #E0EFFE; border-radius: 50%; transition: 0.25s
| ease-out; }
|
| Subjectively i think it is a big help quickly understanding style
| blocks, particularly complex ones. Is the time investment a net
| positive? Possibly, I'd wager so. I'd suggest it is worth trying
| on a project to see if it helps when you return to it months
| later, at least.
| account-5 wrote:
| I'm learning html/CSS/JavaScript and as a novice I started
| ordering my CSS by appearance in the html.
| oneeyedpigeon wrote:
| This is more about ordering individual declarations within a
| block rather than blocks themselves.
___________________________________________________________________
(page generated 2022-05-05 23:00 UTC)