This makes a nice demo and highlights that in some ways, iOS 7 is easier to reproduce using web technology than iOS 6 was.
> There’s been a lot of controversy recently on whether Javascript could compete with native or not, both in terms of performance and of look’n’feel.
On the other hand, the controversially difficult to reproduce parts of iOS 7 aren't part of this demo. The real-time blur, the zooming "z-axis" navigation, the 3D animations, and the 60fps scrubbable gestures for going back in the navigation stack aren't here.
While those are all "bonus effects," they're also a lot of what makes iOS 7 delightful to use.
Actually, I don't think JS can really compete with native, that's not the point I'm trying to make in this article.
Nonetheless, webapps can be an acceptable tradeoff for small apps, that are not too resource-intensive. In such cases, I think HTML, CSS and JS can give good enough results.
Since iOS6 and iOS7 have different looks and feels, it is apparent that rigidly adhering to the one true native look and feel isn't mandatory. I'll bet HTML5 can get closer to either iOS version than they are to each other and so close that I, an iPhone user, wouldn't notice the difference for the kind of app that doesn't require native hardware access. I'll bet that someone will produce an HTML5 mobile UI that I'll like more than I'll like iOS7. I'll bet that this won't be the last iOS UI overhaul, and that some future Apple TV will have yet another "native look and feel" and that iPhone owners will use their TVs and Kindles and smart refrigerators and countless Web apps and eventually lose track of what "the native look and feel of an iPhone" looks and feels like.
I think there's an argument either way on this, though. Even with a simple app, some would say looking very similar to native but being 1% off can be more detrimental to the experience than executing very well on a different, more HTML/CSS/JS-friendly approach.
That being said, I think this would be an interesting thing to start seeing around the web!
You're entirely right.
I'm just used to the old way, but I guess I'm a bit of an eccentric.
I'll try to update the repo asap.
(Anyway, I think the HTML architecture could be streamlined, my point was more to demonstrate the css possibilities)
And you did a really great job with the CSS. But I know that many young people who are starting with HTML/CSS will be hugely impressed by your examples and will try to copy them. And because they see the div-soup in your examples they will assume that this is how you're supposed to write modern HTML. In the end they see the most modern look in the examples, so I wouldn't even blame them for thinking like that.
It would be sad if they learned to write non-semantic HTML and I think we all who write examples on the net should try to write great examples :)
And in fact we should do it with all the HTML which is online because we all learned HTML and CSS from right click "View Page Source" :D
Note that opinions differ on this. Personally I think semantic HTML is nothing but meeting-bait. If you try to be diligent about it you end up in discussions and meetings around whether a certain element should be a figcaption tag should be used or aside etc... And at the end of these types of discussions, regardless of the outcome, nothing that has any actual effect has been changed. It will make zero practical difference whether you use semantic HTML or not. The only thing seemingly affected are imaginary mobile devices that render <nav> differently than <div> or imaginary screen readers that can't read text unless it's in a <figcaption> tag.
It kind of sounds like saying: "Why should I learn math, I will never use it anyway." It might be true, but that is not a good excuse for not learning it. And it is not like using semantic HTML is in any way more work or something, it at least has the benefit of being easier to read and thus maintain.
That's very different. Because there are circumstances where not knowing or applying math is a barrier to accomplishing something. Saying "Why should I learn math, I will never use it anyway." means you're banking on the odds that you will never run into those circumstances.
However when it comes to semantic HTML there is no circumstance where you are unable to move forward because you used <div> instead of <figcaption>.
In fact thanks to the sometimes ambiguous descriptions of which semantic tag is appropriate you may find you used the wrong semantic tag which is arguably worse than not using a semantic tag at all.
And at the end of the day after carefully cross referencing and/or memorizing which semantic tag to use throughout your markup zero real world, practical effect has been gained. Only theoretical gains and memorization for memorization's sake.
It sounds like to be save one should only use <div> and <span> tags, style them with CSS and forget about semantics?
It is obvious to me that this is the wrong approach. And I have never said he should use <figcaption> I said he should use appropriate HTML5 tags. If something is obviously a header, use <header> if not, don't. But building everything out of <div>s like it was in his first example code is just making it more difficult to read, there is no gain in just using <div> for everything.
btw. I wonder if this would also work as smooth as it does now in webkit, when you would add all the -moz- to it and then test it on a Firefox OS phone.
Mmmh, I'd love to hear a feedback if someone does that. I don't have a firefox OS phone, so I can't tell, but I tested it on an iPhone 4 with iOS 7 beta 6 and I think it's a limit.
Of course iOS 7 is not the lightest system on earth but even on more optimized OS like iOS 6, I think the weakest hardware will struggle to process it correctly.
Runs smooth, comparable with Firefox Desktop Browser. But the scrollMask doesn't fade nicely and I have no clue why this happens. You can reproduce it using regular Firefox Browser (use Tools > Web Developer > Responsive Design View).
If you inspect the page It appears they are generating a blurred version of the png on the fly in js. The source of the blurred version of the image is equal to
"data:image/png;base64,iVBOR…7WkYklgQdZAAAAABJRU5ErkJggg=="
while the none blurred version is https://beta.icloud.com/system/cloudos/1SBeta.102619/en-us/s...
Check out
http://www.appgyver.com/steroids
It's still in it's early stages but looks very promising. It gives you native navigation and transitions, amongst other many other goodies.
Nice attention to detail in this. By the way, it seems like the new view's shadow in the original actually loses opacity as that view leaves the screen.
Did you look around for the blur effect at all? You mentioned it but any luck beyond that? I've seen some attempts but nothing useful.
Yeah, the iOS 7 'frosted glass translucency is impossible to achieve with CSS. Everyone points to filter: blur(), but that only blurs the element, and not items behind it.
The only thing I could come up with was using something like HTML2Canvas[1] to render a portion of the DOM in a canvas/image, position that exactly on top, and then blur that. But all that seems quite convoluted and heavy, so decided not to invest any energy into it.
I've looked into this as well. At the moment it is impossible to achieve this effect in plain HTML/Javascript/CSS. It would probably need some Canvas/WebGL magic to work for live content below the navigation bar, but that feels like overdoing it. Achieving blur in CSS is possible, but it's different - you apply blur to an element itself, not to a background of element that covers it.
Yes, I've seen it an a few others demos.
But the difficulty here is to make the content blurred while it scrolls. It's extremely smooth on iOS 7 beta and I can't see anyway to reproduce properly in HTML without severely compromising the performances.
I think this is actually possible if you use synthetic scrolling (i.e. interpret touch events, compute intertia and use translate3d + requestAnimationFrame). You'd basically have 2 copies of the content area, one blurred w/ css and one not blurred. Render the blurred one above the non blurred one and scroll them in lock step.
You can probably get ok performance if you don't have a lot of images.
A high quality implementation of synthetic scrolling is available at http://github.com/zynga/scroller if you want to play with it.
Hmm, I've tried something like that (although not as elaborate), but it really was sluggish...
It may work but I think you should at least need an iPhone 4S or 5.
As I said, it's hard/close to impossible to reliably achieve this effect for live content. With static content you can use CSS filters to do the blurring.
Fantastic post, thanks for sharing! I'm invested pretty heavily in HTML5 on mobile and your demo just reassures me this is the future (it feels great!). I hope you don't mind me using some of this stuff for a new project I'm working on.
As someone using that app, I would love the option to keep the old interface.
Having web-apps trying to mimick a platform I don't use just feels wrong. In much the same way as those fake Windows-UI images ("Scan complete. 3 viruses found!") used all over the internet trying to trick noobs into installing malware.
Whenever I click on anything it layers the new elements behind the other ones and the whole interface becomes unresponsive. It works for others though, and it's pretty and iOSey, so props on that.
Pretty cool. I know this is more of a demonstration of simulating the iOS 7 UI, but I'm assuming to use this for something you'd want the URLs to update as you move through an app?
I may have missed references to this limitation, again, if it even matters for the purpose of the post.
I've actually designed it with a Phonegap integration in mind, to be honest.
I think it's possible but you'd probably have to add a great deal of complexity to the code. I'm not familiar with Backbone.js, but may be you can use it to implement routing?
> There’s been a lot of controversy recently on whether Javascript could compete with native or not, both in terms of performance and of look’n’feel.
On the other hand, the controversially difficult to reproduce parts of iOS 7 aren't part of this demo. The real-time blur, the zooming "z-axis" navigation, the 3D animations, and the 60fps scrubbable gestures for going back in the navigation stack aren't here.
While those are all "bonus effects," they're also a lot of what makes iOS 7 delightful to use.