OblomovI don't think people appreciate the role that #OperaSoftware played in fostering the #OpenWeb and #IndieWeb during the first #browserWar (when the #OperaBrowser was still built on their proprietary #Presto engine), and a fortiori the role it had in their demise (when they switched to being “just another #WebKit/#Blink skin”), despite their browser never even reaching a 3% market share.
In the five years between the creation of the #WHATWG and the switch from Presto to WebKit (and then Blink) by Opera, their role within the working group was essential as an independent standard implementor. Anything that was supported by two out of three (at the time, Apple, Mozilla, Opera) vendors meant different _engines_ implemented the standard. Today, three out of five implementations agreeing is meaningless, since they are most likely just WebKit and its forks.
The Opera/Presto browser was pretty close to being a “swiss army knife” for the web. Aside from the #browser with a solid and modern rendering engine with decent standard support (for the time), it also integrated (in the same UI!) a workable #email client, a decent #IRC client, and a competitive #RSS reader. The browser itself not only had better support for web standards than some of the competitors (including WebKit) in many areas, but it also put effort in supporting #microformats
As an example of how the Opera UI fostered web standards, not only it did automatic feed discovery (allowing subscription to RSS feeds even if they weren't announced on the visible part of the web page), but it famously featured a navigation bar with next/prev/up/top links that could be extracted from appropriately rel-marked link elements in the page (and for many common cases even when they were NOT properly rel-marked).
But the most impressive (and underrated) feature of Opera was #OperaUnite. First introduced in 2009 in a beta release of Opera 10.10, Opera Unite was a web server that allowed JavaScript server-side scripting to write small static and dynamic websites that were accessible either directly (using UPnP to expose it on the Internet) or through a proxy service offered by Opera itself.
https://web.archive.org/web/20120121122103/http://dev.opera.com/articles/view/opera-unite-developer-primer-revisited/
https://web.archive.org/web/20120121122103/http://dev.opera.com/articles/view/opera-unite-developer-primer-revisited/
Opera Unite developer’s primer — revisited - Dev.Opera
Dev.Opera is the ultimate source of distilled knowledge for web developers, covering the latest open web technologies and techniques including HTML5, CSS3, JavaScript, SVG, optimizing content for mobiles, tablets and TVs, and creating add-ons such as extensions and themes for the Opera browser.
Read that again: in the years before its demise, the Opera/Presto browser not only integrated features to access a large chunk of the Internet aside from the web (email, USENET, IRC), but it featured a web server.
In a period where most major players were working towards centralization of the web, Opera pioneered an effort that —if successful— would have made it possible for every Internet user to take both a passive and an active role in its participation.
In a period where most major players were working towards centralization of the web, Opera pioneered an effort that —if successful— would have made it possible for every Internet user to take both a passive and an active role in its participation.
Opera in the Presto days was a pioneer. Anybody that enjoys a #PWA (#ProgressiveWebApp) today should be aware of the efforts made by Opera to standardize their Widgets feature, even if the standard they promoted was ultimately obsoleted by the current one, that relies on modern client features that were not available at the time.
The Opera-designed “demonstrative” Unite Applications were media, photo and file sharing applications. Does that make you think of anything?
The Opera-designed “demonstrative” Unite Applications were media, photo and file sharing applications. Does that make you think of anything?
Sometimes I wonder how different things could have been if the timing had been different. When #OperaUnite was first announced, #ActivityPub wasn't a thing yet, StatusNet had just been born, diaspora* didn't exist, and the only other major bidirectional federated protocol was XMPP, that had existed for 10 years and was in the process of being #EmbraceExtendExtinguish-ed by Facebook and Google.
I have no problems imagining a different timeline, where #ActivityPub had been already a better-established thing, and the demo #OperaUnite applications for media and photo sharing had implemented basic support for it, resulting in self-hosted lightweight alternatives to #PixelFed or #FunkWhale.
And this is actually the vision I have an ultimate goal for the #Fediverse, one where, thanks also to client support, hosting and participation become even more trivial than setting up a static website.
In many ways, Opera giving up on their Presto engine, marked not only the end of the browser war, with WebKit/Blink the uncontested winner, but it also marked the end of truly inspiring (inspired?) client innovations for the open Internet, although possibly not entirely by its own fault, since in the same period Firefox also largely seemed to “give up” on that front, even going as far as removing features they had (such as their RSS support).
With the modern #OperaBrowser now just a derelict ghost of its past self, hooked into proprietary initiatives (think of its Messenger for closed silo networks) and cryptocurrency shilling, some of its legacy is now being carried by _another_ Chromium skin/fork: @Vivaldi
Although I do not appreciate it being partially closed source, or its reliance on Blink (that for example precludes #JpegXL), it does seem to be still interested in keeping the spirit of the “swiss army knife of the (open) web”.
Although I do not appreciate it being partially closed source, or its reliance on Blink (that for example precludes #JpegXL), it does seem to be still interested in keeping the spirit of the “swiss army knife of the (open) web”.
One of the interesting ways in which this shows up is that in addition to email, RSS and calendars, Vivaldi has also actively promoted support for #Mastodon, in a very simple yet effective way (providing a Web Panel for their instance; you can add your own). I expect the same will work on other #Fediverse platforms, as long as they provide a functional web interface with good “small screen” support (since this is effectively what the Web Panels use).
(Off topic for the thread, but playing around with the Vivaldi Web Panel features I discovered that keyboard input in my #FingerMaze game is broken in case of vertical layout. It was designed for cellphones so it's not a big loss, but still, I think I should fix it.)
(OK, now that I fixed #FingerMaze for keyboard use in rotated view and you can finally play it in a Vivaldi Web Panel, let's get back on topic.)
The #VivaldiBrowser is the closest thing we have to an “swiss army knife for the open Internet” today, and yet it doesn't even have feature parity with the late Opera/Presto. For example, it has no IRC client.
But in the context of my vision for the #Fediverse, the most glaring omission is the lack of an equivalent to Opera Unite, an incentive to the development of easy-to-deploy self-hosted websites.
Even if Vivaldi (the company) did share my vision of an open web, I have my doubts that it has the energy and workforce necessary push it. The fact that their main product is proprietary (despite the abundance of open source software they leverage) is also a downside.
Getting Mozilla on board would be of great help in his, but considering the downwards direction they have taken with Firefox, that's even less likely (seriously, not even RSS?)
Getting Mozilla on board would be of great help in his, but considering the downwards direction they have taken with Firefox, that's even less likely (seriously, not even RSS?)
Which is a pity, because two independent browsers implementing support for a common lightweight server applications in the spirit of the Opera Unite applications could be a a major push in the right direction. And even if Vivaldi did invest in something like that, their efforts alone would get nowhere.
People may dismiss the usefulness of the “swiss army knife” concept pushed by Opera/Presto up to 10 years ago and by @Vivaldi now, citing “bloat”, “lack of focus” or the classic principle of doing “one thing well” instead of a 100 things poorly (sometimes called the Unix philosophy). There is merit to the objection, but I have never seen it put in practice as it should be: on the contrary, feature rejection, or even worse removal, have been to the detriment of “doing one thing well”.
Two of my #petPeeves in this regard are with #Mozilla #Firefox, and in both cases they are about feature removal because of perceived bloat.
The first is the removal for the support of the #MNG format. The purported reason for this was the “bloat” coming from linking a 200KB library. Reading the issue tracker for this, 20 years later when Firefox installations are 200MB and counting is … enlightening:
https://bugzilla.mozilla.org/show_bug.cgi?id=18574
I still care about the MNG format support not for the format itself —it's quite clear that it irredeemably failed— but because the same argument can be used in the future to stymie adoption of other formats such as #JpegXL, which is currently supported in Firefox Nightly, and will likely receive the same treatment (I wonder if with the same excuses) now that Google has decided to drop support for it from Chrome.
IOW, the issue isn't so much with the specific format (although that has its importance: MNG was the best we had at the time for a unified format that supported animation, transparency and optionally lossy compression), but the active choice to not uphold the interests of the #openWeb. The same thing holds for the second pet peeve of mine: Mozilla's decision to remove RSS and Atom feeds support.
Firefox had some support for all three aspects of web feeds support (discovery, visualization, subscription), and it was all wiped out with the release of Firefox 64, with maintenance cost being the (purported) reason:
https://www.gijsk.com/blog/2018/10/firefox-removes-core-product-support-for-rss-atom-feeds/
Even if we accept the motivations and that WebExtensions would be the best way to reimplement the features, the question remains: why didn't Mozilla provide an official extension for it?
https://www.gijsk.com/blog/2018/10/firefox-removes-core-product-support-for-rss-atom-feeds/
Even if we accept the motivations and that WebExtensions would be the best way to reimplement the features, the question remains: why didn't Mozilla provide an official extension for it?
If you want an example of why an absence of feed discovery built into the browser (or at least offered through a default-installed official extension), consider this recent post on @fediversenews by @atomicpoet
https://mastodon.social/@atomicpoet/109900176041961778
—having to jump through hoops, looking at the page source code to find web feeds because the browser has removed the discovery feature is something that can trip even competent experts.
https://mastodon.social/@atomicpoet/109900176041961778
—having to jump through hoops, looking at the page source code to find web feeds because the browser has removed the discovery feature is something that can trip even competent experts.
(And yes, the website _could_ advertise the presence of the feeds on the visible part of the page, and the absence of visible links _is_ to be blamed on them, but on the other hand: why duplicate the information when the browser can (and actually used to!) show you the information advertised in the document metadata, where it is supposed to be?)
#Mozilla's choice to remove their built-in web feed support without providing an official extension to carry on the legacy is another strike to the #openWeb and #indieWeb on their side.
I often wonder what has been going on inside #Mozilla. #Firefox reached its largest market share (around 30%) some 10 years ago. Since then, it has been inexorably losing market share. There is little doubt that this has been largely due to the growth of mobile and Google's unfair marketing advantage, BUT:
I have little doubt that Mozilla's response has been the worst possible one: they have chosen to get into a “race to the bottom” based on mimicry instead of playing to their strengths or finding new ones through innovation. I can't say for sure that their market share wouldn't have fallen this quickly if they had taken a different path, but I know for sure that there are people who switched because Firefox didn't have anymore a compelling reasons to be used over the competition.
Again, this isn't about #MNG or #JpegXL or #RSS or web feeds support _specifically_: it's about the priority policies.
I do understand and appreciate that even just the maintenance of the engine to keep the pace with the evolution of the web standards is a huge undertaking —it's why so many browsers have just given up and chosen to “leech” on WebKit or Blink instead.
When the only reason to use your browser is that it's the only FLOSS alternative to Google's, you have a problem.
The fact that @Vivaldi, a Chromium reskin with some proprietary glue, has more personality than #Firefox (that doesn't even seem to have a Fediverse presence) is something that should really be a wake-up call for @mozilla
And before anybody gets into the comments to praise #Mozilla for its history of web standards and user privacy defense —I don't need you to remind me of that. That's not the point. The point is that to actually be able to do that you need something more than “I'm not Google”.
And the irony here is that while #Firefox has nothing to claim for itself other than “not Google”, @Vivaldi _does_, even if it's still using Blink as web engine, and is thus subject to Google's whims on that side (one example for all: concerning #JpegXL support). Heck, even the new Opera is more than just “not Google” — although if it's pursuing all the wrong “personality” traits for that.
Why is having a personality important? Because it's one of the pillars on which your capability to defend your position is founded. Mozilla cannot protect web standards through Firefox if their go-to solution is to remove support for standards that don't get the adoption they wish for in the timeframe they expect: nobody is going to adopt a standard if there is a credible threat for support for it being senselessly removed in the near future.
The #DoNotTrack header has been deprecated, and has been largely useless because it was never adopted by most advertisers, using the cop-out of it not being legally binding. Despite this, #Firefox (and most other browsers, with the only exception of Apple's Safari AFAIK) still support sending the header, despite it being arguably a waste of bandwidth and implementation resources (UI options to control its settings, JS access to it, etc). Why do they still do it?
Because it's part of their personality: even if just at face value, DNT header support is a signal that the browser cares about user privacy.
(Don't get my started on the “new” #GlobalPrivacyControl standard when it would have sufficed to update the DNT spec in relation to the new legislation.)
So while one could place reasonable confidence in @mozilla upholding past, current and future privacy-oriented standards, I don't feel the same concerning the #openWeb.
(Don't get my started on the “new” #GlobalPrivacyControl standard when it would have sufficed to update the DNT spec in relation to the new legislation.)
So while one could place reasonable confidence in @mozilla upholding past, current and future privacy-oriented standards, I don't feel the same concerning the #openWeb.
I'm sure people have different ideas about what does it mean to support the #openWeb. I think first and foremost it means allowing users (on both sides of the connection) to use the protocols and file formats of their choice. Every time a browser fails to implement (or worse decides to remove) support for a standard protocol or file format, it's failing the open web. Half-assing implementation of web standards was basically #Microsoft's staple behavior during the first #browserWar.
Microsoft had reasons for this: at first it was because they didn't “get” the Internet, later on it was because it's the only way they had to (attempt to) control it. They did all they could to cripple it: remember when #OperaSoftware released a “Bork” edition of their of the #OperaBrowser in response to #Microsoft serving them intentionally broken CSS?
https://press.opera.com/2003/02/14/opera-releases-bork-edition/
Now imagine what the Internet would have been like if Opera, @mozilla and few others hadn't held their ground.
https://press.opera.com/2003/02/14/opera-releases-bork-edition/
Now imagine what the Internet would have been like if Opera, @mozilla and few others hadn't held their ground.
Opera releases "Bork" edition
The Swedish Chef Goes After Microsoft Oslo, Norway – Feb 14, 2003 Two weeks ago it was revealed that Microsoft’s MSN portal targeted Opera users, by purposely providing them with a broken page. As a reply to MSN’s treatment of its users, Opera Software today released a very special Bork edition of its Opera 7 […]
If you think what Microsoft did was insane, consider this: @Vivaldi had to change their user agent identification because #Google, #Facebook, #Microsoft and even #Netflix were intentionally breaking their websites when detecting the #VivaldiBrowser
https://vivaldi.com/blog/user-agent-changes/
#GAFAM are against the #openWeb —and the worst in the bunch is Google, that also holds a dominant position with their browser both on the desktop and mobile space.
https://vivaldi.com/blog/user-agent-changes/
#GAFAM are against the #openWeb —and the worst in the bunch is Google, that also holds a dominant position with their browser both on the desktop and mobile space.
ocdtrekkie@ocdtrekkie the right call should be to sue any website that sends different content to different browsers out of existence, but nobody is going to do that 8-(