Hacker News Reader

Comment by zajd | Hacker News Reader

I could be swayed that iOS is easier to target than some other browsers but Chrome? You can definitely build a slider natively...

Maybe the confusion is that Chrome =/= Android Browser

View on HN

> You can definitely build a slider natively...

Nope http://caniuse.com/#search=snap

"Build natively" means to create it yourself in vanilla JavaScript, like this http://meandmax.github.io/lory/. What's the use of a native element that only one browser has when you need cross browser support anyway?

"Natively" as in 2 lines of CSS rather than yet another JS dependency. The cool thinks about CSS Snap Points is that they fall back rather gracefully on brothers that don't support them to just standard overflow scrolling.

Well that's not what native means. Beyond that, the issue isn't that Safari is not implementing HTML5 features fast enough, it's that they are choosing to not implement specific ones in order to protect their platform. You just don't see that from other browser vendors (today)

Isn't that the point of this article? I don't think it's fair to criticize Apple for lagging HTML5 support in iOS, then say "what's the use of this element?" when it cuts the other way.

The criticism isn't that they are lagging HTML5 support in iOS(although it would be valid- that's no reason to sue), it's that they are specifically avoiding parts of the implementation to protect their platform. Things like full screen support, notifications, etc

You don't need snap to build a slider natively. Also interestingly snap is NOT supported when Safari is rendering stuff in a different app, only when you're actually in the Safari App.

As the note says, WKWebView is an embeddable web view for apps. This is what iOS Chrome uses FWIW.

Doh, that is precisely the whole problem being discussed here.

WKWebView is a mess just like UIWebView.

Reply on news.ycombinator.com