Include the default CSS in dist

[nawroth]

Having the CSS available would be very useful.

[ggrossetie]

The default css is available in the examples directory, but I think the latest version is produce by the stylesheet factory.

Anyway, I agree this would be useful 👍

[nawroth]

Oops, I didn't see that.
But anyhow, it should really be produced by the build.
I just couldn't figure out how to do it.

[nawroth]

BTW http://gist.asciidoctor.org/ is using asciidoctor.js and .css from 1.5.0.rc.5 since earlier today!
That's how I got thinking about it.

[anthonny]

👍

@nawroth it could be interesting to use Bower in your project to manage your version of asciidoctor.

[nawroth]

@anthonny That's true. Feel free to chime in at asciidoctor/docgist#7

[mojavelinux]

I agree, we should definitely distribute the CSS. I am planning on setting up a CDN for Asciidoctor eventually, but for now I think it makes sense to stick it into the dist...and even in the Bower repo.

You can generate the latest CSS from Asciidoctor itself either by running:

echo '' | asciidoctor -o tmp.html -a linkcss -

or by using the API (which may even work in JavaScript)

puts Asciidoctor::Stylesheets.instance.primary_stylesheet_data

You can also just grab it out of the Asciidoctor gem:

asciidoctor_spec = Gem::Specification.find_by_name 'asciidoctor'
css_file = File.join asciidoctor_spec.full_gem_path, 'data/stylesheets/asciidoctor-default.css'
puts IO.read css_file

[mojavelinux]

I'm also thinking that the development should happen on a different branch as master so that when we release, we don't have to check-in all the generated files. Instead, the generated files get checked into master by the build and then tagged as a release. wdyt?

[nawroth]

I don't think the generated files should be checked in at all, they should go to bintray (see https://www.npmjs.org/package/grunt-bintray-deploy ) or similar. Or @mojavelinux could create a separate git repo for release artifacts from the different downstream projects. For releases, the files could go to http://www.jsdelivr.com/ and http://cdnjs.com/ as well.

[mojavelinux]

I agree they shouldn't be in master at least. They are required to be an some git repository in order for Bower to work. I believe that Bower works off the tags, so if we only commit the dists to the tags, that seems reasonable. I don't think they should be sitting in master because then you get conflicts whenever you run the build.

I'm not sure how I feel about a separate repository. I like the single source of truth and discoverability of a single repository. If we can get the script to intelligently use tags for a release, I think we win here.

wdyt?

[mojavelinux]

I do agree we should propagate the releases around to the other CDNs such as cdnjs.com. We should track that task in a separate issue.

[nawroth]

"the other CDNs" -- is it already on some CDN?!

Not having the dist files in master would be great.

[mojavelinux]

At the moment I think it's only listed in Bower and published to npm. Is it in a CDN already?

[mojavelinux]

Oh, I see what you were asking. No, it's not on a CDN yet...unless you count github.rawusercontent.com as a CDN :)

[nawroth]

Well, I wouldn't. For gh-pages, GitHub do claim they are backed by a CDN. Not sure about the quality though. And you have to set up the DNS with a cname record pointing to username.github.io to make it kick in.

[mojavelinux]

Well, I wouldn't.

For the record, neither would I :) I was just stretching the pun on the dangling reference in my reply.