CSS Nesting and the Cascade | WebKit
As well as a very welcome announcement, Jen has a really good question for you about nesting in CSS.
If you have an opinion on the answer, please chime in.
As well as a very welcome announcement, Jen has a really good question for you about nesting in CSS.
If you have an opinion on the answer, please chime in.
It’s great to see how (progressive) web apps are being supported on both iOS and macOS …I just wish the discovery were better.
Oh no! My claim has been refuted by a rigourous scientific study of …checks notes… ten people.
Be right back: just need to chat with eleven people.
Jen pointed me to this proposal, which should help smooth over some of the inconsistencies I documented in iOS when it comes to the Web Audio API.
I’ve preemptively add this bit of feature detection to The Session:
if ('audioSession' in navigator) {
navigator.audioSession.type = "playback";
}
An entire generation of apps-that-should-have-been web pages has sprung up, often shoehorned into supposedly cross-platform frameworks that create a subpar user experience sludge. Nowhere is this more true than for media — how many apps from newspapers or magazines have you installed, solely for a very specific purpose like receiving breaking news alerts? How many of those apps are just wrappers around web views? How many of those apps should have been web pages?
Instead of doing what the competing browsers are doing (and learning from years of experience of handling Web Push), Apple decided to reinvent a wheel here. What they’ve turned up with looks a lot more like a square.
But you can’t have a web app without a web-app-compatible browser, and you can’t get a web-app-compatible browser in Apple’s App Store. The only browsers permitted in the App Store are those based on WebKit, the browser engine behind Safari. This means that every browser on iOS, from Firefox to Edge to Chrome, is just a reskinned version of Safari.
A thoughtful response to the current CMA consultation:
The inability to compete with native apps using Progressive Web Apps fully—particularly on iOS—also has a big impact on my work and the businesses I have worked with. Progressive Web Apps are extremely accessible for development, allowing for the creation of a simple app in a fraction of the time and complexity of a native app. This is fantastic for allowing smaller agencies and businesses to innovate on the web and on mobile devices and to reach consumers. However the poor support for PWA features by Safari and by not allowing them in the App Store, Apple forces app development to be difficult, time consuming and extremely expensive. I have spoken with many companies who would have liked an app to compete with their larger competitors but are unable to afford the huge costs in developing a native app.
Get your response in by Friday by emailing browsersandcloud@cma.gov.uk.
Web Push on iOS will change the “we need to build a native app” decision.
Push notifications are definitely not the sole reason to go native, but in my experience, it’s one of the first things clients ask for. They may very well be the thing that pushes your client over the edge and forces them, you and the entire project to accept the logic of the app store model.
Good news and bad news…
The good news is that web notifications are coming to iOS—my number one wish!
The bad news is that it won’t happen until next year sometime.
A grassroots coalistion of web developers lobbying to get Apple to allow fair competition on iOS.
We have identified the #AppleBrowserBan as the number one threat to the future of the open web.
Safari is very opinionated about which features they will support and which they won’t. And that is fine for their browser. But I don’t want the Safari team to choose for all browsers on the iOS platform.
A terrific piece from Niels pushing back on the ridiculous assertion that Apple’s ban on rival rendering engines in iOS is somehow a noble battle against a monopoly (rather than the abuse of monopoly power it actually is). If there were any truth to the idea that Apple’s browser ban is the only thing stopping everyone from switching to Chrome, then nobody would be using Safari on MacOS where users are free to choose whichever rendering engine they want.
The Safari team is capable enough not to let their browser become irrelevant. And Apple has enough money to support the Safari team to take on other browsers. It does not need some artificial App Store rule to protect it from the competition.
WebKit-only proponents are worried about losing control and Google becoming too powerful. And they feel preventing Google from controlling the web is more important than giving more power to users. They believe they are protecting users against themselves. But that is misguided.
Users need to be in control because if you take power away from users, you are creating the future you want to prevent, where one company sets the rules for everybody else. It is just somebody else who is pulling the strings.
Eric has a written a clear and measured explanation that I hope Alex and Jake will read, given their petty snarky reactions to Webkit shipping a feature (reactions that do more harm than good to their cause—refuting their bullshit has taken time and energy away from the legitimate criticisms of Apple’s rendering engine monopoly on iOS; this whole debacle has been one big distraction from far more important browser bugs).
Many of us are mad at Apple for a lot of good reasons, but please don’t let the process of venting that anger tar the goals and achievements of Open Prioritization.
Firefox as the asphyxiating canary in the coalmine of the web.
This is something I bump against over and over again: so-called evergreen browsers that can’t actually be updated because of operating system limits.
From what I could gather, the version of Chrome was tied to ChromeOS which couldn’t be updated because of the hardware. No new ChromeOS meant no new Chrome which meant stuck at version 76.
But what about the iPad? I discovered that my Mom’s iPad was a 1st generation iPad Air. Apple stopped supporting that device in iOS 12, which means it was stuck with whatever version of Safari last shipped with iOS 12.
So I had two older browsers that couldn’t be updated. It was device obsolescence because you couldn’t install the latest browser.
Websites stop working and the only solution is to buy a whole new device.
Prompted by my talk, The State Of The Web, Brian zooms out to get some perspective on how browser power is consolidated.
The web is made of clients and servers. There’s a huge amount of diversity in the server space but there’s very little diversity when it comes to clients because making a browser has become so complex and expensive.
But Brian hopes that this complexity and expense could be distributed amongst a large amount of smaller players.
10 companies agreeing to invest $10k apiece to advance and maintain some area of shared interest is every bit as useful as 1 agreeing to invest $100k generally. In fact, maybe it’s more representative.
We believe that there is a very long tail of increasingly smaller companies who could do something, if only they coordinated to fund it together. The further we stretch this out, the more sources we enable, the more its potential adds up.
What I want instead is an anarchist web browser.
What I’d really like to see is a browser that cuts things out, that takes things away from the web. Colors, fonts, confusion. Do you need an enormous JavaScript engine under the hood to power a modern web browser? I don’t think you do. Do you need all the extensions? All the latest CSS features? Nah, mate.
Throw away everything and start again and focus intensely about what people care about when it comes to the web.
If Apple allowed Safari to actually compete, it would be better for web developers, businesses, consumers, and for the health of the web. Come on, Apple, set Safari free!
I have this expensive computer in my pocket and it feels unfair that it is hamstrung in this very specific way of not allowing other browser engines. I also have an Apple laptop and it’s not hamstrung in that way, and I really hope it never is.
You may not realise that all browsers on iOS are required to use the same rendering engine as Safari. On other platforms, this is not the case.
A terrific in-depth look at the frustrating state of the web on iOS.
So it’s not just one browser that falls behind. It’s all browsers on iOS. The whole web on iOS falls behind. And iOS has become so important that the entire web platform is being held back as a result.
And this damning assessment is mercifully free of conspiracy theories.
The Safari and Chrome team both want to make the web safer and work hard to improve the web. But they do have different views on what the web should be.
Google is focussing on improving the web by making it more capable.
Safari seems to focus on improving the web as it currently is.
Read the whole thing—it’s excellent!
There can only be one proper solution: Apple needs to open up their App Store to browsers with other rendering engines. Scrap rule 2.5.6 and allow other browsers on iOS and let them genuinely compete. Even though Apple has been forced to compromise on some App Store rules, I have little hope for this to happen.