Alphabetized Selector Order

[MarioRicalde]

I've read the whole document, and I agree with everything you say, however there's one thing that I would really like to bring up:

Sorted Definition Order makes a lot of sense. I've been doing this for some time and it works.

However, I'm really not convinced of the sorted selectors. It just goes completely against CSS ( Cascading ). I know cascade can be bad and become into a nightmare if you do it wrong. And that sorting makes it look better, but I think overdoing it is a just a overkill.

I reckon that having @mixins and %placeholders at the top and sorted since they don't matter how you place them on the file.

[dfischer]

I'm happy to work with you on this.

Here's the main reason I tout this: expectation.

In order to create a maintainable stylesheet layer, you need consistency and expectation. We really depend on this as front-end developers.

Ok, so bringing expectation and consistency into play, when you have the expectation you will always know where a certain definition or selector is in the document related to the name is helpful. No?

What are the downsides? I understand that it limits the ability to overwrite the cascade, but can you show me an example where it's detrimental?

Let's put both examples in Debates

[MarioRicalde]

Awesome!

I understand that expectation is something that sounds good. But do we really need to sacrifice the main thing about css? cascade? Do we live in in a point of time when we need to scroll to find out selectors?

Aren't editors helping us with that already ?

Also, how can you be sure that a user won't be expecting to have some sort of control over the order of the definitions? Look through many projects and you'll see some kind of pattern and reasoning on keeping some definitions next to each other ( this also happens on the back-end ).

Here two really superfluous examples:

With the rule applied:

http://jsfiddle.net/qFWLL/

Without it and using the cascade:

http://jsfiddle.net/qFWLL/1/

[dfischer]

I see what you're saying. To that I say, why not do this?

http://jsfiddle.net/hgpUH/2/

I know it removes a level of the cascade, but the point is to also reduce the errors of unexpected cascades.

Through sass, if you wanted all error's to share a common style, you can @extend from an error placeholder attribute or do a mixin.

I think this creates a best practice that is more maintainable. No?

[MarioRicalde]

I agree with using @extend, but it's not something you should be using always. Relying on the cascade is not a taboo. I understand that having the code all beautifully sorted sounds good, but I'm not sure it's worth the effort. Especially with all the text editors out there that can do that for you.

I can keep on going on giving examples of use cases where relying on the cascade is better than using @extends like a mandatory rule to overcome having to sort selectors alphabetically, but I reckon I'll not do that since I'm a bit busy lately.

Maybe someone else can give some feedback.

I put my case to rest.

Cheers.

[dfischer]

Ok, I'll get some more feedback on this through the community.

Perhaps you can prove it to me otherwise with the "Especially with all the text editors out there that can do that for you."

Can you explain this to me? Perhaps I can leverage that as the alternative best-practice.

[MarioRicalde]

Sounds good to me!

What I meant with that was that for instance, if you're searching for a class you can use incremental search to reach it, for it with a simple command / key combo. You don't go on scrolling through the whole file reading the contents and figuring out where it is.

[dfischer]

Yeah, that's true. I'll go with that. Closing for now.

Thanks!

[dfischer]

Actually, will re-open this until a commit is made.