Thank you for your thoughtful PR. I am sympathetic to this change, but would like one more pair of eyes on this before I merge.

@raphlinus: does this look like a good idea to you as well?

Hmm, I have mixed feelings about it. I certainly understand the desire to keep compile times down and avoid bloat, but these modules don't strike me as especially heavy. The experience with default features is that they're almost always left on, and are somewhat inconvenient to control.

Do we have any kind of quantitative measurement about how much compile time is saved here?

I understand the mixed feelings 😉

I've run some measurements with hyperfine on my laptop (crates were all downloaded):

That's a nontrivial improvement. I'm ok with this change. If the time delta had been much smaller I would have said it's not worth it. Thanks for the PR and measurements :)

Oh, I've noticed something:
I think the previous comparison was not 100% fair, as there is another additional crate built (getopts) when default features are active.

Here is a better benchmark, which shows the real difference:

I would caution against making a breaking change like this. There are a number of projects that use default-features=false (like rustdoc, clippy, etc.).

Also, to me, 0.7 seconds does not seem worth a change.

Is there anything to do here? Should this PR be closed or left open until a decision is reached?

Does anyone know how much the breakage would be?

This makes a lot of sense to me, and having an HTML renderer in a parser crate was a bit shocking the first time I checked the project. I think that both features should be in different crates, but keeping the current minimal functionality as optional features can make sense for tests.

All implications must be carefully reviewed though, so I will be back on this relatively soon.

Related to #526.

This pull request is interesting for the 0.10 release, merged.