It would be great if this project targeted GitHub Pages Jekyll.

[howardroark]

I really like the aesthetic of this template and ended up using it with GitHub Pages as a project homepage. I like to set things up so I can edit Markdown and front-matter while letting GitHub Jekyll do the rest of the work. Basically just edit and push. With open-source projects I usually use the README.md file as the index of the site. Keeps all the Markdown and project details in one file as I work out the idea.

It would be cool if this template was designed to clone into a gh-pages branch of a new repo when someone was kicking off a project. All it really needs is a container/styles that output Markdown nicely.

Here is the example of how I used this... https://github.com/codingcoop/vagrant-host/tree/gh-pages

Just a thought. Thanks for the great work! I may make my edits more reusable either way.

[johno]

Awesome thoughts, thank you for sharing them, @howardroark !

I definitely agree, there should be a layout and/or support for rendering to html from markdown. That way, you can configure the readme to be the site's index, and specify the layout to be the md template. This is absolutely something that should work out of the box. So, that's something bleuprint should address ASAP.

It's super rad to see bleuprint in action, thanks for the link!

If you want to open up a PR with your conversions that leverage Jekyll's Sass compilation rather than the gulpfile, I'd gladly merge those in. Though, I think I want to keep the gulpfile in the project for js uglification/concatenation support since Jekyll, to my knowledge, doesn't support that without plugins.

I most likely won't have time to address this until this weekend, but I will first look into adding a markdown layout to ensure the default styling looks great with md -> html conversions. Essentially serving as the blog/post portion of the site.

I'm happy to collaborate if you'd like to add some tweaks and new features to bleuprint.

Thank you again for taking the time to open this issue. :beers:

[howardroark]

Great to know we are on the same page! I would love to collaborate on this.

I have implemented your template using a project which extracts GitHub's Markdown CSS. I figure there is no better baseline for how to handle Markdown then how GitHub deals with README files.

GitHub CSS extraction: https://github.com/sindresorhus/github-markdown-css

Project with template + GitHub CSS: http://pollinate.xyz/ https://github.com/codingcoop/pollinate/tree/gh-pages

I'm going to start building up a rough concept of a template here...

https://github.com/codingcoop/one-pager

It could be possible to make it a fork of this repo and port changes backward. Otherwise I will have a fork of this project going where I send things back.

Some things I think would be cool...

• Bring over the GitHub javascript for dealing with anchors
• Incorporate some color variations

I'll keep you updated!

[johno]

Great, @howardroark, sounds awesome.

Turning the readme into a pretty HTML doc with Github pages is a really great concept/use case.

I wouldn't worry about spending the time to maintain a fork of Bleuprint for the One Pages project to port changes if it's going to introduce extra work. When appropriate, I can always incorporate the relevant changes back in to Bleuprint.

I definitely agree with the Github js for anchors and color variations. I've pondered implementing a few different theme files that people can switch themes with @imports like so:

// Scss omitted for brevity...

@import 'themes/some-cool-theme';
@import 'themes/some-other-theme';

This will allow someone to change color variations on the fly, and then provide some insight into how they could further customize the Bleuprint boilerplate.

[johno]

Also, as a side note, I started crafting some Markdown CSS themes which could come in useful for theming, namely for the One Pager concept: https://github.com/markdowncss. I will open up a PR there, too.

[howardroark]

+1 for importing themes.

This Markdown CSS project org is great! In terms of importing Markdown CSS I like the idea of concentrating on a .markdown-body container like GitHub does... https://github.com/sindresorhus/github-markdown-css/blob/gh-pages/github-markdown.css

That way people can build around Markdown centric containers and also can expect their README edits to correlate between GitHub and their site.

This is a bit of a wild idea but it would be cool to convert the above css into JSON and then modify a copy of the outputted object to merge back together with the original and then convert back to CSS. This way you could have variations of the GitHub style CSS for use in different themes that could be easily merged with the GitHub original any time it changed.

This project could act as a good baseline:

https://github.com/sindresorhus/generate-github-markdown-css

Convert to/from JSON with this maybe:

https://github.com/aramk/CSSJSON

Merge the JSON object with something like this:

https://github.com/jonschlinkert/mixin-deep

[johno]

Absolutely, @howardroark! It'd be pretty easy/awesome to bring in CSS, like from the markdowncss org, and namespace it under .markdown-body using a reworkcss plugin. That way, it allows CSS themes to be created independently of their markdown use case (a big plus IMO). Then, one can select between themes and have those changes be reflected in the build.

Though, I feel like we could leverage reworkcss in place of CSS represented JSON and mixin-deep. I have been intending on creating a couple plugins for rework, rework-merge and rework-unique (I have other use cases for these as well), which could perform any required merging/diffing between CSS ASTs.

I think you're on the right track with the one-pager concept, and would love to collaborate. I'll spend the next couple days pondering what I think a potential proof of concept could be. If you've got some details/ideas/implementations in mind, in addition to what's above, please share.

[howardroark]

Sounds like you have a been thinking about this for a while :) I have never checked out reworkcss, but it looks great. Making plugins for existing projects and leveraging the AST makes way more sense.

With a few tweaks this project can be the "one pager" concept for GitHub pages in its default state. I don't really think I need a separate project at all. The only requirement would be that any Gulp builds related to CSS are done ahead of time so that choosing themes is just a matter of editing SASS.

[johno]

Haha, yep. Been pondering this one.

My one qualm in turning this into something intended to primarily consume a Readme file is that I still use this to scaffold out static sites pretty regularly. In these scenarios I want the majority of Jekyll features available. However, in the readme/splash page context, we wouldn't need all that fluff. Which, would create additional complexity when trying to handle two different use cases. So, I believe I will want to break this concept into it's own standalone project somehow. How exactly that will work, I'm not quite sure yet.

I will continue to ponder it further...

[howardroark]

I totally get that. I have a project in the works (it's going slowly because I'm not much of a programmer). It is basically a command line tool that lets you pull project scaffolds down from GitHub and preform operations/parse templates before dumping them to your system. The idea is that the transformation is defined in an object of data.

https://github.com/codingcoop/pollinate

The current project description may be a bit confusing (could be described in a much more simple context).

With this tool in place this project could make an excellent "Flower" (scaffold). The idea is that later a basic web UI could be offered to customize some of the finer details and offer you a command to paste to your terminal (passing the object along as an http endpoint).

Even got a organization lined up to house them all... https://github.com/flowershop

I'm always looking for help ;)

[johno]

Pollinate looks pretty awesome @howardroark!

When I get a chance I'll dive into it a bit and see what I can contribute. Sounds like a really awesome concept. Also, I wouldn't downplay your programming skills, that project looks extremely well laid out and implemented thus far.

I know all these pieces: pollinate, bleuprint (or a subset of it), and markdown themes will be able to fit together somehow for this "one-pager" readme context. It's just a matter of time before we figure out the perfect way to arrange them.

[howardroark]

I am learning as I go. It is making more sense every day. Truth be told I copied all that project structure from another node.js project ;)

But yes, I think there really is a demand for all these things!

[johno]

Hey, that's using the resources at your disposal :smile_cat: