Tags: safari

49

sparkline

Saturday, November 10th, 2018

Redesigning your product and website for dark mode — Stuff & Nonsense

Some advice from Andy on creating a dark theme for your website. It’s not just about the colours—there are typography implications too.

Sunday, October 28th, 2018

Phil Nash and Jeremy Keith Save the Safari Video Playback Day

I love this example of paying it forward:

Friday, October 26th, 2018

Service workers and videos in Safari

Alright, so I’ve already talked about some gotchas when debugging service worker issues. But what if you don’t even realise the problem has anything to do with your service worker?

This is not a hypothetical situation. I encountered this very thing myself. Gather ‘round the campfire, children…

One of the latest case studies on the Clearleft site is a nice write-up by Luke of designing a mobile app for Virgin Holidays. The case study includes a lovely video that demonstrates the log-in flow. I implemented that using a video element (with a poster image). Nice and straightforward. Super easy. All good.

But I hadn’t done my due diligence in browser testing (I guess I didn’t even think of it in this case). Hana informed me that the video wasn’t working at all in Safari. The poster image appeared just fine, but when you clicked on it, the video didn’t load.

I ducked, ducked, and went, uncovering what appeared to be the root of the problem. It seems that Safari is fussy about having servers support something called “byte-range requests”.

I had put the video in question on an Amazon S3 server. I came to the conclusion that S3 mustn’t support these kinds of headers correctly, or something.

Now I had a diagnosis. The next step was figuring out a solution. I thought I might have to move the video off of S3 and onto a server that I could configure a bit more.

Luckily, I never got ‘round to even starting that process. That’s good. Because it turns out that my diagnosis was completely wrong.

I came across a recent post by Phil Nash called Service workers: beware Safari’s range request. The title immediately grabbed my attention. Safari: yes! Video: yes! But service workers …wait a minute!

There’s a section in Phil’s post entitled “Diagnosing the problem”, in which he says:

I first thought it could have something to do with the CDN I’m using. There were some false positives regarding streaming video through a CDN that resulted in some extra research that was ultimately fruitless.

That described my situation exactly. Except Phil went further and nailed down the real cause of the problem:

Nginx was serving correct responses to Range requests. So was the CDN. The only other problem? The service worker. And this broke the video in Safari.

Doh! I hadn’t even thought about service workers!

Phil came up with a solution, and he has kindly shared his code.

I decided to go for a dumber solution:

if ( request.url.match(/\.(mp4)$/) ) {
  return;
}

That tells the service worker to just step out of the way when it comes to video requests. Now the video plays just fine in Safari. It’s a bit of a shame, because I’m kind of penalising all browsers for Safari’s bug, but the Clearleft site isn’t using much video at all, and in any case, it might be good not to fill up the cache with large video files.

But what’s more important than any particular solution is correctly identifying the problem. I’m quite sure I never would’ve been able to fix this issue if Phil hadn’t gone to the trouble of sharing his experience. I’m very, very grateful that he did.

That’s the bigger lesson here: if you solve a problem—even if you think it’s hardly worth mentioning—please, please share your solution. It could make all the difference for someone out there.

Sunday, September 9th, 2018

“Killing the URL” | CSS-Tricks

URLs are the single greatest feature of the web.

Saturday, September 1st, 2018

The Ecological Impact of Browser Diversity | CSS-Tricks

This is a terrific spot-on piece by Rachel. I firmly believe that healthy competition and diversity in the browser market is vital for the health of the web (which is why I’m always saddened and frustrated to hear web developers wish for a single monocultural rendering engine).

Tuesday, July 10th, 2018

Twitter and Instagram progressive web apps

Since support for service workers landed in Mobile Safari on iOS, I’ve been trying a little experiment. Can I replace some of the native apps I use with progressive web apps?

The two major candidates are Twitter and Instagram. I added them to my home screen, and banished the native apps off to a separate screen. I’ve been using both progressive web apps for a few months now, and I have to say, they’re pretty darn great.

There are a few limitations compared to the native apps. On Twitter, if you follow a link from a tweet, it pops open in Safari, which is fine, but when you return to Twitter, it loads anew. This isn’t any fault of Twitter—this is the way that web apps have worked on iOS ever since they introduced their weird web-app-capable meta element. I hope this behaviour will be fixed in a future update.

Also, until we get web notifications on iOS, I need to keep the Twitter native app around if I want to be notified of a direct message (the only notification I allow).

Apart from those two little issues though, Twitter Lite is on par with the native app.

Instagram is also pretty great. It too suffers from some navigation issues. If I click through to someone’s profile, and then return to the main feed, it also loads it anew, losing my place. It would be great if this could be fixed.

For some reason, the Instagram web app doesn’t allow uploading multiple photos …which is weird, because I can upload multiple photos on my own site by adding the multiple attribute to the input type="file" in my posting interface.

Apart from that, though, it works great. And as I never wanted notifications from Instagram anyway, the lack of web notifications doesn’t bother me at all. In fact, because the progressive web app doesn’t keep nagging me about enabling notifications, it’s a more pleasant experience overall.

Something else that was really annoying with the native app was the preponderance of advertisements. It was really getting out of hand.

Well …(looks around to make sure no one is listening)… don’t tell anyone, but the Instagram progressive web app—i.e. the website—doesn’t have any ads at all!

Here’s hoping it stays that way.

Friday, April 20th, 2018

Timing

Apple Inc. is my accidental marketing department.

On April 29th, 2010, Steve Jobs published his infamous Thoughts on Flash. It thrust the thitherto geek phrase “HTML5” into the mainstream press:

HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member.

Five days later, I announced the first title from A Book Apart: HTML5 For Web Designers. The timing was purely coincidental, but it definitely didn’t hurt that book’s circulation.

Fast forward eight years…

On March 29th, 2018, Apple released the latest version of iOS. Unmentioned in the press release, this update added service worker support to Mobile Safari.

Five days later, I announced the 26th title from A Book Apart: Going Offline.

For a while now, quite a few people have cited Apple’s lack of support as a reason why they weren’t investigating service workers. That excuse no longer holds water.

Once again, the timing is purely coincidental. But it can’t hurt.

Wednesday, March 21st, 2018

Elephant - WordRidden

We went on a safari after the Pixel Up conference in South Africa. It was an amazing experience …but there was also The Elephant Incident.

And now I don’t need to write about it because I could never come close to recounting it as brilliantly as Jessica has done here.

The darkness closed in quickly as we rattled along the trail, the flashbulb lightning not doing much to supplement the juddering glow of the headlights. We were, by all appearances, a happy and relaxed little group, pleased with the day’s sightings, mellowed out by the evening’s drinks, looking forward to a nice dinner with wine and then a good night’s sleep. But I kept thinking about the elephant encounter from the night before—and so, apparently, did young Tas, who was bundled up next to his dad and eventually said quietly: “I don’t want to see another elephant.” We all comforted him with false bravado: no, don’t worry, there won’t be any elephants, we’re fine, it’s all fine, everything is totally fine. And all the while I was peering into the trees, and attempting to gauge the relative freshness of the huge piles of elephant dung on the road, and really, really not wanting to see an elephant either.

Thursday, January 25th, 2018

Safari 11.1

Squee! The next time there’s an update for OS X and iOS, Safari will magically have service worker support! Not only that, but Safari on iOS will start using the information in web app manifests for adding to home screen.

That’s an impressive turnaround.

Thursday, December 21st, 2017

Release Notes for Safari Technology Preview 46 | WebKit

Well, that escalated quickly! Service workers are now available in Safari’s Technology Preview, which means it won’t be long before it lands in Safari proper.

Also: service workers also just landed in the insider release of Edge.

Everything offline’s coming up Milhouse!

Thursday, October 19th, 2017

The Story of CSS Grid, from Its Creators · An A List Apart Article

It must be the day for documenting the history of CSS. Here’s an article by Aaron on the extraordinary success story of CSS Grid. A lot of the credit for that quite rightly goes to Rachel and Jen:

Starting with Rachel Andrew coming in and creating a ton of demos and excitement around CSS Grid with Grid by Example and starting to really champion it and show it to web developers and what it was capable of and the problems that it solves.

Then, a little bit later, Jen Simmons created something called Labs where she put a lot of demos that she created for CSS Grid up on the web and, again, continued that momentum and that wave of enthusiasm for CSS Grid with web developers in the community.

Thursday, September 21st, 2017

Removing the White Bars in Safari on iPhone X

You could add a bunch of proprietary CSS that Apple just pulled out of their ass.

Or you could make sure to set a background colour on your body element.

I recommend the latter. Because reasons.

Thursday, August 24th, 2017

Malte Ubl on Twitter: “🙏🏿 to @sebabenz for testing that this isn’t an AMP special case. Safari now defaults to sharing the canonical URL 👏🏾

If Safari is updating its “share” functionality to look for canonical URLs, then that should work not just for AMP pages, but also Medium posts that include a canonical URL (like the ones created by posting to the Medium API, which is what I’m doing).

Thursday, August 3rd, 2017

Attachment #317095 for bug #175115

I’ve never been so excited by a single diff in a JSON file.

Service workers are coming to Safari.

Sunday, June 11th, 2017

With New Browser Tech, Apple Preserves Privacy and Google Preserves Trackers | Electronic Frontier Foundation

It’s interesting to see how excessive surveillance is (finally!) being treated as damage and routed around. Apple seem to get it—they’re tackling the tracking issue. Meanwhile Google are focusing purely on the visibility and UX of invasive advertising, without taking steps against tracking.

There’s a huge opportunity here for Chrome’s competitors—if Firefox and Safari protect users from unwarranted tracking, that could be enough to get people to switch, regardless of the feature sets of the browsers.

Tuesday, June 6th, 2017

Intelligent Tracking Prevention | WebKit

This is an excellent move by Apple—interpreting cross-site tracking as damage and routing around it.

Friday, May 27th, 2016

» Autofill: What web devs should know, but don’t

Jason takes good look at the browser support for autocomplete values and then makes a valiant attempt to make up for the complete lack of documentation for Safari’s credit card scanning.

Tuesday, April 26th, 2016

Updating Our Prefixing Policy | WebKit

Ted has snuck a blog post out from behind Apple’s wall of silence, and it’s good news: WebKit is not going to use vendor prefixes for new features.

Wednesday, March 23rd, 2016

The web on my phone

It’s funny how times have changed. Remember back in the 90s when Microsoft—quite rightly—lost an anti-trust case? They were accused of abusing their monopolistic position in the OS world to get an unfair advantage in the browser world. By bundling a copy of Internet Explorer with every copy of Windows, they were able to crush the competition from Netscape.

Mind you, it was still possible to install a Netscape browser on a Windows machine. Could you imagine if Microsoft had tried to make that impossible? There would’ve been hell to pay! They wouldn’t have had a legal leg to stand on.

Yet here we are two decades later and that’s exactly what an Operating System vendor is doing. The Operating System is iOS. It’s impossible to install a non-Apple browser onto an Apple mobile computer. For some reason, the fact that it’s a mobile device (iPhone, iPad) makes it different from a desktop-bound device running OS X. Very odd considering they’re all computers.

“But”, I hear you say, “What about Chrome for iOS? Firefox for iOS? Opera for iOS?”

Chrome for iOS is not Chrome. Firefox for iOS is not Firefox. Opera for iOS is not Opera. They are all using WebKit. They’re effectively the same as Mobile Safari, just with different skins.

But there won’t be any anti-trust case here.

I think it’s a real shame. Partly, I think it’s a shame because as a developer, I see an Operating System being let down by its browser. But mostly, I think it’s a shame because I use an iPhone and I’m being let down by its browser.

It’s kind of ironic, because when the iPhone first launched, it was all about the web apps. Remember, there was no App Store for the first year of the iPhone’s life. If you wanted to build an app, you had to use web technologies. Apple were ahead of their time. Alas, the web technologies weren’t quite up to the task back in 2007. These days, though, there are web technologies landing in browsers that are truly game-changing.

In case you hadn’t noticed, I’m very excited about Service Workers. It’s doubly exciting to see the efforts the Chrome on Android team are making to make the web a first-class citizen. As Remy put it:

If I add this app to my home screen, it will work when I open it.

I’d like to be able to use Chrome, Firefox, or Opera on my iPhone—real Chrome, real Firefox, or real Opera; not a skinned version of Safari. Right now the only way for me to switch browsers is to switch phones. Switching phones is a pain in the ass, but I’m genuinely considering it.

Whereas I’m all talk, Henrik has taken action. Like me, he doesn’t actually care about the Operating System. He cares about the browser:

Android itself bores me, honestly. There’s nothing all that terribly new or exciting here.’

save one very important detail…

IT’S CURRENTLY THE BEST MOBILE WEB APP PLATFORM

That’s true for now. The pole position for which browser is “best” is bound to change over time. The point is that locking me into one particular browser on my phone doesn’t sit right with me. It’s not very …webby.

I’m sure that Apple are not quaking in their boots at the thought of myself or Henrik switching phones. We are minuscule canaries in a very niche mine.

But what should give Apple pause for thought is the user experience they can offer for using the web. If they gain a reputation for providing a sub-par web experience compared to the competition, then maybe they’ll have to make the web a first-class citizen.

If I want to work towards that, switching phones probably won’t help. But what might help is following Alex’s advice in his answer to the question “What do we do about Safari?”:

What we do about Safari is we make websites amazing …and then they can’t not implement.

I’ll be doing that here on adactio, over on The Session (and Huffduffer when I get around to overhauling it), making progressively enhanced, accessible, offline-first, performant websites.

I’ll also be doing it at Clearleft. If you work at an organisation that wants a progressively-enhanced, accessible, offline-first, performant website, we should talk.

Monday, January 11th, 2016

Without delay

When I wrote about mobile Safari adding support for touch-action: manipulation, I finished with this snarky observation:

Anyway, I’m off to update my CSS even though this latest fix probably won’t land in mobile Safari until, oh ….probably next October.

Historically, Apple have tied mobile Safari updates to iOS version number increments, and they happen about once a year. But this time, it looks like my snark was unfounded:

On Safari for iOS, the 350 ms wait time to detect a second tap has been removed to create a “fast-tap” response. This is enabled for pages that declare a viewport with either width=device-width or user-scalable=no. Authors can also opt in to fast-tap behavior on specific elements by using the CSS touch-action property, using the manipulation value.

That’s from the release notes for Safari 9.1—a point release.

I’m very pleased to have been absolutely wrong with my prediction of Apple’s timing.