Tag Archives: webkit

Web Browser Ecology After Microsoft Ditches EdgeHTML for Blink

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. 

SVG Transforms: Not competing with O3D

Per this thread, Apple/WebKit’s SVG Transforms are NOT competing or in the same area of interest as O3D. Instead, SVG Transforms (which incorporates WebKit’s CSS 2D and 3D Transforms, CSS Transitions and CSS Animations) is meant to display and interact with flat pieces of web content (in this case, the traditionally-2D SVG) in 2.5D/3D space, while O3D and WebGL are meant to display fully 2.5D/3D *scene graphs* and *models* separately from any web content (even though both efforts are aiming for an in-browser user experience).

Interestingly, Maciej mentions that it would be possible to codify a means to join arbitrary (2D/3D) web content and arbitrary 3D models together, but that it may be "bigger challenge than anything that anyone has done so far".

So if this same argument could also be applied to other related initiatives in both fields, from canvas(3D) to X3D, then I’m assuming that the next frontier for the 3D Web initiatives to cross is how to bridge the divide of perception between 3D and 2D in the same network-centric application. Certainly, the fact that most of us do not have 3D-ready navigation hardware (like the SpaceNavigator) is a core part of that dialogue over why the 3D Web initiatives are not scaling to better expectations of ease of use and accessibility (not to mention hardware acceleration of graphics).

So O3D or WebGL may have a future in the web browser (or at least a better one than VRML and X3D), but its not like we’re that much closer to bridging the gap between 3D web content and 3D scene content.

Styling, Scripting and SMIL: The three options in SVG animation

I wonder when CSS animation and other WebKit niceties can be packaged into CSS frameworks for easier, less rigorous designing of web pages.

Anyway, after looking at the announcement that WebKit allows CSS animations, transitions and transforms, I wonder about the "best practices" of using such modules with SVG.

Maybe it would go like:

  • CSS for color and movement of shapes
  • SMIL for timed text (subtitles) and links
  • JS for playback control

It seems a bit more realistic for SMIL to be relegated to timed text rather than have such an actively-animating role as was accorded to it by the W3C when they first came out with the SMIL standard in the late 90s/early 2000s; SMIL’s syntax can be seen as one that is best for graphically-intensive text. Allowing for CSS to take a greater role in animation can also open up doors for web designers to easily create Flash-like animations  using a combination of normal web editors and SVG editors rather than wait for all-in-one dedicated animation editors.

The problem is that the WebKit team has not yet developed a publicly-documented approach to SVG animation through CSS; CSS as-is is already used in SVG and XHTML, among other flavors of XML, for styling and color, but this animation/transform/transition idea for CSS has not been publicly considered as being usable with SVG, only with XHTML as rendered by WebKit.

Thus, it remains to be seen how CSS styling as an SVG animation property will play out.

WebKit, Mozilla, CSS and SVG

So now you have Apple’s WebKit pushing more for CSS extensions such as animations and transformations (at least because Apple would rather push for the <canvas> tag rather than endorse SVG) while you have Mozilla pushing SVG effects (at least because Mozilla would rather throw its support to SVG extensions rather than CSS, as seen with their relatively late tackling of the Acid2 test).

But where do the twain meet? How can SVG and CSS be reconciled as needing each other to create, say, better graphical web UIs?

Plus, what’s there to gain for Apple in the extension of CSS into the animation and variables department (which is already dominated by JavaScript and, to a lesser extent, vector graphics such as Flash/ActionScript and SVG/SMIL)?

Maybe CSS can be better used for HTML animation and effects while SMIL is better for SVG animation and effects?

Uninformed: Mozilla – the Intel of browsers?

Is Mozilla the Intel of web browser makers?

As I’ve probably said before, I find the foundation/corporation to be rather set in its ways, convinced that the Mozilla platform, which has been ported for use on a number of operating systems, offers enough clout for them to continue development of their flagship web browser. Any issues that the users of the browser may face is the cause for further improvement of parts of the platform, rather than total replacement of these components.

For instance, Mozilla’s proponents and developers felt slighted when Apple passed over the Gecko layout engine in favor of KDE’s KHTML/KJS for their WebKit platform.

Furthermore, Mozilla tends to view itself as the vanguard of the web, and has promoted the Gecko engine as being more “compatible” with a variety of web sites and web standards than other layout engines, including the WebKit/KHTML engines.

But on another note, the comparison between Gecko and WebKit should take into account the folks who support, use or promote either engine. While Mozilla, a cross-platform browser maker, is the largest promoter and supporter of Gecko, WebKit tends to be supported and promoted by a variety of groups: the most monied of these supporters are the mobile device or software makers, such as Nokia/Trolltech, Apple, and Google (via Android).

Does this mean that Mozilla and Gecko is similar to Intel and its 30-year-old x86 chip architecture, while WebKit and its promoters are similar to the PowerPC architecture and its supporters (IBM, Freescale)?