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:
Cqoicebordel ❎@oblomov Just to jump on that part, Vivaldi, and in particular Jon von Tetzchner, founder of Opera and Vivaldi is a big proponent of Open Standard, but is skittish around OSS. The reasons being that OSS come at a cost. (Note that I'm not here to argue, I'm just reporting infos)
Switching to an OSS licence is also a one way trip, that you can't come back from, and it may jeopardize future deals : Opera was on the Nintendo Wii and DS in part *because* it was closed sources.
Vivaldi successfully /
Switching to an OSS licence is also a one way trip, that you can't come back from, and it may jeopardize future deals : Opera was on the Nintendo Wii and DS in part *because* it was closed sources.
Vivaldi successfully /
@oblomov made deals with cars manufacturers to be included in their infotaitnment system, being the first browser on Android Auto, and I believe being closed source helped make the deal.
That said, a lot of Vivaldi is "accessible sources" : they distribute their changes to Chromium (https://vivaldi.com/source/), and the HTML/CSS/JS code that makes the UI is accessible in the installed browser.
It's not ideal, but it's a somewhat good balance for them to make money :)
Holger Burkhardt@oblomov Opera was truly a browser ahead of its time. Too bad that their approach was not honored by the users.