I have now tested this with Chrome, Firefox, Safari, and IE over both HTTP and HTTPS. You can see the HTTP version at http://166.78.23.198:4000/ (obviously that URL won't be valid forever).
In all 8 cases the site renders just fine. All of the links, images, styles, and fonts work. We have compatibility across all major browsers. It should be safe to try this out in production. We can always rollback quickly if necessary. Including index.html for each link is not a show stopper. It's a simple way for us to make site validation simple for contributors. I doubt we'd have access to .htaccess on CloudBees. I trust @abayer to know what's possible in that regard. @mattstep I understand that an experienced developer in many languages and sys admin like yourself wouldn't need this feature. I'll probably continue to use jekyll locally myself. However, that shouldn't prevent us from making it easier for anyone else to contribute documentation. The barrier to doc contribution is too high right now. The real complexity is in getting jekyll installed. Juggling Ruby versions with rvm, having the right Python version, getting the correct gems install, and not screwing up any of your other dev envs along the way. Also keep in mind that all of these tools are non-Java based and quite possibly foreign to the majority of our user audience. @abayer's experience getting jekyll running on Mac OS X is not an isolated incident. Heck, even getting jekyll installed on Ubuntu wasn't trivial and required updating, installing, troubleshooting, and Googling. I can't speak to what it's like to install on Windows but I'm sure it isn't any easier. We can take all of the pain out of this process and have users contribute to documentation directly from their web browsers knowing that the site will render properly. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-site/pull/2#issuecomment-20845803
