I'm not sure why the CSS needs to be declared as containing UTF-8 since all the characters of the file are part of the US-ASCII range.
Use the .overflow-container on tables and pre/code blocks. "-webkit-overflow-scrolling" seems to be useful to allow horizontal scrolling on overflow elements on iOS [1].
This is not in any way useful as a library. Charitably, it's a useful reminder to set max-width to 100% on embedded media. Less charitably, it's an artifact of the hype du jour on one of those terrible new-fangled TLDs.
=== Just FYI... after opening this link, === and in short succession this nearby one: news.ycombinator.com/item?id=7404218 ("Bootflat"), something sent my Firefox browser and then my entire Galaxy Tab 8.9 (which has been functioning pretty flawlessly for 3+ years) into an unstable state.
I may have to root/wipe it now... :(
I can't prove that it was caused by either this or the other link, but the coincidence is troubling... who checks these HN submissions for malware anyway?
It responds well to being resized (e.g. to fit on a mobile phone screen instead of a large monitor). Although, I think it is normally used to mean considerably more than the simple scaling being done here (e.g. I've seen designs where the text goes from two columns to one if the display is narrow).
http://en.wikipedia.org/wiki/Responsive_web_design
Right. His first example puts a scale factor on a 2400x700px image to make it "not too big" for smaller screens. That's responsive design the same way that the NES emulator on my old WinCE phone in 2003 (which had a touch display that only supported a single input touch at a time) was NES on WinCE.
I post a 1 line solution that lets you manage complex application state changes in responsive layouts and deal with gui conflicts across responsive designs using pure CSS/LESS and don't get a single upvote.
This guy posts that HTML is fluid by default with a couple lines of CSS and gets 20 votes.
HN, I really don't understand what the hell is going on here anymore.
Nah I don't assume anyone is avoiding upvoting out of spite or anything, but I just thought HN as a whole was technically more advanced than most other communities because of the user base and niche ... so it leaves me scratching my head.
I've noticed a definite upswing in nontechnical (management, strategy, gossip/politics, worldnews) articles during weekdays in the last couple of years. There are also many more 'redditlike' comments in the last 6 months to 1 year- jokers, puns, easily googlable questions etc. HN community is just changing in that direction as the audience grows.
I've actually been surprised by this assumption - while the community in general sways to the heavily technical side of things; there are plenty of entrepreneurs, idea men, new developers etc - which is great, but definitely something to keep in mind with regard to what the community might find interesting.
I thought it might be that one instead, but I wasn't sure.
So why did Fluidity get more upvotes? Here's my opinion:
1. Fluidity had a better subject line - I knew immediately what it was about and I was very curious. Linkbait? Sure, but it worked.
2. Fluidity demonstrated the concept immediately on click through - I didn't need to muddle through a clever metaphor to figure out the concept. I saw it immediately.
3. Fluidity used a kitten. People like kittens unless they are bad people. - it may sound like I'm making a joke but I'm not. "Kittens" are any facial image that triggers what Konrad Lorenz referred to as Kindchenschema. http://en.wikipedia.org/wiki/Cuteness It is a common trick in advertising and marketing. Fluidity uses it perfectly.
By contrast, MoshPit's README is complicated.
The density of the text alone is likely to be off putting to 90% of the intended audience. I gave it a serious read myself because I was curious about your question. I am still wondering what it is for.
To provide a bit more context, I have been a developer for more than 30 years. More of a hobbyist the last 10, but I regularly pick up new frameworks for fun. Last summer I ran through all the latest js frameworks (ember, angular, backbone, etc), so I'd say MoshPit is something I should be interested in but I'm not entirely sure why it matters to me.
Please know that this is not a reflection on you personally or on the project itself. I am just providing an opinion based on my impressions upon entering the page and trying to decipher what you were trying to accomplish.
I understand and I agree, I tried to spell it out as simply as possible and put the demos at the forefront for the project, but it's hard explaining a new approach to solve and old problem in a simple way without getting verbose.
I think I need a prettier demo with "tips" and "hints" about what exactly is different... 90% of people will click through the demo, see nothing they haven't seen before and move on, which is a shame.
Yep, taking the complex and making it simple is never easy.
Sometimes it's about dialing back on features. Sometimes it's about kittens.
Don't get frustrated though. Take each opportunity as a chance to learn and experiment.
I've often wondered what would happen if someone launched three identical projects on github with totally different approaches to marketing. I suppose one could compliance this with multiple versions of the README, but I'd go as far as testing different names too.
I suspect some may see this as a heretical approach to open source development, but it's naive to think that any group of people are somehow resistant to marketing techniques.
Anyway, the key is having a great product. Keep at it and eventually you'll be able to explain it in a single sentence that makes the concept instantly clear.
In this example, I'd say his title was more compelling, and more applicable to more people. Try reposting your link with a title that will appeal to more people? (read: link bait)
I've come to a similar conclusion that using @media incantations only covers the basic cases, so any advanced web layout would need a mix of CSS and JS anyway (so we might as well have a solid JS toolkit help us keep things flexible and tidy).
Exactly, the problem becomes managing view logic in conjunction with @media queries. If you app fundamentally changes how it works and how it looks, you're stuck managing that logic in 2 places. You don't want to manage the view logic in JS and you can't manage the application logic in CSS without some kind of standard system. That was the goal for MoshPit, to integrate easily and allow management of both at the CSS layer.
You don't have to
if (window.is_mobile() && this.$left_thing.css('display') == 'block') {
this.$left_thing.hide();
this.$right_thing.show();
} else if (window.is_tablet() && this.$left_thing.css('display' == 'block') {
this.$left_thing.css('left','-100px');
this.$right_thing.show().css('left','0');
} else if (i_hate_my_life) ...
Because managing it in the code, through QA, and receiving the email subject line:
"We're adding a new component to the application, it will only be shown like this when this thing is happening and on mobile it will be able to show here, but not here, only if this thing is shown, and since it' launches from this we'll need these things to do this."
Doesn't cause more nested if else switch case statements to further complicate the code.
Off-topic, but: I love the feeling of seeing a new TLD for the first time. I immediately start thinking about possibilities and everything seems golden for a while.
Funny that you mention it, I get what you mean.
Its a bit like the sequence from "once upon a time in the west", where the camera goes over a hill, showing all the unclaimed land, the workers building the new railway etc. Epic scenery of a land of opportunity, golden afternoon sun rays, with a grand Ennio Morricone soundtrack playing.
I love this idea - I no longer like using Twitter Bootstrap because it's just so huge! And 90% of the time I find myself creating an override file to style it to my websites feel.
I do love their grid system though, does anyone know of a great lightweight grid system that's robust like Bootstrap's?
Edit: when I originally posted this, it was a fork of https://github.com/aekaplan/grid -- which I did not write (tried to express that via "when I first saw it", but in hindsight was not clear). I've since changed it at the original author's request. Apologies for any confusion!
Not only should you be overriding stuff, but nowadays they include the LESS files (with Bower at least) so in essence you can pick and/or rewrite the parts you want.
The complaint that Bootstrap is so huge is no longer valid, people are just super lazy.
That's my take as well... imho, you should be using bootstrap from the source... I usually start with the source, copy the mixins and variables files, and then create a new main less file that references all the parts I need with my copy of mixins/vars... works out really well, and less need to worry about new versions.
I've used http://weice.in/ivory/index.html before and liked it. However, I don't do much web-design, so I can't really comment on how good or bad it is, just that I've found it useful in the past.
It's a good start to getting properly responsive websites. A lot of times this really is all that's needed. But sometimes more complex solutions are needed for certain elements.
The CSS file could be more minimal if "@charset "UTF-8";" were removed. The only reason this is required is because of the UTF-8 character in the comment.
If you're working for the sort of company that would go out of it's way to block all URLs which have the string "sex" in them, you've got bigger problems than not being able to view website.
Many years ago when I was doing .NET programming, a helpful resource was http://systemwebmail.com/. Predictably, the firewall at $CORP blocked /webmail/. I had to print it at home and bring it into work.
Agreed. For me the most important this is load time -- if it takes more than a few seconds, I move on well before even the best of current responsive solutions have a chance to load and do their magic. This doesn't address that entirely, especially in the case of large images or heavy iFrames, but at least I can start reading almost immediately. Also, navigation would still be a struggle with this solution, though just a list with display:inline would be functional.
Reminds me of that annoyingly pious vanilla-js site from a while back.
Yes, HTML is 100% responsive out of the box, something so well understood, it nary even warrants mention. We are so far past that part of understanding that our conversations surround polishing appearance to the nth level. We don't fiddle with CSS because we don't need to; we do it for the 1% of cases HTML alone isn't enough. So congrats on writing your first reset, something literally every web developer has already done in their lifetime.
It's shame that HN, a technical community, still doesn't have a good responsive design.. and even design at all.. I'm always bit confused when viewing the site :(
It is obvious the browsers will try to stick all content into the view port by default. Too bad the web doesn't consist of vertical pages with no alignment whatsoever.
I'm not sure why the CSS needs to be declared as containing UTF-8 since all the characters of the file are part of the US-ASCII range.
Use the .overflow-container on tables and pre/code blocks. "-webkit-overflow-scrolling" seems to be useful to allow horizontal scrolling on overflow elements on iOS [1].
* [1]: http://stackoverflow.com/questions/15605085/webkit-overflow-...