tkazec

Presumably Windows' fault, since it has awful font rendering systemwide. Looks fine in Chrome 20 on Lion.

Yeah, it does make me wonder some about the ethicalness. Back in 10k Apart 2010, one of the top 3 apps compressed nearly their entire app into a .png and then eval()'d the result... Which ended up being pretty innovative I suppose, as they wrote the compressor and bootstrap themselves.

Then again, Closure Compiler is accepted even though the advanced mode may rewrite some of your code. And the crushers are available to everyone free of charge, so...

I posted a writeup on the creation process here: https://plus.google.com/114368870393867455297/posts/W1xiWydN...

You remember correctly! If you don't mind me asking, who were you with? I (their 15 year old intern) was there from August-November and got to know the place pretty well :)

It really just depends on the context: In a web app (the example in the essay) or Chrome extension, traditional navigation mostly falls away, leaving something almost entirely controlled by JavaScript. Buttons and links have two distinct styles and places to be used, but in a web app they usually functionally do the same thing. In Bootstrap, the issue was how to make links that look like buttons also behave like buttons, which all the issues still apply to.

Once someone brought up the keyboard issue in my pull request, I researched for a while, and then made the post once I angrily realized the full extent of the problem.

If you need an example app that uses both buttons and links, here: https://chrome.google.com/webstore/detail/mghenlmbmjcpehccoa...

I think in situations where you want to use a "button" (in the functionality sense) that looks like a link, you probably won't need to disable it—the two styles don't really mix for the most part, though I'm sure I've seen it done somewhere.

I know what e.preventDefault() is and when and how to use it, just simply didn't think of it when trying to find solutions. It was promptly pointed out in the G+ comments, but there are still major drawbacks to that approach.

Either way, it was well past the asking Bootstrap to add this phase by the time I wrote the post.

>what's with all the hate for href="#"? Um, there was a section of my post explaining everything wrong with it, which was also further discussed in the G+ comments.

Of course I understand why keyboard accessibility (a benefit of href="#") is a good thing, that was a main point in the post: There's no solution for adding "buttons" (in the functionality sense) that look like standard links without major drawbacks, like a lack of keyboard control.

Great point, I hadn't thought of that. Buttons are so finicky :(

On a related note, I wonder how screenreaders handle buttons? I'm guessing/hope they read the labels, but if they don't...