This looks interesting. On the hand, it’s yet another proprietary creation by one browser vendor (boo!), but on the other hand it’s a declarative API with no JavaScript required (yay!).
Even if this particular feature doesn’t work out, I hope that this is the start of a trend for declarative access to browser features.
Finally! View transitions for multi-page apps (AKA websites) will be landing in Chrome soon—here’s hoping other browsers follow suit. Mozilla are up for it. Apple are, as usual, silent on their intentions.
Nice to see a blog post of mine referenced to show that this is a highly-requested feature. Blogging gets results, folks!
I think filing bugs on browsers is one of the most useful things a web developer can do.
Agreed!
‘Sfunny, I’d been meaning to write a blog post on exactly this topic, but Tyler says it all …and that’s before Apple’s scandalous shenanigans.
These updated definitions makes sense to me:
- Newly available. The feature is marked as interoperable from the day the last core browser implements it. It marks the moment when developers can start getting excited and learning about a feature.
- Widely available. The feature is marked as having wider support thirty months or 2.5 years later. It marks the moment when it’s safe to start using a feature without explicit cross-browser compatibility knowledge.
Remember when I wrote about sizes="auto"? Well, it’s coming to Chrome! Hallelujah!
This is a very handy tip if you’re adding view transitions to your website!
Some great ideas for view transitionts in here! Also:
If you look at any of the examples on a browser that does not support them, the pages still function just fine. The transitions are an extra that’s layered on top if and when your browser supports them. Another concrete example of progressive enhancement in practice.
I think this might be the most excited I’ve been in quite some time about an update to browser support, which probably says a lot about my priorities:
Support for the
avoidvalue of the CSS fragmentation propertiesbreak-before,break-after, andbreak-insidewhen printing.
Finally!
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.
I remember when Google Chrome launched. I still have a physical copy of the Scott McCloud explanatory comic knocking around somewhere. Now that comic has been remixed by Leah Elliott to explain how Google Chrome is undermining privacy online.
Laying bare the inner workings of the controversial browser, she creates the ultimate guide to one of the world‘s most widely used surveillance tools.
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.
Google Topics is the successor to Google FLoC. It seems to require collusion from your “user agent”:
I can’t see why any other browser would consider supporting Topics. Google wants to keep tracking users across the entire web in a world where users realize they don’t want to be tracked. Why help Google?
Google sees Chrome as a way to embed the entire web into an iframe on Google.com.
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.
Forgive me for linking to The Rag, but for completeness’s sake, it would be remiss of me not to point out more coverage of “that” question I asked:
It was to the company’s credit that it chose to take the question posed by Clearleft’s Jeremy Keith, well known in the web standards community and who was briefly on the advisory committee for AMP (Accelerated Mobile Pages), before resigning saying that “it has become clear to me that AMP remains a Google product.” AMP has been in the news of late with a lawsuit alleging Google deliberately throttled ad load times to promote it, and Keith asked: “Given the court proceedings against AMP, why should anyone trust FLOC or any other Google initiatives ostensibly focused on privacy?”
An article by Sarah Gooding, prompted by the question I asked at Chrome Dev Summit:
Jeremy Keith’s question referencing the AMP allegations in the recently unredacted antitrust complaint against Google was extremely unlikely to receive an adequate response from the Chrome Leadership team, but the mere act of asking is a public reminder of the trust Google has willfully eroded in pushing AMP on publishers.
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.
At first glance, this looks like a terrible idea. But the key is in the implementation. In this case, the implementation is truly awful.
The section on detecting “auto dark theme” is, as far as I can tell, not intended as a joke.
Mind you, this could all be a galaxy-brain idea to encourage more developers to provide their own dark mode styles. (In much the same way that AMP was supposed to encourage better performance.)