Tag Archives: web browser

Web Browser Ecology After Microsoft Ditches EdgeHTML for Blink

Uncategorized, , , , , ,

In re: https://css-tricks.com/the-ecological-impact-of-browser-diversity/

I think the issue of ecological diversity as you presented in your post is complicated by the issue of open- and closed-source web browser engines.

MacOS would not have existed in the first place if Apple had not acquired NeXT and its partially open-source, BSD-derived OS NeXTSTEP, nor would Safari have accomplished basic compliance with W3C specs if they had not used KHTML and other web utilities from the KDE project. Similarly, Android and Chrome would not have gotten anywhere near what they have become if they hadn’t used Linux and WebKit as a launching pad.

I know that you wrote this post months before Microsoft announced that they were ditching EdgeHTML for Chromium/Blink, but I don’t know whether to feel sorry or a sense of schadenfreude over this moment.

If Opera had open-sourced Presto or Microsoft had open-sourced EdgeHTML, Trident or even Tasman (for IE for Mac), maybe those platforms would have seen a longer future of investment from interested developers like Gecko and KHTML/WebKit/Blink all have. Maybe Microsoft would have had a better experience in developing Trident and not need to fork it into EdgeHTML after years of neglect. Maybe they would have had a better competitive fight against the monoculture which now trends in Google’s direction. I wish that they would had finally opened up their browser development to the open source community and continued their evolution.

But they’ve both cut themselves off from their own proprietary engines to use the popular open-source one that anybody can use. That makes sense for the bottom line and is good for extending Blink and Chromium into more hardware applications, but it’s shameless and sad that the open-source community will never get to see/build/extend/distribute Presto nor Trident/EdgeHTML into longer-lasting, more evolved engines; it’s even more shameless given how Microsoft spent so many years trying to defend IE from both Firefox and Chrome using unethical practices.

I also expect that MS will eventually fork Blink, just like Google forked it from WebKit and Apple forked WebKit from KHTML, since the open source ecosystem allows for this to happen in a way that would take place differently with closed-source regimes. But I think the dynamic open source developer community has been denied a massive opportunity to further the evolution and competition of browser engines with this forced exit of EdgeHTML into obscurity. 

The WWW, the Transformers film, and language-learning

Uncategorized, , , ,

I mean, were the scriptwriters serious?! " We’ve learned Earth’s languages through the World Wide Web"?!

This just tore me up a bit, but its not the first time that screenwriters have displayed such an utter misunderstanding of the Internet; for one, the fact that the World Wide Web is only one Internet-dependent application (and one that is text-centric, not voice-centric) may render the above quote partly inaccurate.

I can only think that, if the two factions and their leaders were able to 

  1. Receive radio signals emanating from digital-electronic, networked machines
  2. Use a voice browser to vocally read text
  3. Manage to pair recorded voice-readings of hyperlinked text to their own native language for comparisons, contrasts and translations of words and contexts

all within mere seconds on an incremental basis, then we might have a more solid hypothesis for the Transformer race’s own networking capabilities, alongside all the other technological capabilities which they possess.

But in the meantime, we only have this alternative hypothesis for what would happen if the Transformers had learned Earth’s languages by rapidly flipping through a web browser:

EDIT: See also this slightly-related writeup from 1996 on extraterrestrials using the WWW. Vos Post wrote a section about the potential hyperlinearity of alien communication, comparing it to the more familiar hyperlinearity of the World Wide Web.
EDIT 2: Someone else wrote a criticism of this same quote, primarily from an SMS/mobiletexting-centric focus, for the Apache Pow Wow newspaper of Tyler Junior College.

The Tabtitlebar – Where Apple and Google went right, wrong or M.I.A.

Uncategorized, , , , , , , ,

This will be short.

Already, skirmishes of opinion over Apple’s interpretation of Google Chrome‘s tabtitlebar – or the positioning of the tabs in the title bar of the browser in order to utilize screen space for webpages – have erupted on various news sites and blogs. Even on OS X, the jury over Safari 4‘s user interface design is divided; on the Windows port, most who express favor with Safari 4’s user interface design are usually users of Windows Vista, so the main supposition is that those who have the most trouble with the tabtitlebar are Windows XP users; oh, and (on a cross-platform basis) people who simply like more screen real estate for pageviewing.

Of course, Google Chrome Beta (Google’s first browser, and currently Windows-only) was the first notable web browser to publicly promote the UI infusion, and it was not without its initial criticisms for that same reason (among others, including the option of sending anonymous usage and crash data to Google). Safari 4 Beta, on the other hand, marks a first for Apple in its legendary user interface history, and may also begin a user interface trend for Apple throughout its Mac OS X applications (Finder, Mac OS’s file navigation app, is hinted to have tabs in early alphas of Snow Leopard, OS X’s 6th iteration, so it may well take up Safari 4’s tabtitlebar feature).

Many have written about problems with this emerging user interface widget, which utilizes the operating system’s window manager by embedding navigation between tabs within the title bar (mostly on Windows). Personally, I think it is a good idea due to a month or so of using Google Chrome (I also find the process-per-tab idea to be a good idea), but problems still linger with both implementations as far as I’m concerned.

  • Speed: Chrome is far better in the speed department than Safari as far as opening, closing and navigating between tabs is concerned (again, maybe because of the process-per-tab idea). The Windows port of Safari 4, like its Mac port, does not allow an option (AFAIK) for using middle-click to close tabs; left-clicking to close tabs in Safari 4 on WinXP feels like chipping into brick. The responsiveness to clicking buttons to close and open tabs is horrendous on this platform.
  • Tab navigation and perception: In this area, I’ll say that Firefox 2.0+, despite its own speed and resource management issues, did a better tour-de-force at tab navigation than Opera, Chrome or Safari, by allowing one to scroll through as many tabs as one may please without the tabs being scrunched up in the tab area. All the other browsers, even Chrome and Safari, continue to maintain the metaphor of the "limited tab area", with Safari 4 doing worse by maximizing the view of the tab of the current page in view at the expense of other tabs-in-waiting.

Yes, Firefox actually did something that I’ve come to appreciate (and wish that they could extend into a much wider territory of tab navigation; getting rid of the tab-specfic close button in 3.0 remains questionable, IMO).

There is room for improvement for Safari and Chrome in this combination of two user interface metaphors. In fact, there’s room for improvement for most of Apple’s software ports to Windows, but I highly doubt that Apple is willing to consider such ideas as unscrunching the tabtitlebar for tabscrolling or giving separate processes to each tab, just as how I doubt that Microsoft will do the same with IE8 or IE9.