Adds lost-column: none rule

[peterramsing]

This adds a rule to lost-column where when you pass none in, the lost-column is reset to browser defaults.

[alex-ketch]

I've been working with the fork that led to this feature, and it's great utility to have.
The issue that kept popping up for me is whether this should purely be a reset for lost-column: or if it should also reset lost-offset:, as I found myself setting it to zero every time I used lost-column: none.

Name wise, it makes sense that it doesn't touch the offset, but I can definitely see something like lost: reset living alongside `lost-column: none'.

[peterramsing]

@alex-ketch Was that my fork from a while ago before I took the main repo or did you make your own?

I'll look into having a lost: reset; rule and see what that might entail.

[alex-ketch]

@peterramsing I was using your fork from before you took over the main repo.

[peterramsing]

@alex-ketch Cool! I'll hopefully have 6.7.0 out shortly to hopefully integrate this. Feel free to chime in on #217 and share any thoughts there as well!

[corysimmons]

I know I said I liked none but the more I think about it, the more I like reset. We're "resetting" something. When I think of "none" I think of something like lost-column: 0/3 and I'm unsure of what that would do. When I think of "reset" I think "Oh, this is resetting what Lost did - probably back to browser defaults".

Just my 2 cents. Feel free not to worry about it as this isn't a huge deal or anything. What do you guys think before merging in this API?

[peterramsing]

I know unset was also tossed around. Let me dig through some W3C, MDN, and other grids to see if there is a trend.

[peterramsing]

I pondered this for a bit. What about adding two more values.

foo {
  lost-column: inherit;
}

The outputted CSS is:

foo {
  width: inherit;
}
foo:last-child {
  float: inherit;
  clear: inherit;
  margin-right: inherit;
  width: inherit;
}
foo:nth-child(n) {
  float: inherit;
  clear: inherit;
  margin-right: inherit;
  width: inherit;
}
foo:nth-child(1n + 1) {
  float: inherit;
  clear: inherit;
  margin-right: inherit;
  width: inherit;
}
foo:nth-child(1n) {
  float: inherit;
  clear: inherit;
  margin-right: inherit;
  width: inherit;
}

Then another to go back to W3C defaults.

foo {
  lost-column: reset;
}

The outputted CSS is:

foo {
  width: auto;
}
foo:last-child {
  float: none;
  clear: none;
  margin-right: 0;
  width: auto;
}
foo:nth-child(n) {
 float: none;
  clear: none;
  margin-right: 0;
  width: auto;
}
foo:nth-child(1n + 1) {
  float: none;
  clear: none;
  margin-right: 0;
  width: auto;
}
foo:nth-child(1n) {
  float: none;
  clear: none;
  margin-right: 0;
  width: auto;
}

@alex-ketch You've been using this in production. Do you have any thoughts? RE: your codebase, could you do a find a replace or do you think that also having a rule for "none" to retain some backwards compatibility would be a good idea?

---

The reasoning behind this thought process is to let the rules self document a bit better.

[peterramsing]

@iest I know you had some thoughts on this in #150. Got any further thoughts?

[corysimmons]

Why inherit?

[peterramsing]

@corysimmons Because it's a self documenting value. Plus it's not resetting it as much as it's telling it to inherit the rules of its parent. I'm not stuck on it, just like how it self documents.

[corysimmons]

I like how it self-documents too, but I don't see a need for it. Will there ever be a use case where someone might want to inherit all those particular values?

[iest]

My personal preference is for lost-column: none as it's more similar to how typical CSS overrides work. I don't think it'd cause confusion, just like border: none doesn't cause confusion.

Not sure on the use case for inherit, but I guess it makes sense to have?

Regardless of the syntax, I'd just be happy to see this feature in the library 👍

[corysimmons]

lost-column: rewind 💃

[peterramsing]

@corysimmons Don't tempt me with lost-column: rewind;. 😉

Per these comments I propose that it remains lost-column: none;. @iest is right: margin-left: reset; isn't a rule, however margin-left: none; is.

[alex-ketch]

lost-column: none makes the most sense to me, as the column reverts back to the default behaviour. Whereas lost-column: reset, as @corysimmons suggested, is a little misleading to me.
I would expect a reset to not only revert lost-column but remove lost-offset as well as other settings related to Lost Grid.
Currently I have to manually revert the settings as the layout I'm dealing with changes significantly across breakpoints.

@peterramsing I think backwards compatibility wise, find-and-replace as you suggested would easily suffice no matter the final term.

[peterramsing]

@alex-ketch, I think we commented right at the same time. Quite epic. Regarding lost-offset, do you think that this PR should address that as well? Do you have any proposals regarding that?

[alex-ketch]

@peterramsing My hesitation is that I don't want to muddle what lost-column targets. Instead a second PR adding a reset utility function of sorts that clears everything would be better in my opinion.

[peterramsing]

@alex-ketch I like that thought process. Maybe something for later, then for the "reset".

[peterramsing]

As I'm sifting through code right now ( #208 ) and see that there is a reset value for lost-align that reverts back to browser default. If we have a lot of different "reset" rules, we might consolidate these in the future (keeping backwards compatibility for a few versions at least). I'll keep a mental note of this.

[peterramsing]

I think this is good to merge pending any final issue with the rule being lost-column: none;.

[corysimmons]

👍

[corysimmons]

Cool. You might want to start deleting these branches as you merge. You can always git revert back to before they were merged and git cherry-pick ranges if you end up needing their code again. It just keeps the repo nice and clean.

[peterramsing]

@corysimmons Cool–yeah, I hadn't done that yet for this. It was late. Thanks for catching that. 😄

Now I'm starting to understand why other maintainers of active setup orgs to hold their repos so they can have forks of it where they code...

[zephraph]

And it allows you to group related repositories such as examples or independent add-ons. LostGrid is available, you should snag it.

[peterramsing]

@zephraph I grabbed it. For now I think I'll leave the repo under me as we just did a transition. Maybe with v7 it will move. So much to do, so little time.

[corysimmons]

I love the idea of an org.

If you name it something more abstract than LostGrid it'd be cool. Like these Sass dudes have https://github.com/at-import and have a pretty cool grid in it alongside a bunch of other cool stuff.

I might get a hair up my ass to make an insane themeable PostCSS UI kit one of these days.

Feel free to keep it in your name to rack up some resume points while you do free work though. :^)

I'm getting totally obsessed with Python for the time being.

[artisin]

I was looking at the tests and it appears that lost-column: none; creates a duplicate of the a:nth-child(1n) rule. Based on the code above it looks like that duplicate should be a a:nth-child(n) rule.

it('provides none rule', function() {
  check(
    'a { lost-column: none; }',
    'a { width: auto; }\n' +
    'a:last-child { float: none; clear: none; margin-right: 0; width: auto; }\n' +
    //duplicate, looking at the code above this should be `a:nth-child(n)` ???
    'a:nth-child(1n) { float: none; clear: none; margin-right: 0; width: auto; }\n' +
    'a:nth-child(1n + 1) { float: none; clear: none; margin-right: 0; width: auto; }\n' +
    //duplicate
    'a:nth-child(1n) { float: none; clear: none; margin-right: 0; width: auto; }'
  );
});

[peterramsing]

@artisin Hmm. Yes, that does look to be a duplicate. I'll create a new issue.