61–70 of 127 posts
Mozilla/5.0 (Mobile; rv:31.0) Gecko/31.0 Firefox/31.0
Edit: The previous title was "Windows Phone's IE starts masquerading as mobile Safari to render pages properly" Looks like the webkit prefix tags are creating the new IE6. As usual, it's the web developers fault for not updating their CSS prefixes. http://css.dzone.com/articles/why-webkit-new-ie6-trap-vendor Mozilla, Opera and Microsoft have been complaining about this and Opera had already implemented support for th…
On the one side I want to make a ramble about why it takes so long for those standards to finish and unprefixed CSS3 and beyond is possible, but on the other hand - without actual real-life use, how can you find all the edge-cases and practical application to create a complete standard?
Edit: The previous title was "Windows Phone's IE starts masquerading as mobile Safari to render pages properly" Looks like the webkit prefix tags are creating the new IE6. As usual, it's the web developers fault for not updating their CSS prefixes. http://css.dzone.com/articles/why-webkit-new-ie6-trap-vendor Mozilla, Opera and Microsoft have been complaining about this and Opera had already implemented support for th…
> Looks like the webkit prefix tags are creating the new IE6. This bothers me. Webkit isn't some ancient browser that is has remained stagnant for years until google/apple decided to do something about it. Nobody spends hours debugging their perfect layouts in webkit. Webkit isn't holding the entire web back. It's just a poor comparison. I browse mobile web in mostly firefox mobile, and I don't think I've ever seen a…
For a long time, IE6 ruled the roost, so developers used IE6 as their development target. Browsers that moved beyond it, or implemented things differently (often correctly) were ignored.
On mobile, webkit rules the roost. Developers use it as their development target. Browsers that move beyond it or implement things differently (by using non-webkit prefixed CSS) are ignored.
Why do you need to detect if mobile? Why aren't media queries enough?
Also, see this article:
http://www.smashingmagazine.com/2014/07/22/responsive-web-de...
The mobile web is just a disaster all around. I remember when I got my iPhone in '08, the browsing experience was amazing. Most sites were still relatively simple, and whatever highly non-standard tricks Safari played to do things like text reflow worked great on that small 3.5" screen. Half a decade later, I'm profusely disappointed with Chrome's browsing experience on my Nexus 5's massive 5" screen. Even on HN, I c…
I'd like to join you on this mobile rant for a bit. Mobile browsing completely sucks right now. Whether it's websites that don't know how (or don't bother) to design with mobile in mind, or websites that do try to design with mobile in mind, and go completely over the top to the point that it ruins UX (Why do we still see websites where you can swipe left/right to switch articles. Does anyone every actually need to swipe through blog posts that rapidly?) It feels like there are very few websites that don't outright ruin mobile browsing.
And even when you find one of the nice ones, your browser mucks it all up by thinking it is smarter than the web designers. "Font Boosting" makes Reddit and several forums I frequent completely unreadable for me. Even on the mobile versions of the sites! It seems to get worse as you go down the page, and after 30-40 comments, the font sizes might as well have been chosen completely at random.
The other day, my phone warned me of low internal storage, and I saw the Chrome app was taking up 225mb of space on my android, and this is not including the additional 100mb+ from cache and data. That's 10% of my internal storage! Could you imagine if Chrome for desktop took up 100GB? /endrant
Poor Windows Phone team. This is a symptom of the ecosystem's indifference to the windows phone platform. Browser vendors implementing hacks to trick web apps into presenting the right content because web developers have learned that they can't rely on the browser to render content properly. I think there's a lesson in here about treating your ecosystem right.
I actually don't think that's entirely fair to the Windows Phone team. Developers are being lazy and only testing on webkit devices.
Earlier quoted context omitted.
That query means nothing. Most of those results include the non-prefixed version as well. The prefixed one is there for backwards compatibility.
> That query means nothing. That query means developers by and large don't care and just cargo-cult through. > The prefixed one is there for backwards compatibility. Backwards compatibility with what, fucking Chrome 6? How many of these sites have been tested for backwards compatibility in Chrome 6? I'd bet it's somewhere around "none whatsoever".
Chrome won't remove them because it breaks these sites relying on the webkit prefix remaining - so there's sufficient ground there to indicate developers are failing. But it's not the developers who include the non-prefixed standardised version.
Yes, there are lots of developers who don't care - the ones who rely on the webkit-prefix support remaining. That is contrary to the spirit of vendor prefixes - experimental CSS properties that should not be relied on.
Those using both the webkit prefixed and the standard non-prefixed versions are using the typical graceful fallback - one that doesn't make other browsers "unsupported"
"In general, our advice is to develop a responsive site that can adapt to the capabilities of different devices. If you choose to build a mobile-specific experience then we recommend looking for the sub-string "mobile" in the user agent string to determine when to deliver mobile optimised content:" function isMobile() { return navigator.userAgent.toLowerCase().indexOf("mobile")>=0; } This is really the best we can do…
ug, that's already a bad check, but if they insist, why not just: /mobile/i.test(navigator.userAgent)
Just because the API call and syntax is a bit iffy doesn't mean it's a bad pattern. ES6 will finally have a string .contains method btw (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)
Earlier quoted context omitted.
The title is almost always changed if the post's title is different from the submission's title. There usually isn't a good reason to editorialize the title when submitting to HN, unless the title is something like a "Show HN." For anyone seeing this comment after the title has been changed, OP's title was "Windows Phone's IE starts masquerading as mobile Safari to render pages properly"
> For anyone seeing this comment after the title has been changed, OP's title was "Windows Phone's IE starts masquerading as mobile Safari to render pages properly" editorializing or not, i prefer the less vague title. serves as a great tldr;
Earlier quoted context omitted.
> Why do you blame developers? Because the fault lies with them and no one else, no matter how in denial you are. > The fault lies with the standards community for not standardizing much faster (at most a week after the second browser has support for that feature) That doesn't even make sense, standards work is not "you shipped some random unspecified and mostly broken pile of shit and some other bloke was convinced…
Do you have any backup for your arguments?
Co-Chairmain of the web standards group:
http://www.glazman.org/weblog/dotclear/index.php?post/2012/0...
Mozilla on the issue. http://alistapart.com/article/the-vendor-prefix-predicament-...