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.

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

Version 0.2.0 #79

Merged
merged 46 commits into from
May 13, 2014
Merged

Version 0.2.0 #79

merged 46 commits into from
May 13, 2014

Conversation

jescalan
Copy link
Member

This branch is for breaking changes that will push into the next release of axis, which I'd like to chase a little harder. I'll be working on making sure the code is clean, a bunch of our current issues are cleared out, and hopefully get started with integrating nib for the browser-level stuff now that it's being better maintained.

Also want to note that stylus is moving quickly toward a solution for having mixins accept blocks, which is super exciting and will allow us to quickly include responsive mixins and utilities. I'd love to have us be among the first to ship support for these.

Finally, was checking out this project the other day, and would love to offload the responsibility for keeping up with vendor properties to them. If there's a good way to get it integrated, I think this would be an excellent option.

Also, I'd like new changes and improvements to happen in this branch. I'm going to push a small release based on the last commit to master which will be the last upgrade to version 0.1.x (unless there are bugfixes) before we can release the next version.

I haven't been giving axis enough love recently, but this is an awesome library and deserves better. Let's get this bad boy up to speed, shiny and fresh as can be.

/cc @yoshuawuyts @declandewet

@zspecza
Copy link
Contributor

zspecza commented Sep 10, 2013

Definitely. Agreed on getting started with merging nib - I also had a look at the improvements to Stylus and they are exciting me!

@zspecza
Copy link
Contributor

zspecza commented Oct 15, 2013

Reading back on this and I think autoprefixer should belong in nib rather than Axis...

@jescalan
Copy link
Member Author

Perhaps @slang800 will weigh in on this. If it's moved to nib, I'll happily drop support from axis

@zspecza
Copy link
Contributor

zspecza commented Oct 16, 2013

Well, in this comment, he mentions he would like nib to be on top of the latest in Vendor prefixing. I had a look at Nib last night and it seems the project still uses mixins to handle vendor prefixing, and I did not see anything in nib's issues or pull requests regarding autoprefixer. I'm sure it'd allow @slang800 to focus on other things because it takes a lot off his plate what with the way it uses the Can I Use database (such a smart idea actually, why didn't we think of that? :P)

@notslang
Copy link
Contributor

Yeah, I'd love for autoprefixer to be integrated with nib... that would help remove a lot of the logic from nib. If you wanna send a PR for that, I'd totally support it.

@jescalan
Copy link
Member Author

Sure, it's super easy to integrate, I made this little plugin to make it even easier: https://github.com/jenius/autoprefixer-stylus

I'll have a PR sent in shortly

@jescalan
Copy link
Member Author

Ok so this branch is shaping up fast. We now have integrated with both autoprefixer and nib, which is awesome. As it stands, autoprefixer takes care of the vendor stuff, nib takes care of the basics, and axis' role is mostly to provide shortcut functions and UI/typography mixins. I'm happy with this role.

One idea that came up when chatting with @corysimmons was basing a UI library off bootstrap's components. I think this is definitely something worth discussing and considering here. Bootstrap already has a very solid library of components to start from. I don't agree with any other part of bootstrap really - both the markup and the way that classes are used to apply it are terrible in my opinion. But the components at a high level are solid, and obviously apply across a wide variety of sites. On top of that, bootstrap has dropped all the ugly styles and now has very base-bones components.

So what we could do is replace axis' random collection of ui components to mirror bootstrap's components, but have them implemented as mixins rather than classes, which would make them immensely cleaner and more powerful. It would also give axis a really nice base to start from, potential auto-integration with the js plugins, and immediate familiarity to a gigantic user-base.

Take a browse through their components page: http://getbootstrap.com/components/

Taking this a step further, many of these patterns also require certain general markup structure. In this case, life could be made easier for users by optionally providing view helpers that would produce matching markup structure with some of the mixins through jade, for example. This goes somewhat hand-in-hand with jescalan/roots#233

Would love to get opinions on this @declandewet @slang800 @yoshuawuyts @samccone

@samccone
Copy link

I am all about the proposed UI kit that @corysimmons is talking about, it seems pretty darn cool

@corysimmons
Copy link
Contributor

@samccone What UI kit?

@samccone
Copy link

that codepen

@yoshuawuyts
Copy link
Contributor

Woah, please don't. The naming of elements in Bootstrap is awful, and is not something we should further build upon. There are other options, such as semantic UI, but imho they're not that much better (e.g. the class for a button is div.button rather than just button). Why not build a nice set of commonly used elements rather than trying to mimic the monolithic beast called bootstrap.

@jescalan
Copy link
Member Author

Maybe you didn't get all the way through what I wrote, but I was not suggesting emulating the classes, I only suggested emulating the components at a high level. Everything would be done through mixins. I think it would be easy to make things more semantic once we drop the ugly classes and such.

@yoshuawuyts
Copy link
Contributor

Oh, ok! I just assumed that if you wanted auto integration with the js plugins that the elements / classes would have to be named equally, even though they were implemented as mixins.

@corysimmons
Copy link
Contributor

@samccone What codepen? :[

@samccone
Copy link

@corysimmons
Copy link
Contributor

I am all about the proposed UI kit that @slang800 is talking about, it seems pretty darn cool

Ah, sorry, you wrote @slang800 :)

@samccone
Copy link

oh HAHAHAHA

@corysimmons
Copy link
Contributor

It's slow going because I have to make sure everything is exactly right but I'm certain it'll be huge. I'll try to get it done before I move up there so I have something to show the guys at Artifact Conf.

Good luck with your Bootstrap port Jeff.

@corysimmons
Copy link
Contributor

Seriously @Jenius why not just use one of the Stylus Bootstrap ports out there right now and just convert all the classes to placeholders? It'd be better for smaller CSS and would save you a ton of work as you'd just have to do something like:

// https://github.com/Acquisio/bootstrap-stylus/blob/master/stylus/buttons.styl

.btn {
  display: inline-block;
  padding: $padding-base-vertical $padding-base-horizontal;
  margin-bottom: 0; // For input.btn
  font-size: $font-size-base;
  font-weight: $btn-font-weight;
  line-height: $line-height-base;
  text-align: center;
  vertical-align: middle;
  cursor: pointer;
  border: 1px solid transparent;
  border-radius: $border-radius-base;
  white-space: nowrap;
  user-select(none);

  &:focus {
    tab-focus();
  }

  &:hover,
  &:focus {
    color: $btn-default-color;
    text-decoration: none;
  }

  &:active,
  &.active {
    outline: 0;
    background-image: none;
    box-shadow inset 0 3px 5px rgba(0,0,0,.125);
  }

  &.disabled,
  &[disabled],
  fieldset[disabled] & {
    cursor: not-allowed;
    pointer-events: none; // Future-proof disabling of clicks
    opacity(.65);
    box-shadow none;
  }

}

.btn-primary {
  button-variant($btn-primary-color, $btn-primary-bg, $btn-primary-border);
}

// Placeholder it
$btn
  @extend .btn
$btn-primary
  @extend .btn-primary

// Usage
button
  @extend $btn, $btn-primary

Then just make a palette.styl file where $btn-default-color and such would go so people could customize colors from one spot.

This would make smaller .css and leave it open for people to actually use classes if they wanted the JS stuff Bootstrap offers.

@jescalan
Copy link
Member Author

Eh, I hate the classes with a passion. I really don't ever want to promote using classes for styles over mixins.

@corysimmons
Copy link
Contributor

Usage would be very mixin-like (don't need to clutter markup with presentational classes) and outputted css would be smaller.

button
  @extend $btn, $btn-primary

Are you just converting this stuff into mixins so you can pass colors on the fly rather than in a palette.styl file? I'm just not sure what the advantage to using mixins in this situation is other than that and the placeholder thing would save you a ton of time porting this.

Either way, it's up to you. If you have a good reason to do it with mixins (other than on-the-fly color) then that's cool and I'm sure it'll be intuitive. I was just throwing this out there.

@samccone
Copy link

@Jenius semantic classes do make plenty of sense in many cases

@corysimmons
Copy link
Contributor

@samccone I think @Jenius is right in not polluting markup with presentational classes but the placeholder thing avoids that completely. The only time you'd need the classes in markup is for JS. The only question is, why turn them into mixins rather than placeholders? What extra functionality will mixins serve in this case? I'm genuinely asking because I can't see anything in Bootstrap that could have extra functionality added to it other than button colors.

@jescalan
Copy link
Member Author

Because mixins can take options and placeholders can not. This would allow people to customize the way the components look smoothly. For example, instead of .btn .btn-red .btn-large it would be btn(red, large). This is almost exactly how axis works already, I'm just proposing building out the UI section by mirroring the bootstrap components at a high level, since they have a very widely used and vetted library.

@corysimmons
Copy link
Contributor

Ok, I understand that. It'll look/feel better. If possible, try to use placeholders within the mixins though for the compiled css benefits. If it's a pain in the ass, no worries. Excited to play with this when you're done and I think it'll be a pretty big thing in the Stylus world as a whole. Is this Axis or are you gonna put it in it's own repo and just import to Axis?

If the latter, I might use this in Jeet as a bandage while I flesh out Sidekick a bit more (rather than rushing it). Bootstrap ain't ugly.

@jescalan
Copy link
Member Author

Axis' role was always to be a library that provided helpers and highly customizable UI patterns, so I think this belongs within axis. In the past, it has also pulled in more basic functionality like vendor stuff, positioning, gradients, etc, but I'm more than happy to have this routed out to nib and autoprefixer now that they are viable solutions. The less I have to maintain, the better!

I'll try to take a look at placeholders where I can, but I assume most will be mixins, and luckily this won't matter much after gzip anyway like we talked about before. I know you are working on your own jam, but if you would like to be involved with this, I would love that. I feel like it's possible that axis could serve as a base layer for what you are building, with very bare-bones UI components, where you could stack more interesting themes on top, but who knows, maybe you want to take it in an entirely different direction.

@corysimmons
Copy link
Contributor

It's possible and I'll think about it but like you said, I like working on my own jam. ^_^

@samccone
Copy link

@zspecza
Copy link
Contributor

zspecza commented Oct 18, 2013

Wow, it's been such an eventful week. Four close friends turned 21 and it isn't even the weekend yet... So now I can finally post my opinion on this...

I'll start with a few questions: If we make Axis mirror Bootstrap in UI components, then why will users not just simply use Bootstrap's own mixins to do it? Why use some third-party library that requires a different CSS preprocessor? And if you want to use Stylus instead of LESS, then why not use one of the unofficial Stylus Bootstrap ports that already exist?

Plus there are a few things I disagree with in the way Bootstrap handles functional properties - here's an example though I think this may have changed now but for a while the maintainers insisted on px based typography despite many arguments: twbs/bootstrap#1943

I like my vertical rhythm, it keeps things nice and consistent. One afternoon, I was reading that issue and thought their opinions were fine - I'd just do all the functional stuff myself. But in practice it didn't pan out - it was just too hard to get done. There was way too much bloat.

The minute I saw Axis I was ecstatic because it provided building blocks that allowed me to create my own UI elements - which is what every developer should be doing anyway. It's nice to have defaults there if you want to be lazy, but I don't think it's a good thing in the long run, because everyone wants to be lazy and everything starts looking the same. Axis may not have a full set of UI defaults, but it still makes developing stuff a whole lot faster. It already has a perfect balance - I think we should keep improving it by ironing out the bugs and adding more helper mixins that solve problems people face when writing CSS and put it all into practice to look for the best combinations of CSS declarations in the existing UI components.

In fact I can think of an improvement already - currently, the button mixin makes no assumptions about vertically aligning, say, an icon and text in a button element. I had to do that myself on http://declandewet.com, and that's a concept that despite me learning it a hundred times, I always forget, because it's such a bleeding edge case...

This is the sort of stuff we should be focusing on in here, that and getting nib + autoprefixer properly integrated and giving some love over to nib, too - a few months ago, we deemed it possible to replace the gradient fallback image with a dependency-less solution. That's a bit out of my scope as a programmer, but the tools are there once we figure it out.

@corysimmons
Copy link
Contributor

I see what Jeff's doing and appreciate it.

Sidenote: Love your site Declan. Love those abstract background things.

@jescalan
Copy link
Member Author

All right guys, 0.2.0 has been very stable for quite a while in testing and I think we're ready for the ol merge and :shipit:. Only thing we need now is to update the docs page, which will probably happen along with the next roots version release.

jescalan pushed a commit that referenced this pull request May 13, 2014
@jescalan jescalan merged commit fec3efe into master May 13, 2014
@jescalan jescalan deleted the 0.2.0 branch May 13, 2014 19:30
@kylemac
Copy link

kylemac commented May 13, 2014

💐

@jescalan
Copy link
Member Author

Also, huge ups to all the contributors who helped with this version: @declandewet @adamjonas @leepowellcouk @joshrowley

And of course @samccone for the review!

@samccone
Copy link

🎍

@adamjonas
Copy link

🏩

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants