Bootstrap 2.1 released(blog.getbootstrap.com)
blog.getbootstrap.com
Bootstrap 2.1 released
http://blog.getbootstrap.com/2012/08/20/bootstrap-2-1-0-released/
142 comments
I <3 Bootstrap, but I did find the old documentation easier on the eyes and easier to navigate as well.
This is just a speculation, but I think bootstrap-affix.js is their new baby. If there is one thing that the new navigation does well, it's promoting the affix js feature (scrollspy stuff).
I like the documentation navigation style using affix in rc - http://rc.getbootstrap.com/customize.html
Fair criticism, but the subnav we had before, like the navbar, just doesn't scale. Let's less obtrusive, but hinders us in a big way. It's tough doing nav that works for everyone everywhere, but hopefully this pans out for us and folks using Bootstrap.
Edit: Also, the side nav came first, then the affix plugin. Originally I was proposing a fixed, independently-scrolling left sidebar, which we may still get to, but it felt decidedly un-Bootstrap-like for the time being.
Edit: Also, the side nav came first, then the affix plugin. Originally I was proposing a fixed, independently-scrolling left sidebar, which we may still get to, but it felt decidedly un-Bootstrap-like for the time being.
I really, really loved the subnav, precisely because I use smallish width windows (routinely half of 1980px, thanks to window snapping) and at that size the left nav block feels like a complete waste of space (especially the huge blank area just below, given a height of 1080px).
It's a lot harder for me to navigate the doc pages too because I'm scrolling a lot, lot more and the "sub-topic" nav-bar is gone (e.g. "Base CSS" page had "Typography", "Code", "Tables", etc.)
Like you, I still appreciate the new functionality and continued development.
EDIT: Went back and the styling of the docs changed again (was I hitting a cached page?). The subtopic navigation is back and on the left now. Still takes a while to scroll but it's an improvement.
Like you, I still appreciate the new functionality and continued development.
EDIT: Went back and the styling of the docs changed again (was I hitting a cached page?). The subtopic navigation is back and on the left now. Still takes a while to scroll but it's an improvement.
+1 on left hand navigation being a bad idea. I now see 20% less information on the screen as I try to quickly find something.
I like the new navigation and layout better because I can find everything in one large column. Before I had to scan both up/down and right/left because of the multi-column layout.
Yup, that was what we wanted to avoid for this round of updates. Cmd+F is your best friend in docs, no matter the format. Either way, we'll strive to improve as much as we can with future updates.
I have the exact same opinion, the new doc page is a step backwards...
It make me close it in 10s and I use TB in 2 of my projects and I love it, but that layout is simple terrible for people with smaller than 20" screens... please provide us another site with more reading area and minus menu.
Anyway thanks a lot for this, I love TB it's great and you guys are my heroes :D
It make me close it in 10s and I use TB in 2 of my projects and I love it, but that layout is simple terrible for people with smaller than 20" screens... please provide us another site with more reading area and minus menu.
Anyway thanks a lot for this, I love TB it's great and you guys are my heroes :D
So much scrolling ...
For example skimming through the table css options, you see a lot less on one screen.
2.1 seems solid though, invaluable tool at my job.
For example skimming through the table css options, you see a lot less on one screen.
2.1 seems solid though, invaluable tool at my job.
Unfortunately, it seems like submenu implementation has the classic mistake: it requires mouse cursor to travel strictly along the menu item to get to the submenu.
Pictures: http://imgur.com/a/pSDOo
Pictures: http://imgur.com/a/pSDOo
Yep, the trick here is to keep the menu open even after the mouse has left the parent menu area. It's so simple yet probably quite difficult to code.
Yes. Not only that, it should keep the submenu open when traveling inside this triangle (but close on timeout if mouse stays still inside it):
Also, if in the parent there's another menu item with submenu somewhere on the path of mouse inside this triangle, ignore this item.
For best results, if mouse was inside the submenu for a moment, keep the submenu open until clicking away from it or moving over a different item in the parent menu. So many details!
+--------+
| parent |
| +--------+
| /|submenu |
| / | |
|=====/==| |
|=====\==| |
| \ | |
+------ \| |
+--------+
Also, if in the parent there's another menu item with submenu somewhere on the path of mouse inside this triangle, ignore this item.
For best results, if mouse was inside the submenu for a moment, keep the submenu open until clicking away from it or moving over a different item in the parent menu. So many details!
Upvoted for the ASCII art alone. That seems to be a lost art, particularly here on HN. Long live the ASCII art diagram!
I'm also a big fan of ASCII diagrams. The ones I use to explain my Rails authorization gem, Authority (https://github.com/nathanl/authority#the-flow-of-authority), were made using a great tool called Asciiflow: http://www.asciiflow.com/
Not difficult at all. For a simple fix, one just needs to add a timeout between receiving the mouseOut event and hiding the menu. OS X appears to do something slightly more complicated; it hides the menu immediately if you mouse out away from the submenu, but keeps the menu open for about one second if you mouse out towards it.
But then you couldn't use the `:hover` pseudo selector; you'd have to replace css with javascript.
In usability vs "purity" of implementation wins usability.
This should really be considered a bug of the css spec.
The CSS spec's :hover was never made for dropdowns, it was made for simple on-hover effects, IMO.
Apparently the CSS spec does allow delayed behavior - http://www.w3.org/TR/css3-transitions/#transition-delay-prop...
Its not difficult at all actually.
Just requires a timeout for the onmouseover event. jQuery's hover intent would work wonders.
Basically show the submenu onmouseover of parent and if no mouseover is detected on the submenu within 400ms => hide the submenu.
It gives the user a slight bit of time to move the mouse to the submenu rather than relying on perfect mouse movements.
Just requires a timeout for the onmouseover event. jQuery's hover intent would work wonders.
Basically show the submenu onmouseover of parent and if no mouseover is detected on the submenu within 400ms => hide the submenu.
It gives the user a slight bit of time to move the mouse to the submenu rather than relying on perfect mouse movements.
I wrote about this issue and ways to overcome it a little while back (with pictures!): http://thomaspark.me/2011/10/making-menus-escapable/
Thank you for calling this out. We'll fix it up as best as we can with the next release. Knew it going into this release it wasn't enough, so hopefully we can iterate on it to get the right behavior.
I love bootstrap. Yeah, i hate the fact that all the mvp's out there basically look & feel the same by using it as the go-to css framework, but at the same time it's helping people iterate a lot faster and that's rarely a bad thing.
In addition, given how Twitter's bootstrap's look & feel is starting to influence web design at large, I wonder if there is a case for other large web-players to make their own css framework to impact the look and feel of sites to their favor. Think of it as disguised propaganda.
In addition, given how Twitter's bootstrap's look & feel is starting to influence web design at large, I wonder if there is a case for other large web-players to make their own css framework to impact the look and feel of sites to their favor. Think of it as disguised propaganda.
I agree with one exception: fixed headers are an eyesore and a usability anti-pattern in most cases. Even regular users know how to scroll to the top.
Fixed headers also break the pagedown behaviour: when you press the page down key, you miss some lines that are hidden below the fixed headers. (If we mean the same thing by fixed headers)
Nearly all desktop applications use a fixed header, it has fine usability there. For a web app, as opposed to a primarily informational site, I think there are definite cases where a fixed header is preferred. Gmail for example, it makes sense to have control butons for your message always visible.
tl;dr on your average blog I agree, but in a web app I don't.
tl;dr on your average blog I agree, but in a web app I don't.
Since lukifer wrote "in most cases" you're only disagreeing if you think there are more web apps out there than blogs or informational sites. He didn't say a fixed element is never desirable. I think you're agreeing.
How about taking the approach of the browser on android 4+? The top bar disappears as you scroll down, but pops into view when you scroll up. It is then aligned with the user's intention, a scroll up being a signal that they wish to go up to the menu. Combine with a reasonably speedy fade-out for cases where a user is simply scrolling up to re-read something, and I think it puts most of the usability issues to rest.
Sure, regular users KNOW how to scroll to the top, but why make them? I think that fixed headers add some good convenience, especially on long pages.
They were an anti-pattern for my site so I CSSed them away. But with 2.1 there's .navbar-static-top which does the same thing as my custom CSS. I think they should place it ahead of .navbar-fixed-top in the docs since it's better in most cases.
yeah it's amazing how removing that black fixed bar make it seem suddenly so... open.
I actually pulled it at the last minute, but I was considering removing it for 2.1. Perhaps in 2.2 when we continue to evolve the docs :).
I think it's a matter of personal taste. Since all the examples used to display the bar, people probably had a tendency to include the black-bar without thinking too much about it. However, nothing prevents you from building a very functional site without it (I know i have).
Either way, huge prop for the awesome work! The new doc is simply excellent and the whole framework is just remarkable, particularly if one considers how far you guys have pushed it in less than a year.
Either way, huge prop for the awesome work! The new doc is simply excellent and the whole framework is just remarkable, particularly if one considers how far you guys have pushed it in less than a year.
Yes, I use a custom class on my header that removes the rounded corners that appear on the navbar when you don't use the fixed class (don't know if it's still the same on 2.1).
Would you mind elaborating? Isn't it more convenient to be able to navigate without having to scroll to the top?
It's not always a bad thing; for something like API docs, a fixed header can make sense. But for blogs and brochure-ware, and even some web apps, it breaks the focus on the content and steals precious screen real estate.
If the most common use case involves many quick jumps across the page hierarchy, fixed header can be a good fit (though an affixed side-nav might be better for wide screens). But if the most common case is drilling down to a specific page and spending a little time there, then fixed headers just create noise and get in the way.
If the most common use case involves many quick jumps across the page hierarchy, fixed header can be a good fit (though an affixed side-nav might be better for wide screens). But if the most common case is drilling down to a specific page and spending a little time there, then fixed headers just create noise and get in the way.
I would argue that they've done a good job of pulling together a lot of the look and feel of their peers into one library. While it can be obnoxious that a lot of MVPs all look the same because of it I don't think it actually looks that bad.
Interesting comments on the Extend page [1] on why LESS vs SASS:
Why LESS?
One of Bootstrap's creators wrote a quick blog post [2] about this, summarized here:
- Bootstrap compiles faster ~6x faster with Less compared to Sass
- Less is written in JavaScript, making it easier to us to dive in and patch compared to Ruby with Sass.
- Less is more; we want to feel like we're writing CSS and making Bootstrap approachable to all.
[1]: http://twitter.github.com/bootstrap/extend.html
[2]: http://www.wordsbyf.at/2012/03/08/why-less/
Why LESS?
One of Bootstrap's creators wrote a quick blog post [2] about this, summarized here:
- Bootstrap compiles faster ~6x faster with Less compared to Sass
- Less is written in JavaScript, making it easier to us to dive in and patch compared to Ruby with Sass.
- Less is more; we want to feel like we're writing CSS and making Bootstrap approachable to all.
[1]: http://twitter.github.com/bootstrap/extend.html
[2]: http://www.wordsbyf.at/2012/03/08/why-less/
To each their own. The third point is actually why I prefer SASS. I like meaningful whitespace.
I'd prefer Stylus over both LESS and SASS. Now that Bootstrap is relatively stable, I intend to port it.
It may be easier to just help update this to 2.1-
https://github.com/thomas-mcdonald/bootstrap-sass
https://github.com/thomas-mcdonald/bootstrap-sass
I believe they were referring to porting bootstrap to Stylus (rather than SASS)…
Stylus is nice, but I'm just not comfortable dropping the colons yet. Maybe I'll give it a go for a project and see if I come around.
Is the semicolon in "tl;dr" strictly necessary?
Funny how they put the semi-colon there but not in the Javascript.
Yes. "Too long didn't read" is not grammatically correct.
(For those who don't know there was a standoff between the bootstrap guys and the maker of a popular js minifier tool [Douglas Crockford I think?] over the pragmatism of ending lines in js with semicolons. Bootstrap claims that semi-colons are optional and verbose, while the minifier folks espouse semi-colons as a best practice, and have chosen to consider it "not a bug" that their minifier breaks working code with no semi colons in some cases.)
tl;dr
I'm in the optional semi-colons camp, and it is a bug in the minifier :)
I'm in the optional semi-colons camp, and it is a bug in the minifier :)
Why not just put them on separate lines? Let the optimizer figure out when to add them. :)
Come on, meow, I thought we were past this :).
Yes. It's to avoid a comma splice and a sentence fragment. "Too long; don't read," versus "Too long, don't read," versus "Too long. don't read."
yes...
Can you actually host the old documentation this time and not leave us in the dust like you did in the 1.4 => 2.0 release?
By the way, Node.js does an awesome job of keeping documentation (and landing pages) online for
every version: http://nodejs.org/docs/
direct link to download it: https://github.com/twitter/bootstrap/zipball/v2.0.4
It's still available in the source.
That is not enough. Old documentation MUST STAY ONLINE.
How can that possibly be not obvious?
How can that possibly be not obvious?
It does "stay online". Why must it also be hosted for you? When you download Bootstrap, you get all the docs in a folder. Open the index in your browser. All the old versions are tagged on GitHub and can be downloaded forever.
So when bootstrap releases a new version suddenly everyone must switch to self-hosting their docs? Because leaving the friggin' docs online costs so much?
It's inconceivable we are having this discussion on HN.
It's inconceivable we are having this discussion on HN.
> Because leaving the friggin' docs online costs so much?
It's not so much about cost but about polluting the Google index with obsolete information. For example, look up a Java API and it's very likely that the first link you will get will point to Java 5. Google is not wrong, that API link is most likely the most linked to, but it's very often not the one you are looking for and certainly not the one that the author of the API wants you to find first.
It's not so much about cost but about polluting the Google index with obsolete information. For example, look up a Java API and it's very likely that the first link you will get will point to Java 5. Google is not wrong, that API link is most likely the most linked to, but it's very often not the one you are looking for and certainly not the one that the author of the API wants you to find first.
I really don't see the problem. You have to download the release to use it and the documentation is included, what's the huge deal about keeping a tiny HTML file around? It's not like you suddenly need to start renting a VPS to read it..
It's inconceivable that projects are expected to host old docs forever. Jesus, it's in the zip that you get if you download the Github snapshot anyway. It's literally 20 seconds of your time to have your own local copy.
python & django both host old docs for all in-use versions seemingly forever. Nobody's complaining that they're polluting google, or campaigning for them to be taken down. So why are people reflexively resisting a reasonable request for bootstrap 2.0 docs to stay up? status quo bias!
All of the documentation for old Haskell packages on Hackage are hosted online and it does pollute Google's results. Google often links to outdated versions and you have to take a couple steps to find the current version.
There is a big difference between forever and switching it off as soon as you change versions. Most people were still using 1.4 when 2 came out so leaving the documentation up for a year or something would not have been difficult.
Have you actually tried to do that? BS 2.0.4 pops up with "framing not allowed!" and redirects to a missing page on the internet.
Probably relatedly, some/much of the docs rely on javascript, so they won't run unless you're running through a server. Instead of forcing everyone who wants or needs to see an older version of bootstrap docs to wrangle this non-working stuff in to a server and configure that, massive amounts of time would saved by simply having versioned docs online.
EDIT: the short answers is not to open the index.html file but any of the other .html files (examples, etc) and you should be able to at least navigate around some.
EDIT2: At least some of the javascript stuff is working without loading from a server - not sure why yet, but it's working. The index page still needs to be fixed.
Probably relatedly, some/much of the docs rely on javascript, so they won't run unless you're running through a server. Instead of forcing everyone who wants or needs to see an older version of bootstrap docs to wrangle this non-working stuff in to a server and configure that, massive amounts of time would saved by simply having versioned docs online.
EDIT: the short answers is not to open the index.html file but any of the other .html files (examples, etc) and you should be able to at least navigate around some.
EDIT2: At least some of the javascript stuff is working without loading from a server - not sure why yet, but it's working. The index page still needs to be fixed.
Yes, I did actually try to do it. The popup is only on the index page, from one of those dynamic Github watcher-count widgets, and can be ignored by either opening the page of documentation you need instead or holding down escape, or deleting the offending widget.
I'm not sure what you're talking about with the JavaScript. JavaScript runs on the client, not the server. Twitter hosts these docs on Github Pages already... static files, no server-side code.
I'm not sure what you're talking about with the JavaScript. JavaScript runs on the client, not the server. Twitter hosts these docs on Github Pages already... static files, no server-side code.
An error on the index sends off alarm bells, and I bet others never bother to try the other pages - just thinking "this is broken".
I know where JS runs. I was conflating embedded javascript references as <script src="http....> style javascript. Typically when I am doing JS, the JS is marked up as being served from a domain - an initial assumption would be that it would be trying to pull the js from a server, but it's not (or not caring, or my stuff is cached).
I still side with the others who want/expect hosted and versioned docs from a project of this size/influence.
I know where JS runs. I was conflating embedded javascript references as <script src="http....> style javascript. Typically when I am doing JS, the JS is marked up as being served from a domain - an initial assumption would be that it would be trying to pull the js from a server, but it's not (or not caring, or my stuff is cached).
I still side with the others who want/expect hosted and versioned docs from a project of this size/influence.
I ran into the same issues you did, went ahead and compiled the archive docs here - http://unofficial-twitter-bootstrap-documentation.com/
I'm amazed by your sense of entitlement.
Because I ask them to make a folder on their webserver and put the old docs there, which is going to take them all of 5 minutes?
Yes, sometimes people need to be reminded of basic common sense. I do feel entitled to that.
Yes, sometimes people need to be reminded of basic common sense. I do feel entitled to that.
While the attitude is a little entitled, there may still be a valid point for other users as well. Couldn't se properly crafted URLs on the homepage solve this problem? Like /tags/2.0/documentation/index.html [1]. And run it right off of bootstrap?
Edit: the point being that we can point links at pages from previous commits, branches, and tags Shouldn't this help?
[1] that URL was slightly bastardized but I'm sure someone could very quickly whip this up
Edit: the point being that we can point links at pages from previous commits, branches, and tags Shouldn't this help?
[1] that URL was slightly bastardized but I'm sure someone could very quickly whip this up
Boy I was half asleep when I wrote that comment, all I was saying was that since github lets you reference previous versions of files by crafting the URL properly to include a tag/branch/hash, it should be possible to link to previous versions of the documentation straight from the latest version, eliminating the need for someone to clone the repo to access them.
Python, Django, Ruby, Rails, Node.js, jQuery all have multi-version docs online. I'm sure there are plenty more examples. Yes, I do feel entitled to having support for outdated but still relevant software. This is standard.
The latest version of bootstrap only just got released. I think a majority of users will still find the old docs relevant, even weeks later.
Yes, I realise I can still download the docs. But it's more convenient for some people to have it hosted online.
The latest version of bootstrap only just got released. I think a majority of users will still find the old docs relevant, even weeks later.
Yes, I realise I can still download the docs. But it's more convenient for some people to have it hosted online.
Please make it available online, or at least someone should make it available online.
You can clone the repo, check out that branch, and open the docs in your browser locally. That's even better, since now you don't even need a network connection to access it.
Having a copy that you can access locally is great, but there are advantages to having it online.
First, it means you can navigate to it by googling "bootstrap 2.0 documentation". If you are using five JavaScript libraries, it can be annoying to have to find the folder for documentation for each library.
Also, you might not even have the documentation locally. Another developer might have set things up and they might not have checked the documentation into version control.
First, it means you can navigate to it by googling "bootstrap 2.0 documentation". If you are using five JavaScript libraries, it can be annoying to have to find the folder for documentation for each library.
Also, you might not even have the documentation locally. Another developer might have set things up and they might not have checked the documentation into version control.
Not to mention that any old tutorials, blog posts, wiki pages etc -- now link to 404 land.
While it would be great if everyone could just magically upgrade, if you've spent a lot of time wrangling some content management system to the "old" bootstrap, you're more likely better off fixing bugs in that site, than upgrading and hoping nothing breaks.
If it's supposed to be used as a framework, I'd say it's common courtesy to provide the old documentation for at least a short period. It's not that hard, see eg:
http://www.python.org/doc/versions/
While it would be great if everyone could just magically upgrade, if you've spent a lot of time wrangling some content management system to the "old" bootstrap, you're more likely better off fixing bugs in that site, than upgrading and hoping nothing breaks.
If it's supposed to be used as a framework, I'd say it's common courtesy to provide the old documentation for at least a short period. It's not that hard, see eg:
http://www.python.org/doc/versions/
Not cool guys. I can't actually open the docs that I downloaded because I get a popup that says "Framing is not allowed!" and redirects me to a non-existent Github URL.
[deleted]
For that release we had an upgrade guide. It wasn't the most complete, but I think it helped a lot. For this one, as is the case for every other release, just browse the tags and download the docs. Just as it's not terribly difficult for us to host them, it's not asking much for you to download a ZIP file that will always be available :).
How do you recommend I link someone else to the exact docs (in lock-step with tutorials, etc.) going forward?
I just tried out 2.0.4 (and Bootstrap in general) for the first time an hour ago. I'm already obsolete!
Bootstrap has restored the joy I used to have in building websites. I can think more about design and what I want to stay instead of cross site compatibility, pixel dimensions, and building responsive designs. Thanks so much to the team at Twitter for putting this out there.
Excellent work, Bootstrap is awesome! Thanks!
BTW, I found almost all Bootstrap-powered websites I visited uses sticky top navigation, which wastes considerable amount of my precious vertical screen estate.
Another wide-screen wasting example is the new Gmail and Google Groups - and what's even worse is that they force you to use the new UI.
I find sticky top navigation is annoying and nothing else, I just don't get it, aren't many people using width screens nowadays? Or is it just me?
Maybe Bootstrap's nav should be non-sticky by default?
BTW, I found almost all Bootstrap-powered websites I visited uses sticky top navigation, which wastes considerable amount of my precious vertical screen estate.
Another wide-screen wasting example is the new Gmail and Google Groups - and what's even worse is that they force you to use the new UI.
I find sticky top navigation is annoying and nothing else, I just don't get it, aren't many people using width screens nowadays? Or is it just me?
Maybe Bootstrap's nav should be non-sticky by default?
Bootstrap has been an invaluable asset for building our MVP. I'm glad we got rid of the top bar, and very few people actually think we use bootstrap. But it affords us wonderful defaults for tables, buttons, menus, modals etc.
If the team making it reads this, thank you. I owe you many beers for what you've given us.
If the team making it reads this, thank you. I owe you many beers for what you've given us.
What is MVP in this context, ModelViewPresenter?
I'm happy that the fluid offsetting made it into this version.
I've been using Zurb Foundation (http://foundation.zurb.com/). It doesn't have as many feauture-rich components, but found the responsive grid easy to use and I really appreciate the fact that my site doesn't look like everyone else's...
Sorry to be a noob, but how does one get that glowing button effect as seen on http://rc.getbootstrap.com/index.html ?
CSS Box Shadows: http://css-tricks.com/snippets/css/css-box-shadow/
The navbar component is now white by default.
Thank you for handing out coloring papers to the devs. Seriously, this will make the entire web 10% more unique.
Thank you for handing out coloring papers to the devs. Seriously, this will make the entire web 10% more unique.
The docs for previous versions: https://github.com/twitter/bootstrap/tags
I really do not like this new boostrap page. There's too much back and forth (left and right) hopping going on with my eyes. It doesnt feel very natural. It's like driving and then looking at the passenger over and over. I don't like it. Keep everything above the content and keep it full width like it was, but that's just my opinion.
[deleted]
I wonder if moving further away from the twitter.com look is intentional, for branding purposes.
None of the table examples in the documentation work (striped, hover, etc) at http://twitter.github.com/bootstrap/base-css.html#tables on Chrome 21
I've already started a 2.04 site. As a web design newbie, how hard is it to update to the latest version? Just copy over the js and css? (I realise I'd need to re-write my html to use the new features).
One of my main beefs with Bootstrap was that it felt cramped. The switch to 14px body text with 20px line height addresses that. Personally, I'd increase the default line height a bit more.
It's fantastic! With the addition of date/timepicker it'd be complete.
It's strange to browse a website while someone changes pages from up underneath you. I'm trying to develop here!
That aside, thanks for creating this. Bootstrap makes prototyping a pleasure.
That aside, thanks for creating this. Bootstrap makes prototyping a pleasure.
Any plans for dropping JQuery as a dependency on the controls?
The customize area is really helpful and chops off time lost going through the source trying to customize it by hand. Great addition. Thanks for all the hard work.
Have you checked out the LESS code (instead of the compiled CSS)? The file variables.less has the same settings (with comments!) as the online customizer. It's much faster to tweak that file and recompile than it is to use the compiler.
Yes, thank you. I'm just a sucker for GUIs.
I'm not very colorblind, but the "warning" color used for the progress bars is far too similar to the "success" color. Please consider a brighter yellow.
Awesome news. For me the most important thing about the update is that the modal popup works with the latest Opera. Also the docs feels easier to use.
2 days early! So excited. Too excited perhaps.
One tip I use with icons, especially on colored backgrounds like alerts, is using a class like :
i.icon-blend { opacity:0.8; }
i.icon-blend { opacity:0.8; }
Oh wow, I love the new doc website. This is so cool! Keep up the great work!
Looks like www.bootstrapcdn.com has already updated their files.
Thanks , hope to play around with it this week.
@loceng I might be more excited than you
FYI: If you click "reply" on an individual comment you can respond directly to someone else's comment (as I've done here).
He was hoping this was Disqus platform perhaps..
Or he was commenting about the twitter bootstrap, in kind of a twitter reply.
im glad someone was able to figure it out...
please don't say the D word...
This is great tool
Couple thoughts:
Maybe its just me but I think the docs site a huge step backwards in usability. The dark blue <-> red graphics offset by the blue of their primary buttons is a little...gross. I am also not at all a fan of the left hand navigation panel, I get that they are trying to show off the affix component but I'd rather have the content be full width as its all I am really there for. I found the sliding top sub navbar far less obtrusive and easier to navigate. Also: so white is the default for the navbar but the demo site is still using black?