mdo

> If they can unfuck the "so-and-so has commented on an old commit" thing hiding valuable conversation, we start to get into a real code review tool.

We'll get there ;).

Up until a few weeks ago, we had the whole issue clickable. It'd toggle the select checkbox for bulk actions across multiple issues/pulls. However, we opted to skip that as missing a click on say a milestone name, user avatar, or label would then toggle that issue's selection. It'd be even worse if the accidental clicks sent you to a specific issue as you'd get inadvertent loads and have to go back.

Bottom line? Too frustrating for common use, so we skipped it.

We've long discussed voting. It probably definitely won't ever happen in the near future.

You can set create `priority:1`, `priority:2`, etc labels right now and sort by those values. Not quite the same as what you want, but it's a pretty close solution until we figure out the next features to add to Issues.

I think we do that because what happens if random contributors jump in and start adding even more random task lists? We could probably do some checks to prevent that, but this is at least a safe and practical way to do it as a first-pass.

Eh, adaptive/responsive features are not that much of a payoff for us honestly. It helps with a few edge cases of screen splitting, but there are far bigger changes we can make than spending time on that. I wouldn't rule it out, but it's not at the top of our list right now.

You can totally get to this by removing the `is:issue` or `is:pr` from the search field. That'll show everything, regardless of type.

Hey there! Try clicking on the labels within the issues list—they are linked up to quickly adjust your search without typing. Not quite the same, but hopefully it helps!

<3

Dropping features, dropping IE8, adding features, rewriting the whole library, etc :p.

Actually I haven't updated the blog to use that yet. We just include videos with every single release. Don't try to draw a particular conclusion—it's mostly just for fun :).

Didn't really see the need to honestly :).

To be clear, those are just example class names so you know exactly what element I'm referring to and where it resides in the markup.

If you like this, you might like my Code Guide: http://mdo.github.io/code-guide.

Apologies for this, I was trying to be brief and lost most of the meaning in that one last night. I've updated it to better communicate the potential problem folks can run into.

We've not changed anything. Unsure what you saw, but the examples' HTML has never been minified.

Open an issue (with suggestions?) and we'll check it out.

Not sure why you'd think that—we've had it the last five months, since v3 dropped.

This is exactly why we haven't added it :).

I've not played with `inline-block` grids enough to be honest, but I've made a note to revisit it in v4.

We'll see how it goes—if enough folks complain, we can revisit :). I wanted the content to be in the absolute forefront with this update. That meant not affixing the top navbar and downplaying the side nav. I think it's super helpful, but again, I'm open to reversing things again if it'd be better for more folks.

We will definitely be looking into the IE support ASAP. More to follow on that.

We preferred Less over Sass because of it's ability to compile via JS, Mac app, or node. At the time, I believe Sass was not able to via JS.

Other than that, personal preference.

We plan on supporting at least back to IE7. Some of the code was written to do so already, and we'll get there with the rest of it, hopefully with negligible code bloat.

No, sir! It comes with compiled (and optionally minified) CSS, so you should be all set.

Actually, it came from our internal apps and is used across the board for all of those (and believe me, there are a lot of them) :).

Yup, we know we need to make that clearer, and fix the issues of IE8 and IE7. We'll get to that ASAP!