Future of the Web

This document defines how SVG effects are extended to apply to CSS-formatted elements. In particular, it makes the 'filter', 'mask' and 'clip-path' CSS properties and SVG paint servers applicable to CSS-formatted elements (such as HTML elements).

Once you add in better email and calendar support WebEx could become more appealing to the enterprise. PostPath has a Linux based collaboration system built on an AJAX client that doesn't need a browser. Cisco added that the company's strategy is to develop "an integrated collaboration platform designed for how we work today and into the future. And better yet: PostPath's pitch is that it is an Exchange alternative and a "Linux-based corporate email server." Let's read between the lines: Doesn't this sound a lot like an end-run around Microsoft Office, Outlook and Exchange just like Google is trying to do with Google Apps? Cisco probably has no desire to compete head on with Microsoft (or at least admit it), but the company obviously sees something here and coupling PostPath with WebEx could be a threat to Redmond. In fact, Cisco could be a bigger threat to Microsoft in the enterprise than Google. Why? Cisco already sells enterprises a lot of stuff. Isn't a collaboration suite really just an extension of the network?

"Why something as poorly designed as the Web became The Next Big Thing, and what that means for the future." Well designed but "fixed" systems were over taken by the evolvable but poorly designed Web. I'm wonderig if these same "evolving" principles apply to standard organizations? Put WebKit up against the standard orgs in charge of key WebKit components, and you see clearly that WebKit would fail misably if they stuck to the hapless efforts of the W3C, Ecma and ISO. Besides the fact that entrenched players such as Microsoft are sitting on those standards orgs in position to dumb down or put into terminal stall much needed innovations. For instance, WebKit deepneds on HTML5, CSS3, SVG, and JavaScript. All of which are stalled at various standards orgs. As a reaction to this org stall, the WebKit group pushes forward anyway relying instead on OSS Community style innovation and consensus model sharing.

First of all, I modified the approach by replacing # with ¶ per the suggestion of another Simon. Whereas # suggests Web anchors, it only suggests that to Web hacks, while ¶ has a long typographical history as a paragraph marker. Plus, it's kind of pretty and it's officially called a Pilcrow, which you gotta love. Now that the anchor is so evanescent, I wonder if it might work in a shade slightly less ethereally pale. ¶

Ben O'Steen has put up some thoughts on what he refers to as 'compound' documents and how to store them in repositories and allow for referencing of parts of a document, such as a table, a graph or even a paragraph. Why did I add the scare quotes to compound? While to a computer scientist a research paper with its graphs and tables and paragraphs might be compound, I suspect most authors tend to think of a research article as a single entity. Until we start giving them access to services that make it clear that it's not monolithic, that is. As background, Ben gives four rules: Note that the four rules of the web (well, of Linked Data technically) are in essence: * give everything a name, * make that name a URL … * which results in data about that thing, * and have it link to other related things.

The four rules of the web and compound documents A real quirk that truly interests me is the difference in aims between the way documents are typically published and the way that the information within them is reused. A published document is normally in a single 'format' - a paginated layout, and this may comprise text, numerical charts, diagrams, tables of data and so on. My assumption is that, to support a given view or argument, a reference to the entirety of an article is not necessary; The full paper gives the context to the information, but it is much more likely that a small part of this paper contains the novel insight being referenced. In the paper-based method, it is difficult to uniquely identify parts of an article as items in their own right. You could reference a page number, give line numbers, or quote a table number, but this doesn't solve this issue that the author hadn't put time to considering that a chart, a table or a section of text would be reused.

everything we do here at Mozilla is, for the most part, a contribution to the Web platform. I blogged previously about the low esteem I reserve for arguments that favor proprietary platforms (which typically pit rapid proprietary innovation against dawdling Web Platform standardization cycles), but even in that upbeat blog post, I acknowledge that the standards process leaves much room for improvement.

Google Chrome is Google's browser project based on the extraordinary WebKit portable layout engine. Yes, Google has written their own open source browser. The reasons for Google taking this unusual step are very compelling - as this excellent presentation explains. I also think Chrome will be a game changer. The WebKit engine shows up in Adobe's Apollo RiA and, Apple's SproutCore-Cocoa RiA model. Microsoft of course offers the OOXML-XAML-Silverlight RiA that is based on .NET-WPF proprietary formats, protocols and interfaces. These are RiA efforts can be used as either browser plug-ins or stand alone runtimes. Now Google has entered the RiA fray with both feet coming down hard on a browser based runtime engine. Google RiA isn't a "Plug-in". It's the browser as both a browser and RiA runtime engine. Very cool. Let the battle begin!

Google released its second web browser yesterday afternoon, adding additional headroom for web applications stretching the limits of what it's possible to accomplish within a web browser. The Google Chrome team assembled domain experts in various fields over the past six years, both through direct hires and acquisitions, to create a new browser and its critical components from scratch. GMail and Google Maps pushed the Web to its limits, taking advantage of browser technologies invented in Redmond but left dormant for far too long. Contributing to Firefox's core, writing browser extensions, and championing HTML could only take the $150 billion company so far: they needed to own the full browser to push their Web efforts forward at full speed.

Response to two ZDNet articles about Google Chrome. The first article, "Who Wins with Google Chrome" is very positive, but for mostly all the wrong reasons. The second article, "Five reasons why Chrome will crash and burn" is very critical; again for all the wrong reasons. Clearly much of the world doesn't get RiA. Not do they have a clue as to why it's so important to the future of the Open Web.

Hisham El-Emam's OpenOffice in a browser work

"The biggest rival for Microsoft's next-generation Silverlight web technology will be JavaScript, not Adobe's ubiquitous Flash, according to experts speaking at Microsoft's TechEd conference in Sydney on Friday. " Good article capturing Microsoft's early response to Google Chrome. Not surprisingly they try to pit Chrome against Adobe AiR, and argue that Chrome is a bigger threat to Microsot's XAML-Silverlight RiA than Adobe Flash (AiR). I posted a comment to this article, Divide and Conquer".

"The AIR "robot" application connects to a Java backend that controls the robot through Mindstorm's public Java api, and Java and AIR are then glued together through an open source technology called Merapi. Merapi is an open-source project for connecting AIR and Java run by Adam Flater, and is sure to have an exciting future." This is an excellent example of how many applications are using Adobe AiR. Java is used on the backend with the sophisticated Flash GUI on the front

I've installed and played with Chrome but I'll spare you my review of it. What's more interesting to me and of concern to you is where the Internet is heading as specific client- and server-side technologies (as well as the entities in between) become deeply aligned with one another at the expense of openness. Or should I say Internets?

An AJAX version of the Flash IDE. Incredible!

ZOHO Speaks about Chrome: "The biggest losers in Google's announcement are not really competing browsers, but competing rich client engines like Flash and Silverlight. As Javascript advances rapidly, it inevitably encroaches on the territory currently held by Flash. Native browser video is likely the last nail in the coffin - and Google needs native browser based video for its own YouTube, so we can be confident Google Chrome and Firefox will both have native video support, with Javascript-accessible VOM (video object model) APIs for web applications to manipuate video. As for Silverlight, let me just say that if Silverlight is the future of web computing, companies like us might as well find another line of work - and I suspect Google and Yahoo probably see it the same way too. More speculatively, I believe we will witness the emergence of Javascript as the dominant language of computing, as it sweeps the client side and starts encroaching on the server. The server landscape today is split between "enterprise" platforms like Java and .NET on the one side (we ourselves are in the Java camp on the server side), and "scripting" languages like PHP, Python, Ruby on the other, with Javascript firmly entrenched on the client. Languages like Ruby promise tremendous dynamism and flexibility to the developer, but their relatively weak execution environments have held them back. It is telling that both Java and .NET come with state of the art just-in-time compilers, while none of the major scripting languages do......" Interestingly, ZOHO already has a prototype running on Chrome! Solves tons of performance problems for them, as well as givign them an on-line / off-line story (Gears). The success of Chrome depends on Chrome "killer apps"; Not browser surfing features! And we already have a number of killer apps that will immediately take advantage of Chrome: gMail, gReader, gMaps and Google Docs! ZOHO will no doubt use Chrome to put themselves squarely i

The hope is that a new specification will help companies finally handle and manage all the information stored in different repositories throughout the enterprise. Enterprises have been struggling for years to leverage all the information on business processes they have stored away in order to conduct business better. The problem is much of this information is created in unstructured documents, such as spreadsheets and word processing documents, rather than in a database, making it difficult to control and manage. Several vendors offer enterprise content management (ECM) solutions to deal with unstructured documents, but different vendors' solutions do not talk to each other. Businesses store their unstructured documents in multiple repositories from different vendors, so they have to spend a great deal of time and money to integrate these repositories so they can communicate with one another. A potential solution, the Content Management Interoperability Services (CMIS) specification, was announced today by tech heavyweights Microsoft, IBM and EMC.

"By combining unified communications, IM, SharePoint, and blogs and wikis while protecting its IP, Monsanto is advancing teamwork." InformationWeek has posted a number of technology innovation-implementation profiles. Monsanto is one of the best "collaborative" examples, although it's very similar to the model GE presented at Office 2.0. These colalborative concepts go back 1998, and the early work Ars Digita was doing with the first "Knowledgeware" - wiki applications. The first "use case" to be published was that of the global electronics giant, Siemanns. Notice the SharePoint - MSOffice integration as a key element in the Monsanto collaboration strategy. That connection "forced" Monsanto to rebuild their document databases and portals using SharePoint and SQL Server.

Web Content Editing Made Simple Only EditLive! offers true ease of use with enterprise capabilities. It is the ideal solution for editing rich HTML documents in CMS, wikis, blogs, email and more. Give your content authors an editing solution that they will actually use. The Word-like interface makes content creation easy for business users who know nothing about HTML and want to keep it that way.

Fighting this killer feature is Microsoft Word's own killer feature, which is: Everyone in business has Word, and most people know how to use it effectively. There are plenty of people who would use a simultaneous editing feature in Word if it had one, and who aren't going to switch to Google just because it does. A new service, Plutext, currently being developed, will bring nearly live editing to Word documents. I saw a demo at the Office 2.0 conference.