594 karma · joined August 21, 2008
http://cubiq.org/remove-onclick-delay-on-webkit-for-iphone
It uses event capturing so you can bind the listener to an outer div containing many buttons, rather than each button individually.
As for your last point though... lolwut. iOS was just an example, the same is true for consoles, other app markets, etc. iOS apps bear "no weight" in the statement that a proprietary platform causes slow time to market?! iOS is one of the largest and most developed-for proprietary platforms, which makes it a great example, which means it absolutely does bear weight -- and a lot of weight at that -- in a statement that generalizes proprietary platforms. </semantics>
- Want to port your game to a new platform (game console? embedded device?) - just get webkit/mozilla/<your favorite open source browser> to compile. Although this is no small task, in many cases it can be easier and way faster than rewriting the code for an entire game. not to mention this mandates one port per console, rather than one port per game per console. N^2->N time savings :D
- Not being controlled by a single corporation is incredibly important. Take iphone games: want to update your game to use some newly released feature of the sdk? Get ready for 1+ weeks of waiting for approval. Notice a low-level bug in the sdk? ha-ha, have fun talking to Apple's technical support. These are the obvious reasons, there are a million-and-one examples as to how limited access can slow down - and even halts - the game development process.
That's all I have time for now, I'll try and think of some more later
Edit: too/to
My favorite features:
- auto-insert vendor prefixes, even IE filters (no need for css3 'mixins', which are most of the mixins the avg dev will need)
- can even rasterize linear-gradient backgrounds and serve as image for more pre-css3 browser support. This one I haven't tested but it sounds awesome
Edit: paragraph formatting
rvm implode curl -L get.rvm.io | bash -s stable
source ~/.bash_profile
rvm install 1.9.3
gem install railsHowever the above article references iOS 4.2, so I am wondering if any of these are fixed in iOS 5
I agree that it is best to let the browser handle the scrolling mechanics. Then you simply hide the original scrollbar by having an embedded div hold the content with a width thats about 40px or so bigger than the outer, fixed width div ( and overflow: scroll-y ).
Edit: changed direct link to YC link.
Drop me an email at joe@nearish.com if you'd like to talk, I am interested in your solution to scaling.
One thing that is interesting is how Apple's Industrial Design team, mentioned in the post, affected the design of the new Macbook power adaptors (like the one you linked to, http://www.cl.ly/0r2n2S2z1b3K0L1E0R3t). The old ones had the cord coming out perpendicular to the laptop. I liked that design a lot better than the new style, which is a bit awkward to plug in and leaves you either:
1. With a cord facing out the back of the laptop, then (probably) looping around 180 degrees and back to the power outlet, or
2. With the cord running parallel next to the laptop, completely blocking the ethernet port.
Obviously neither of these solutions is streamlined or Apple-like, so I wonder if the ID dept made the trade-off of a parallel connector with minimal strain relief, or a perpendicular connector with built-in strain relief.