Live data from Hacker News

Bootstrap 2.3 Released

blog.getbootstrap.com

21–30 of 118 posts

Re: Bootstrap 2.3 Released

#21
post #8

Not sure how I feel about the swearing on the page.

sooo... Counter(re.findall(r"[^a-zA-Z]([a-zA-Z]+)[^a-zA-Z]",requests.get(" http://blog.getbootstrap.com/2013/02/07/bootstrap-2-3-releas... ).content.lower())) I see one occurrence of 'shit'. I'm not sure how I feel about your pansy ass semi-outrage of someone else's release page language. Oh, wait. I feel nothing, approximately what this entire conversation thread is worth.

Ctrl + F shows two. Time to update your regex-fu, or use simpler tools.

Re: Bootstrap 2.3 Released

#22

> Renamed all of the variables to use dashes instead of camelCase. I absolutely detest camelCase. It ranks down there with good-old Hungarian notation. So, I am now wondering, why this change? Are people finally coming to their senses?

I don't want to start a flame war, but I was wondering if there is a rationale for prefering dash-case? I have a hard time not writing in camelCase by default now.

Re: Bootstrap 2.3 Released

#23
post #11

Replace all CSS transitions with JavaScript transitions. why?

I'll probably write up something at length about this decision when/if it happens… but this is the current thinking:

CSS transitions are just total shit to deal with in javascript.

What people often don't realize is that there is an event for transitionEnd in javascript – but this isn't always fired in a reliable way – only when a transition successfully ends (which isn't all the time).

This is incredibly problematic because often really important functionality is tied to the completion of transitions.

Because these functions never finish, sometimes you're left with dead dom nodes or weird incomplete states.

What's more, there isn't a performance benefit to using css transitions – the benefit is that they were suppose to be make transitions easier and provide a nice separation of style from logic – but they end up being incredibly more difficult and because of the necessary fallback logic, the styles end up leaking back into your logic anyways. It's a pain in the neck :/

With bootstrap we really just want to give everyone the most reliable product we can, and css transitions just aren't that.

Also, from what I hear, the spec is basically dead in the water – and a reliable cancel event isn't in the works (unless this has changed in the last month or so)… which is more of a reason to consider alternatives.

Most likely we will end up going with some sort of combination. CSS transitions when we don't need a reliable "complete" event – and css transitions when we don't really care (though this case is becoming more infrequent).

Re: Bootstrap 2.3 Released

#24
post #22

> Renamed all of the variables to use dashes instead of camelCase. I absolutely detest camelCase. It ranks down there with good-old Hungarian notation. So, I am now wondering, why this change? Are people finally coming to their senses?

I don't want to start a flame war, but I was wondering if there is a rationale for prefering dash-case? I have a hard time not writing in camelCase by default now.

fwiw, we generally just try to do what the language does:

border-radius document.createElement etc…

Re: Bootstrap 2.3 Released

#25

> Renamed all of the variables to use dashes instead of camelCase. I absolutely detest camelCase. It ranks down there with good-old Hungarian notation. So, I am now wondering, why this change? Are people finally coming to their senses?

Preference, readability, consistency with classes, better spell checking, etc. I always felt we should have done dashes instead, but shipping camelCase meant sticking with it for backward compatibility. With v3 though, we're going with our gut and using dashes.

Re: Bootstrap 2.3 Released

#26

> Renamed all of the variables to use dashes instead of camelCase. I absolutely detest camelCase. It ranks down there with good-old Hungarian notation. So, I am now wondering, why this change? Are people finally coming to their senses?

just-testing-this

JustTestingThis

Hmm. I think it only matters to me that the author picks one and stays with it. But that means that all libraries he uses has to use the same one. Which is why languages tend to prefer one over the other. e.g. Java using CaMeLcAsE

To have them mixed in one code base would be like a micro context switch.

Re: Bootstrap 2.3 Released

#27
post #10

Why the dropping of support for submenus? I find those really useful and it would be a pain to have to patch them back in.

I am glad that they removed it. Submenu is very much a last generation tech. Awkward on mobile devices. And my one very strong reason to use bootstrap was to make the app mobile friendly.

Removing its support is good because it was adding tons of CSS code.

Re: Bootstrap 2.3 Released

#28
post #8

Not sure how I feel about the swearing on the page.

sooo... Counter(re.findall(r"[^a-zA-Z]([a-zA-Z]+)[^a-zA-Z]",requests.get(" http://blog.getbootstrap.com/2013/02/07/bootstrap-2-3-releas... ).content.lower())) I see one occurrence of 'shit'. I'm not sure how I feel about your pansy ass semi-outrage of someone else's release page language. Oh, wait. I feel nothing, approximately what this entire conversation thread is worth.

If my comment seemed like a semi-outrage then you sir/madam are a very sensitive person.
Post reply on HN