Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CSS properties order #4

Open
azevedo opened this issue Apr 7, 2015 · 30 comments
Open

CSS properties order #4

azevedo opened this issue Apr 7, 2015 · 30 comments
Labels
enhancement question

Comments

@azevedo
Copy link
Contributor

azevedo commented Apr 7, 2015

This has already been talked about. It was an issue in this repo as well but got deleted probably when this repo stopped being a fork.

It has a trello card.

@gabrielpoca and I still believe this could have a revamp even in the actual properties order which might be "outdated" and missing some properties like those from the flexbox module.
The reasons are stated in the trello card, but for us the main reason for not liking the current order (alphabetical) is because it's not logical, even though it's an alphabetical order it feels random. It doesn't translate the "semanticness" of a ruleset.
@gabrielpoca
Copy link
Member

I normally don't write the rules in alphabetical order, I usually write the rules in blocks: flex rules, height width rules, color rules, etc. I write the rules that are related at the same time. And then I run a function to sort by alphabetical order, to match the current guides.

I believe we should at least give this a try in one project.

@gabrielpoca
Copy link
Member

@groupbuddies/developers we'll need everyone's feedback on this.

@zamith
Copy link
Member

zamith commented Apr 8, 2015

What has changed since the conclusions in the trello card? Only flexbox, or is there any new argument for or against this ordering?

@naps62
Copy link
Member

naps62 commented Apr 8, 2015

I agree that semantically ordering is better than alphabetical ordering. I also don't think my opinion has changed that much since we last discussed this

Did this fail just due to not getting updates, or was there any other reason for giving up at the time?

@gabrielpoca
Copy link
Member

I think it's safe to say that a lot has changed since last time. At least some people did even more investigation, and in general, almost everyone did level up on css.

Previously the rule was discarded because @ronaldofs said he already tried this and there was no point in doing it. But a lot has improved on our way of doing css since then. And there are a lot more arguments for this improvement. I hope everyone thinks for a while, before rejecting this improvement. I don't think an argument is necessary if all of us look at the way we program in other languages and apply the same rules to css.

@zamith
Copy link
Member

zamith commented Apr 8, 2015

What new arguments are there?

@gabrielpoca
Copy link
Member

I would rather know everyone's opinion on this first. I already know that me, @azevedo-252 and @naps62 agree with this improvement, what about @ronaldofs and @joaojusto ?

@joaojusto
Copy link
Contributor

I would like to try this in one project to. It may seem strange and I recognize that will take a bit of time and effort to get it right but it makes more sense than the alphabetical order.

@ronaldofs
Copy link

I believe this is only a matter of style, not an improvement. But I don't want to be the only opposition on this if you know it's the best way to do that (whatever 'best' means).
Is there a script/macro/whatever to do this automatically?

Side note:
@azevedo-252: if I open some recent project you work on with that kind of organization, the css files does feel random. Also don't understand what you mean with "semanticness of a ruleset" since the final order will have to be decided and doesn't appear naturally. Also, "logical", as you say, will be the logic defined by you/someone and that makes the "logic" lose it's meaning since it should be deductive reasoning.
I would assume that, by now, enough time had passed to generate some concrete conclusions... Or at least solid arguments.

@gabrielpoca
Copy link
Member

@ronaldofs how do you organize your methods in a class?

@ronaldofs
Copy link

@gabrielpoca usually: public then private; init and constructors on top; and organized by usage (not having methods call methods yet to be defined).
That isn't that comparable... How do you organize settings on config files? What about on <head>, what order you use?

@ronaldofs
Copy link

But hey, I said I don't mind to order css props with a chosen and defined order. Let's do it.
I was just pointing out that the arguments presented bare no value whatsoever and that there were no updates on the old discussion.

@ronaldofs
Copy link

Quoting idiomatic-css "Larger teams may prefer the simplicity and ease-of-maintenance that comes with alphabetical ordering.", are there opinions on this sentence?
Also there's this: https://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml#Declaration_Order

@gabrielpoca
Copy link
Member

Do you consider css to be more like a config file instead of a programming language?

@ronaldofs
Copy link

I consider it more as "config" than "real programming".
What about the rest of my arguments which refute the premise stating this kind of ordering is an "improvement"?

@azevedo
Copy link
Contributor Author

azevedo commented Apr 8, 2015

Before anything else, I still haven't updated anything on the trello card, I just reopened this issue in order to generate discussion. The refactor still needs to happen.

@naps62 it failed due to a mix or "forgetness" and not having a clear unanimous approval.

@ronaldofs "I believe this is only a matter of style"
I cannot agree with this. I do not treat a ruleset as a bag of unrelated rules that happen to render what I want, in that particular circumstance. There's a whole set of principles and best practices that guide what rules I insert and why. So a particular order (or grouping) that reflects purpose is necessary, for me at least.
I can't say I'm deducting things from a bunch of rules which are simply "flattened" under a selector.

The ordering between related groups, indeed is "decided" by us and may look random (even though it has a logic, which I still need to write down, sorry about that). Nevertheless, the actual property grouping cannot be labeled as random since it represents some semantic function on the browser. That, I find hard to reason against, since I see no profit in seeing a layout rule followed by a coloring rule and then another layout rule. It's an attempt on a separation of concerns.
Rules and patterns enforced by an architecture help separating these concerns and give meaning to things even further because you're not supposed to be mixing structure with skin for instance. But this is another conversation.

Anyway I would strive for at least having some well defined property groupings (the inner ordering may be alphabetical or some other logic we're comfortable with, eg: some logic that the W3c specs may have defined, some personal preference, ...).

In another note, it is possible and will probably be my next "endeavor" having a tool and/or some sort of linter for ordering/warning about these sorting errors.

@ronaldofs
Copy link

@azevedo-252 The problem I have with the approach is the overhead of conforming to a non-obvious organization. You need to think how to order every time you'd write new declarations.
It is simply not true that in practice you have a lot of declarations inside a selector, which makes irrelevant how you group them when you're trying to reason about it. (Short-term memory can hold ~7 items at once, probably enough for you to memorize all declarations on the selector.)
On the other hand, alphabetic ordering is commonplace. So writing and ordering is effortless.
My goal here is performance and from my view your approach doesn't really improve anything. It seems more a philosophical stand point ("ruleset as a bag of unrelated rules", "you're not supposed to be mixing structure with skin") than trying to make our work more effective.

@ronaldofs
Copy link

For me, it's the same as if you said something like:
"Hey, we shouldn't be racist when naming variables!"
Sure, it would be a nicety... but do we really want it?
😄

@gabrielpoca
Copy link
Member

Why do you think is necessary to order methods and variables and everything, but css is just a bag of things? I get the feeling you're not thinking this through. Or at least not really writing enough css to feel the pain or to recognize the patterns in the way you write css. Maybe we need to agree first if css if a configuration file or a programming language?

@azevedo
Copy link
Contributor Author

azevedo commented Apr 8, 2015

@gabrielpoca that's even more philosophical :D
@ronaldofs I can agree with the goals you've said. But I do couple together being productive and having things being written in a more structured way (in the way we've been speaking; i.e. excluding alphabetical order). After all you spend more time reading code than writing it.
I do agree that a tool that lessens the effort of inserting new rules is necessary. But when we're speaking about reading CSS, there's no way I can deduct things more efficiently from an alphabetical order than from an expected one.

I do understand this is only a problem for some because we look at what CSS is differently.

Right now I'm trying to collect more logical (spec wise) reasons for grouping certain properties... Hope it will be useful for making things easier to grasp

@zamith
Copy link
Member

zamith commented Apr 8, 2015

Do you have any specific order for variables in let's say a constructor? I don't. Or when I do it's alphabetical, because it just doesn't matter and it's easier this way.

What I do, is try to follow SRP (especially) and other patterns, so that everything that's there is related to a single purpose and thus making the order irrelevant.

As for methods, they are organized in a way they should be read, if they call each other, if they don't interact with each other, the order has no relevance.

In terms of CSS I agree with @azevedo-252 that we should try to follow SRP, with componentization, Sass variables and the such. So, as much as possible separate layout from coloring, for example, thus making the number of rules per selector so small that the order is (debatably) irrelevant.

In sum, having little methods and classes make the order pretty much irrelevant in my experience with most programming language. With CSS I believe the same applies if we have small components and selectors.

@ronaldofs
Copy link

@gabrielpoca for me it's more config/stylesheet than algorithmic/programming
@azevedo-252 if you could demonstrate the benefits, I would surrender to it. Promise! Do you have examples where you've applied this extensively so I can have a look?
@zamith also agree on components (but not sure how that would look like in practice)

@zamith
Copy link
Member

zamith commented Apr 8, 2015

@ronaldofs (link removed, blue pen)

@gabrielpoca
Copy link
Member

Your public methods go on top, private on bottom.
Instance variables in one place, class variables in other.
Empty line separating each phase of the test (context, action, expectation)

The only thing this rules have in common is that they improve readability. You had to learn the rules. They don't come naturally. Why do you consider that these rules are necessary, but css properties can go alphabetical, when you normally write related properties at the same time?

@ronaldofs
Copy link

@zamith I was referring to components with separate layout from aspect.

@zamith
Copy link
Member

zamith commented Apr 8, 2015

Public methods go on top and private on the bottom in ruby, because after the private keyword everything is private. On other languages I don't always follow that rule, because it is not necessary.

Instance variables and class variables most likely will have to be defined in different places or else it won't work.

And as for empty lines to improve readability we also do that in CSS.

As @ronaldofs has stated, I don't really see this as an improvement, as much as a style change. And I haven't experienced this order to be more readable. Actually, if we don't have more than 6 or 7 rules per selector (which is pretty much what we have), I think order has no effect on readability at all.

This is obviously my opinion, but if we do agree in an order, whatever it may be, I intend to follow it in every project (unless experimenting something well documented on the research board). That for me is the most important thing. Much more important than this ordering issue.

@naps62
Copy link
Member

naps62 commented Apr 8, 2015

@zamith yes, I do try to group instance variables declarations according to their responsibility, or context. In ruby that doesn't apply too much, since we don't declare them, but a simple example that is language agnostic is this:

// alphabetical order
class Foo {
  var height;
  var scale;
  var width;
}

vs

// "semantic" order
class Foo {
  var width;
  var height;
  var scale;
}

Width and Height are two things that go together like bread and butter, so seeing a scale declaration in between makes it confusing to me. If I see a height, but not a width right next to it, my first assumption is that there is no width at all in this class. I think this is the same principle

Is there a strict, definable order for how we would declare them? I don't think so. But for me, alphabetical and random are pretty much the same here

SRP is a good principle, but it can only go so far. And saying that with SRP makes the order irrelevant is an exaggeration, IMO

@zamith
Copy link
Member

zamith commented Apr 8, 2015

@naps62 I get your point, but I think your example is a bit biased, because there are some attributes that are usually coupled to each other, such as height and width or positionX and positionY. So much that it could be argued that they belong in their own class, maybe Dimensions or Point2D.

Generally speaking, I do think order does not really matter.

As for CSS, those are the two rules I think have a stronger gravitational pull to be together. Most of the others I understand that they have some relation, like display and float, but saying that it is more readable to have them together feels to me like a bit of a stretch. Again, that's my opinion from my personal experience.

@ronaldofs
Copy link

@naps62 I agree and I believe everyone does the same. Those guidelines are pretty much standard for "good development". It's a pain having to work/move/refactor related variables that are set apart from each other. I feel no pain trying to grasp alphabetically ordered style declarations. I would feel pain having to keep a specific order of groups of properties.

Actually, I can give a similar case: @gabrielpoca asked me why I aligned variable initialization or key/value pairs as it was extra work for no gain (I thought it improved readability) ... and indeed I was wasting my time. So I stopped worrying and now I'm happier 😃

// Align example
var abc = 1;
var d   = 2;

@azevedo
Copy link
Contributor Author

azevedo commented Apr 8, 2015

@ronaldofs You can find a lot of examples in our easyPaperRebelz repo. If i'm not wrong there isn't a component that mixes structure with skin (unless it has some well defined reason), much less a single class (if you don't care about the notion of component).
Take for instance the Grid component, it has no knowledge of what its content can be, for that reason it only lays out things, i.e. no skin properties. The same for CardGrid which is a little bit more custom made, but still doesn't have skin. Other layout components: MainContent, SideContent, HelpContent.
On the other hand, components like CurrencyCard, Input, Modal are components that exist independent of where they are used, so mainly they have coloring and box properties only to effect the inner elements, not the outside.

Other than that, having too many properties under a class is usually a bad sign. But when/if you do have I can't say that the order is irrelevant. It's a matter of how you organize things in your head and seeing unrelated things together does make you make wrong assumptions.

I'm still trying to figure out arguments that can convince you but it's getting harder. As I write this I thought of another one:
When I'm authoring a new component and I have its responsibilities in mind, I start writing rules thinking about the actual effects the properties have in the browser, which happen in logical groups (not sure this is the right expression), not in an alphabetical.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@zamith @naps62 @ronaldofs @azevedo @gabrielpoca @joaojusto