Hacker News new | comments | show | ask | jobs | submit login

I am very surprised that so many people are not complaining about Mobile Safari's missing automatic word wrap feature. This is the number one reason why people want to use apps for anything (because their mobile browser is just broken). With word wrap like you get on Android's browsers most traditional desktop websites are totally sufficient on mobile devices, there's even no need for a mobile web version (HN is the best example).

Some could think that Apple is indirectly pushing an app ecosystem with its broken mobile browser experience and I am just seeing excited folks traveling to some worldwide dev conferences and building shitty apps for every and anything. For end users there isn't often any additional benefit and for developers building a native app is a nightmare -- software development like 20 years ago, long release cycles, different platforms and on top one gatekeeper deciding about your fate, wtf and no thanks. No surprise that most mobile first and only startups are struggling like living crap.

Web based apps are still the way to go for most use cases, just check the awesome mobile versions of Airbnb and LinkedIn, both based on Node, fast and ultra responsive. Building native apps belongs to the traditional publisher business model and are good for games and interaction heavy use cases (Facebook, communication, photo sharing, etc.).

EDIT: downvoting != disagreeing




Because word wrap and fluid layout are design decisions made by web developers and designers, NOT the web browser. Fluid layouts work just fine on iOS and wrap as expected. IMO the decision by Apple to scale a site's layout proportionally without breaking the intended layout is a valid one.


And with this decision you break 99% of the web on mobile devices.

It's a tiny thing to override this CSS property and makes mobile browsing of desktop sites so more convenient -- there's is no difference between Chrome on a mobile device and Chrome on desktops in terms of speed and usability of sites. In contrast, using the web browser on iOS is a real pain considering that Apple forbids to install any other rendering engine.

And if you don't like the text reflow just turn it off, it's optional on Android. Finally, it's a much better solution for visually impaired people since you can scale the fonts quickly as big as you want and the text just reflows. This even works on mobile sites since you can override zoom locks. There are so many benefits Apple just ignores with their "design decision" (mainly driven by commercial interests in favorite of the app store).


> And with this decision you break 99% of the web on mobile devices.

There's nothing broken about it. You can zoom in just fine; you just have to scroll back and forth, much like if you had a desktop browser opened to a tiny size.

What you describe is "broken" is actually conforming to HTML and CSS spec; Android is the one that's technically "broken". Internet Explorer had a knack for creating "features" that broke spec, too, and look how that turned out.

> Finally, it's a much better solution for visually impaired people since you can scale the fonts quickly as big as you want and the text just reflows.

Again, accessibility has always been the responsibility of the the web designer and developer. Do you also expect web browsers to analyze images and generate missing alt text? (That would actually be pretty cool, but again, there shouldn't be an expectation for it).

I understand why Android has chosen to include those features, but by doing that, they're potentially breaking the UX that the web designers expect the user to have.

It really has nothing to do with commercial interests and everything to do with separating the responsibilities of the web browser and the web developer.

EDIT: I'm not saying that Android is wrong for including that functionality, but to say that people should be up-in-arms at Apple for not including spec-breaking functionality is a bit ridiculous.


Scrolling back and forth to read each line sounds pretty broken to me. On the desktop, if I had something open in a small window I'd probably pull out Firebug and "fix" the css.

Personally I'm a believer in the original scheme where the site provided the content and it's largely up to the user agent to decide how to present it. This whole "Every rendering engine should create the exact same rendering of the page down to the pixel" is super useful for web apps and stuff, but most of the time I just want to read stuff. Honestly, I'm surprised there's no web browser that just runs the Readable scriptlet on any page that looks like an article by default.


I think it's a bad decision. In order to read the text, I need to zoom in. But I can only zoom in on a part of the page, so I need to scroll sideways back and forth to read the beginning and end of lines in the same paragraph.

It's a bad decision. I should be able to size and flow the page to fit my display, wrapping it appropriately.

Yes, the designer should a layout that does this for mobile devices anyway. But the phone should also make it possible to sensibly read sites that don't.


Setting a static div width should not be undefined behavior for developers. It creates a situation where, if a mobile browser breaks the layout of a site in order to wrap text, the developer then has to go back and create a workaround for a single browser.


People are also not complaining about Apples implementation of Retina, whereas they just double pixels, instead of properly interpolating. They then go around and complain your website looks crap on Retina.


I read dozens of sites on mobile Safari that have wrapped text. There must be a solution. Example

http://m.sfgate.com/sfchron/index.htm


That's not wrapped text, it's a mobile layout. Also if the layout is fluid it's wrapped quite nicely by mobile Safari.

What I assume Android browsers have is something like Opera mobile, which force-wraps all text no matter how the site is coded.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: