Articles

Exciting New Features in Safari 16

,

Apple has released an OS update. Packaged in with it is the latest version of Safari, 16.

Expected to be released ahead of next month’s macOS 13, Safari 16 is packed with updates, making it one of the most capable browsers available.

For web designers, the significance is the forward momentum in web technologies that enable freer design work and fewer hacks to achieve complex layouts. Little by little, CSS recommendations are being implemented to the point that using JavaScript for layout is rapidly becoming as unnecessary as it is disliked.

Some of this was announced in June in the Safari 16 beta. But a lot has been added in the last couple of months. So here’s what’s new in Safari 16 today.

CSS Container Queries

The most exciting addition to Safari 16 is CSS Container Queries.

It is hard to understate how in-demand this feature has been; if you imagine an edit button on Twitter that gifted you crypto every time you corrected a typo, you’d be getting close to how popular this feature is.

Until now, media queries have detected the whole viewport. And so, if you have an element like a card, for example, that needs to change at smaller viewports, you need to calculate the available space and adapt the element’s design accordingly. Unfortunately, this frequently gets out of sync with edge cases causing more than a few headaches for front-end developers.

Media queries are severely restrictive to modern layout methods like Grid that wrap elements automatically because there is no way to detect how the elements are laid out.

Container Queries solve this by allowing you to define styles based on the size of the actual containing element; if a div is 300px wide, the contents can have one design, and if it’s 400px wide, they can have a different design—all without caring what size the whole viewport is.

This is dangerously close to OOP (Object Orientated Programming) principles and almost elevates CSS to an actual programming language. (All we need is conditional logic, and we’re there.)

The latest versions of Chrome, Edge, and now Safari (including mobile) support CSS Grid. Even discounting the rapid decline of Twitter, this is way more exciting than any edit button.

CSS Subgrid

Speaking of Grid, if you’ve built a site with it (and if you haven’t, where have you been?), you’ll know that matching elements in complex HTML structures often results in nesting grids. Matching those grids requires careful management, CSS variables, or both. With CSS Subgrid, grids can inherit grid definitions from a grid defined higher up the hierarchy.

CSS Subgrid has been supported by Firefox for a while but is not yet part of Chrome or Edge. Until there’s wider support, it’s not a practical solution, and using a fallback negates any benefit of using Subgrid. However, its introduction in Safari will surely herald rapid adoption by Google and Microsoft and moves the web forward considerably.

CSS Subgrid is likely to be a practical solution within 18 months.

AVIF Support

AVIF is an exceptionally compact image format that beats even WebP in many instances. It even allows for sequences, creating what is essentially an animated GIF but smaller, and for bitmaps.

AVIF is already supported by Chrome, with partial support in Firefox. Safari now joins them.

AVIF support is one of the more valuable additions to Safari 16 because you’re probably already serving different images inside a picture element. If so, your Safari 16 users will begin receiving a smaller payload automatically, speeding up your site and boosting UX and SEO.

Enhanced Animation

Safari 16 introduces some significant improvements in animation, but the one that catches the eye is that you can now animate CSS Grid.

Yes, let that sink in. Combine Container Queries and animation. The possibilities for hover states on elements are tantalizing.

Safari 16 also supports CSS Offset Path — known initially as CSS Motion Path — which allows you to animate elements along any defined path. This enables the kind of animated effect that previously needed JavaScript (or Flash!) to accomplish.

Chrome, Edge, and Firefox all support CSS Offset Path; the addition of Safari means it’s now a practical solution that can be deployed in the wild.

Web Inspector Extensions

Announced as part of the beta release, Web Inspector Extensions allow web developers to create extensions for Safari, just as they would for Chrome.

Web Inspector Extensions — or Safari Extensions as they’re destined to be known — can be built in HTML, CSS, and JS, so the learning curve is shallow. It’s a good route into app development for web designers.

Because the underlying technology is the same as other browser extensions, anyone who has made a Chrome, Edge, or Firefox extension will be able to port it to Safari 16+ relatively easily. As a result, there should be a rapid expansion of the available extensions.

Improved Accessibility

Accessibility is key to an effective and inclusive web. Be like Bosch: everybody counts, or nobody counts.

When testing a design for accessibility, emulators don’t cut it. In my experience, Safari has some of the most reliable accessibility settings, especially when it comes to Media Queries like prefers-reduced-movement.

Further gains in this field mean that Safari continues to be an essential tool for QA tests.

Reduced Resets

Finally, I want to throw up my hands to celebrate the reduced number of non-standard CSS appearance settings.

For years we’ve been prefacing our style sheets with elaborate resets like Normalize, designed to undo all the assumptions browser developers make about design and the UI preferences of their engineers.

Safari 16 has reportedly “Removed most non-standard CSS appearance values.” How effective this is and how much we can rely on it given the other browsers on the market remains to be seen. However, like many of Safari 16’s changes, it’s a step towards a browser that’s on the developers’ side instead of an obstacle to overcome.

Source

The post Exciting New Features in Safari 16 first appeared on Webdesigner Depot.

Source de l’article sur Webdesignerdepot

/par

Poll: Is It Time to Merge Browser Engines Into a Browser Protocol?

,

We tend not to think about it, but the Internet has a physical dimension. It’s a complex network of wires, cables, servers, and technical odds and ends — if you really want to, you can track it down; doing so is particularly easy on small islands because there tends to be a single cable tethering the region to the wider world.

Those physical cables run all the way to your building, and although an ISP manages them, they are normally rented from public bodies as part of your national infrastructure.

Beyond the physical, international bodies govern protocols like ARP, IEEE, HTTP, NTP, FTP, and others, which control how data is transmitted through the network and keep everything playing nice.

Then, at the other end of the equation, there’s your device. It may be a phone, a tablet, a notebook, a desktop. It’s probably several of these. And because it’s your device, everything on it feels like yours. We tend to think of it as our method of accessing the Internet instead of being part of the Internet — in reality, it’s both.

On your device, the software you use to access the Internet is your browser. For 65% of people, that’s Chrome. Even if you’re reading this on Edge, it’s created with the Blink engine, an extension of Chromium, which is the basis for Chrome. In fact, almost every browser is built using a variation of Chromium, except those on Apple devices that require Apple’s own WebKit to be used instead.

Chromium is ostensibly open-source. WebKit is not, but both are geared towards their primary contributors’ business goals; neither Chromium nor WebKit will make a change that negatively impacts Alphabet or Apple.

Your browser is just a copy of a pre-compiled set of source files sat in a Git repo somewhere. You may have installed a few plugins in your browser. You may have bookmarked a few pages. You’ve probably moved it to your dock or your home screen. Those features are just nice add-ons for the GUI; what really matters is what decisions are made about how to render web technologies.

Imagine a world in which every single car used the same mid-range Ford engine. Add in a stereo, and paint it any color you like, you can even pick your own tires, but under the hood, it has to be that mid-range Ford engine. And the only justification is that it’s too much work to create an alternative.

The 2020s are going to be a time of enormous change. You can smell the panic in traditional banking sectors every time Cryptocurrency is mentioned. Real estate billionaires are desperately trying to get us back into offices we don’t want to return to. And yes, I’m sorry, but the climate crisis is looming, and it will force our hand. The values of a whole generation have been rapidly reassessed. Innovation and the potential for innovation are rife, except, ironically, on the Internet, where we’re still chugging away with the mid-range Ford engine under the hood.

The web has reached the point at which the browser engines we choose define real-world infrastructure. There’s a fork in the road: either browser engines are part of an infrastructure that should be rationalized into a single browser protocol, or alternative browser engines need to be nurtured, encouraged, and accessible by choice.

Featured image via Pexels.

Source

The post Poll: Is It Time to Merge Browser Engines Into a Browser Protocol? first appeared on Webdesigner Depot.


Source de l’article sur Webdesignerdepot

/par

In Memory of Flash: 1996-2020

We are gathered here today….

Today I write in memory of Adobe Flash (née Macromedia), something that a bunch of people are actually too young to remember. I write this with love, longing, and a palpable sense of relief that it’s all over. I have come to praise Flash, to curse it, and finally to bury it.

We’ve been hearing about the death of Flash for a long time. We know it’s coming. December 2020 has been announced as the official timeframe for removal, but let’s be real about this: it’s dead. It’s super-dead. It’s people-are-selling-Flash-game-archives-on-Steam dead.

That last bit actually makes me happy, because Flash games were a huge part of my childhood, and the archives must be preserved. Before I’d ever heard of video cards, frames per second, and “git gud”, I was whiling away many an hour on disney.com, cartoonnetwork.com, MiniClip, Kongregate, and other sites, looking for games.

I think we’ve established in my previous work that even as a missionary kid, I did not have a social life.

The Internet itself gave me a way to reach out and see beyond my house, my city, and my world, and it was wonderful. Flash was a part of that era when the Internet felt new, fresh, and loaded with potential. Flash never sent anyone abuse, or death threats. Flash was for silly animations, and games that my parent’s computer could just barely handle, after half an hour of downloading.

I even built my first animated navigation menus in Flash, because I didn’t know any better. At all. But those menus looked exactly like the ones I’d designed in Photoshop, so that’s what mattered to me, young as I was.

That was a part of Flash’s charm, really.

What Flash Got Right

Flash Brought Online Multimedia into the Mainstream

Funny story, JavaScript was only about a year old when Flash was released. While HTML5 and JS are the de-facto technologies for getting things done now, Flash was, for many, the better option at launch. JS had inconsistent support across browsers, and didn’t come with a handy application that would let you draw and animate whatever you wanted.

It was (in part) Flash that opened up a world of online business possibilities, that made people realize the Internet had potential rivalling that of television. It brought a wave of financial and social investment that wouldn’t be seen again until the advent of mainstream social networks like MySpace.

The Internet was already big business, but Flash design became an industry unto itself.

Flash Was Responsive

Yeah, Flash websites could be reliably responsive (and still fancy!) before purely HTML-based sites pulled it off. Of course, it was called by other names back then, names like “Liquid Design”, or “Flex Design”. But you could reliably build a website in Flash, and you knew it would look good on everything from 800×600 monitors, to the devastatingly huge 1024×768 screens.

You know, before those darned kids with their “wide screens” took over. Even then, Flash still looked good, even if a bunch of people suddenly had to stop making their sites with a square-ish aspect ratio.

Flash Was Browser-Agnostic

On top of being pseudo-responsive, the plugin-based Flash player was almost guaranteed to work the same in every major browser. Back in a time when Netscape and Internet Explorer didn’t have anything that remotely resembled feature parity, the ability to guarantee a consistent website experience was to be treasured. When FireFox and Chrome came out, with IE lagging further behind, that didn’t change.

While the CSS Working Group and others fought long and hard for the web to become something usable, Flash skated by on its sheer convenience. If your site was built in Flash, you didn’t have to care which browsers supported the <marquee> tag, or whatever other ill-conceived gimmick was new and trendy.

Flash Popularized Streaming Video

Remember when YouTube had a Flash-based video player? Long before YouTube, pretty much every site with video was using Flash to play videos online. It started with some sites I probably shouldn’t mention around the kids, and then everyone was doing it.

Some of my fondest memories are of watching cartoon clips as a teenager. I’d never gotten to watch Gargoyles or Batman: The Animated Series as a young kid, those experience came via the Internet, and yes… Flash. Flash video players brought me Avatar: The Last Airbender, which never ever had a live action adaptation.

Anyway, my point: Flash made online video streaming happen. If you’ve ever loved a Netflix or Prime original show (bring back The Tick!), you can thank Macromedia.

What Flash Got Wrong

Obviously, not everything was rosy and golden. If it was, we’d have never moved on to bigger, better things. Flash had problems that ultimately killed it, giving me the chance, nay, the responsibility of eulogizing one of the Internet’s most important formative technologies.

Firstly, it was buggy and insecure: This is not necessarily a deal-breaker in the tech world, and Microsoft is doing just fine, thank you. Still, as Flash matured and the code-base expanded, the bugs became more pronounced. The fact that it was prone to myriad security issues made it a hard sell to any company that wanted to make money.

Which is, you know, all of them.

Secondly, it was SEO-unfriendly: Here was a more serious problem, sales-wise. While we’re mostly past the era when everyone and their dog was running a shady SEO company, search engines are still the lifeblood of most online businesses. Having a site that Google can’t index is just a no-go. By the time Google had managed to index SWF files, it was already too late.

Thirdly, its performance steadily got worse: With an expanding set of features and code, the Flash plugin just took more and more resources to run. Pair it with Chrome during that browser’s worst RAM-devouring days, and you have a problem.

Then, while desktops were getting more and more powerful just (I assume) to keep up with Flash, Apple went and introduced the iPhone. Flash. Sucked. On. Mobile. Even the vendors that went out of their way to include a Flash implementation on their smartphones almost never did it well.

It was so much of a hassle that when Apple officially dropped Flash support, the entire world said, “Okay, yeah, that’s fair.”

Side note: Flash always sucked on Linux. I’m just saying.

Ashes to Ashes…

Flash was, for its time, a good thing for the Internet as a whole. We’ve outgrown it now, but it would be reckless of us to ignore the good things it brought to the world. Like the creativity of a million amateur animators, and especially that one cartoon called “End of Ze World”.

Goodbye Flash, you sucked. And you were great. Rest in peace. Rest in pieces. Good riddance. I’ll miss you.

 

 

Featured image via Fabio Ballasina and Daniel Korpai.

Source


Source de l’article sur Webdesignerdepot

/par