Group items tagged

I disagree with the authors conclusions here.  He misses some very significant developments.  Particularly around Google, WebKit, and WebKit-HTML5. For instance, there is this article out today; "Google Really is Giving Away Free Nexus One and Droid Handsets to Developers".  Also, Palm is working on a WiMAX/WiFi version of their WebOS (WebKit) smartphone for Sprint.  Sprint and ClearWire are pushing forward with a very aggressive WiMAX rollout in the USA.  San Francisco should go on line this year!   One of the more interesting things about the Sprint WiMAX plan is that they have a set fee of $69.00 per month that covers EVERYTHING; cellphone, WiMAX Web browsing, video, and data connectivity, texting (SMS) and VOIP.  Major Sprint competitors, Verizon, AT&T and TMobile charge $69 per month, but it only covers cellphone access.  Everything else is extra adn also at low speed/ low bandwidth.  3G at best.  WiMAX however is a 4G screamer.  It's also an open standard.  (Verizon FIOS and LTE are comparable and said to be coming soon, but they are proprietary technologies).   The Cable guys are itneresting in that they are major backers of WiMAX, but also have a bandwidth explosive technology called Docsis. There is an interesting article at TechCrunch, "In Mobile, Fragmentation is Forever. Deal With It."  I disagree entirely with the authors conclusion.  WebKit is capable of providing a universal HTML5 application developers layer for mobile and desktop browser computing.  It's supported by Apple, Google, Palm (WebOS), Nokia, RiMM (Blackberry) and others to such an extent that 85% of all smartphones shipped this year will either ship with WebKit or, an Opera browser compatible with the WebKit HTML5 document layout/rendering model.   I would even go as far as to say that WebKit-HTML5 owns the Web's document model and application layer for the future.  Excepting for Silverlight, which features the OOXML document model with over 500 million desktop develop

Good article on the increasing use of HTML5 for business apps.  The focus is on mobile devices, even though HTML5 clearly targets anything capable of running a WebKit class browser.  The article also demonstrates, albeit unwittingly, the use of HTML5 as a cloud platform "Compound Document" model.  Something far more important than the comparatively limited focus of BI and CRM mobility apps.   A Cloud Producitvity Platform will replace the legacy Desktop Productivity Platform anchored on Microsoft's Windows-MSOffice workgroup networking.  Just as Compound Documents were the fuel of desktop productivity apps and services, a new breed of compound documents will fuel cloud productivity based workgroups.  The article even demonstrates the basics of embedding charts, interactive feeds, media  and database streams in HTML5 document interfaces.  Still missing real time messaging between apps, but clearly the HTML5 cloud compound document model has arrived. excerpt: HTML5 will lead to richer mobile BI and CRM apps that can be used across browsers and devices. HTML has evolved considerably since it was first mapped out by Tim Berners-Lee more than 20 years ago. Now we're up to HTML 5.0, which could have a significant effect on the business intelligence and CRM landscape.

A little tidbit from the Microsoft gathering this evening.  While demonstrating Outlook for Mac and the HTML rendering engine, Microsoft employees revealed that instead of using the Word HTML rendering that previous versions of Mac Office used (and the PC version as well), Microsoft has moved over to Apple's Webkit rendering engine to render HTML mails.  Outlook 2011 also uses WebKit to create HTML mail. For those of you who didn't like Entourage's HTML mail, Outlook's WebKit mail, you are in for a pleasant surprise. Why is this a big deal?  This is the first time that Microsoft has used Apple's Open Source Webkit framework in their products.  It will be interesting to see if Webkit spreads to other areas. Office 2011 ships tomorrow and starts at $110 for a 2 license student edition.

Adobe has contributed the first "CSS Regions" patch to the OS WebKit project.  CSS Regions is at the core of Adobe's flowing Web Typography work, and has been submitted to the W3C CSS standardization effort.   No mention yet as to what kind of CSS3-HTML5 authoring and publication tools Adobe has in the works, but the inclusion in WebKit will no doubt shake things up in the world of visually-immersive packaging (FlipBoard, OnSwipe, TreeSaver, Needle, etc.) excerpt:Today, the first bit of Adobe-written code landed in the WebKit browser engine project, an early step to try to bring magazine-style layouts to Web pages using an extension to today's CSS (Cascading Style Sheets) technology. Adobe calls the technology CSS Regions. The move begins fulfilling a plan Adobe announced in May to build the technology into WebKit and--if the company can persuade others to embrace it--furthers Adobe's ambition to standardize the advanced CSS layout mechanism. WebKit

Good interview with Charles Jolley - SproutCore - WebKit (met Charles at Web 2.0).  He has left Apple and started a SproutCore Web App development company called "Strobe".  Looking very good Charles! The Blended Brew Apps have become a preferred way of accessing information on mobile devices. But developers want to provide a unified experience, and that is why Jolley believes that we will soon have apps that use HTML5 inside a native app wrapper. "People are looking for an either/or solution, but it is not going to end up like that," he said. Think of Strobe's offerings as a way to create an experience that is a blend of HTML5 and native mobile apps. How this works is that an application is developed in HTML5 instead of proprietary formats. It is wrapped in a native app wrapper for, say, the iPhone, but when accessed through a web browser on a PC or any other device, like tablet, it offers the same user experience. This is a good way to solve a problem that is only going to get compounded many fold as multiple endpoints for content start to emerge. The co-existence of web and native apps also means content publishers need to think differently about content and how it is offered to consumers. The multiplicity of endpoints (iPhone, iPad, TV and PC) is going to force content producers to think differently about how they build the user experiences for different sets of screens. Jolley argues that the best way to do so is to stop taking a document-centric view that is part of the PC-era. In the touch-based mobile device era, folks need to think of ways to have a single technology stack married to the ability to create unique experiences for different devices. And if you do that, there is no doubt that HTML5 and native apps can live in harmony.

Good quotes.  The Wired article is also worth reading.  The important take away being that Apple is fully committed to native browser HTML5.  So is Google.  But, i found out at the Web 2.0 - WebKit party in 2009, there is quite a bit of tension between Apple WebKit and Google.  The problem being that Apple is doing all the work while Google is pumping up HTML5, Web Sockets and Native Client; all of which are essential to WebKit, but also to Chrome OS, Chrome, Android and the Google Apps push. excerpt:  According to Wired, at an Apple "town hall" meeting after the introduction of the Flashless iPad, Steve Jobs unloaded on Google, calling the search giant's "don't be evil" motto "bullshit," before rounding on Adobe. "They are lazy. They have all this potential to do interesting things, but they just refuse to do it," he said. "Apple does not support Flash because it is so buggy... Whenever a Mac crashes more often than not it's because of Flash. No one will be using Flash...The world is moving to HTML5."

Is Adobe AiR a Virtual Desktop?  We expect a VD to run an alien OS and those OS specific applications.  With AiR 2.0 it seems Adobe has ditched the "OS" component of a VD, and the OS specific applications, but is quite capable of running AiR based applications and information services that would otherwise have been designed for a specific OS environment.   Another way of looking at this would be to say that VD's are designed to run existing OS and OS specific applications, while AiR is desinged to run newly written OS independent applications that have one very important advantage over legacy applications and information systems;  AiR speaks the language of the Web 3.0.   This is WebKit HTML5-CSS3 with an advanced but Air specific version of JavaScript called "ActionScript".  What Adobe doesn't do is provide support for other critically important aspects of the WebKit interactive Web 3.0 model: support for Canvas/SVG!  Adobe continues to push the proprietary SWF interactive vector graphics format.   Note that Microsoft's Silverlight universal runtime does not support anything in the WebKit Web 3.0 model!  It's all proprietary. excerpt: For the first time since 2007, Adobe has updated its Air platform, released recently in beta with a slew of new features. The features include support for detection of mass storage devices, advanced networking capabilities, ability to open a file with its default application, improved cross-platform printing, and a bunch of other things that you probably won't really notice in any other way other than your Adobe working significantly more efficiently and smoothly than before. The 2.0 version of Air also will be able to support HTML5 and CSS3, due to an upgrade of its WebKit. Developers will also be happy to know that they can create Air applications that can be installed through a native installer. Air's changes have seen it morph into something of an 'operating system sitting on an operating system'. According

The Future of the Open Web You're right that the browser wars do not matter - except for this point of demarcation; browsers that support HTML+ and browser that support 1998 HTML. extensive comment by ~ge~ Not all Web services and applications support HTML+, the rapidly advancing set of technologies that includes HTML5, CSS3, SVG/Canvas, and JavaScript (including the libraries and JSON). Microsoft has chosen to draw the Open Web line at what amounts to 1998-2001 level of HTML/CSS. Above that line, they provision a rich-client / rich-server Web model bound to the .NET-WPF platform where C#, Silverlight, and XAML are very prominent. Noticeably, Open Web standards are for the most part replaced at this richer MSWeb level by proprietary technologies. Through limited support for HTML/CSS, IE8 itself acts to dumb down the Open Web. The effect of this is that business systems and day-to-day workflow processes bound to the ubiquitous and very "rich" MSOffice Productivity Environment have little choice when it comes to transitioning to the Web but to stay on the Microsoft 2010 treadmill. Sure, at some point legacy business processes and systems will be rewritten to the Web. The question is, will it be the Open Web or the MS-Web? The Open Web standards are the dividing line between owning your information and content, or, having that content bound to a Web platform comprised of proprietary Microsoft services, systems and applications. Web designers and developers are still caught up in the browser wars. They worry incessantly as to how to dumb down Web content and services to meet the limited functionality of IE. This sucks. So everyone continues to watch "the browser wars" stats. What they are really watching for though is that magic moment where "combined" HTML+ browser uptake in marketshare signals that they can start to implement highly graphical and collaboratively interactive HTML+ specific content. Meanwhile, the greater Web is a

Return to the bad old days Many of Apple's demos rely on "experimental" CSS3 properties to work. The exact implementation of these properties has yet to be hammered out, so browser vendors must use their best guess to determine how they should be rendered onscreen. Because of the ambiguity this introduces, it is the custom for browser vendors to attach a vendor-specific prefix to the CSS property names. Firefox uses "moz," while Safari uses "webkit," named for the browser's WebKit rendering engine. This means Web developers who want to use a specific experimental CSS feature must include the vendor-specific properties for each browser they want to support in their style sheets. It's a less than ideal situation, but the actual coding required is trivial. Apple chose not to bother for its HTML5 demo site. That would be bad enough. But Apple's demos don't work on Google's Chrome browser, either -- and Chrome also uses the "webkit" prefix for its experimental CSS3 properties (because it's also based on the WebKit rendering engine). Rather than detecting browser capabilities and degrading the user experience gracefully where features aren't supported -- as is the accepted best practice on modern browsers -- Apple chose to deliberately screen out any browser that doesn't self-identify as Safari. That's right: By forcing my browser's user agent string to identify as Safari 5, I was able to view many of the demos just fine in Firefox 3.6 on Windows. Seriously, Apple? I thought we left elaborate browser-detection scripts behind in the bad old days of the 1990s. I can't imagine anyone would want to start up the practice again, let alone one of the leading companies in the development of next-generation Web standards.

Jonathan Deutsch and Ryan Nielsen left Apple late last year to join Y Combinator's accelerator program and help designers build animations in HTML5 as opposed to Flash. Friday, the two-man team is releasing Hype, the first product of their startup Tumult, on the Mac App Store. Hype, which sells for $29.99, uses WebKit to render pages and has been crafted so that anyone comfortable with using Keynote or PowerPoint can start building animations in HTML5, no code required. "It's pretty clear that HTML5 is the future of the web," says Deutsch. "It will, of course, run not only on desktop machines but also runs really well on any modern smartphone or tablet like the iPad. The problem is that there are no good designer apps for creating animated HTML5 like there are for Flash." Hype presents the user with a blank canvas with a timeline at the bottom. The user can then drag in images, video and text, arrange those elements and use keyframe-based animations to define where those pieces of content go.

Notification of this article also appeared in the Diigo Document Wars Group..... WebODF...   An especially interesting project that was presented is WebODF, which wants to bring ODF to the web. Jos van den Oever started from the observation that a lot of office suites are moving into the "cloud". Examples are Microsoft Live Office, Google Docs, and Zoho. But where are the free software alternatives for the cloud? For OpenOffice.org, KOffice, AbiWord, and Gnumeric, there are none that have a cloud version with ODF support. That was the motivation for Jos to start a project to fill in this gap and let users view and edit ODF documents on the web without losing control of the document into some company's servers. The strategy Jos followed was to use just HTML and JavaScript for the web application. The application then loads the XML stream of the ODF document as is into the HTML document and puts it into the DOM tree. Styling is done by applying CSS rules that are directly derived from the and elements in the ODF document. That is how WebODF was born; it is a project with the initial goal of creating a simple ODF viewer and editor for offline and online use, implemented in HTML5. The small code base consists of one HTML5 file and eight JavaScript files, each of which is a few hundred lines of code. The most interesting part is that it doesn't need server-side code execution: the JavaScript code is executed in the user's browser and saving the document to the web server is done using WebDAV. It supports both the Gecko and WebKit HTML engines. There is also an implementation on top of QtWebKit, which is for better desktop integration, and an ODFKit implementation. This means that WebODF is an easy way to add ODF support to almost any application, be it in HTML, Gtk, or QML. KO GmbH has received funding from NLnet to improve the current WebODF prototype and see how far the idea goes. Interested readers can try the online demo

While HTML5 developers are working directly with JavaScript, SVG, CSS, and other technologies, Flash designers enjoy a high-level environment with timelines, drawing tools, easy control of animation effects, and more. With Edge, released in beta Sunday, Adobe is striving to bring that same ease of use to HTML5 development. The user interface will be familiar to anyone who's used Flash or After Effects; a timeline allowing scrubbing and jumping to any point in an animation, properties panels to adjust objects, and a panel to show the actual animation. Behind the scenes, Edge uses standard HTML5. Scripting is provided by a combination of jQuery and Adobe's own scripts, and animation and styling uses both scripts and CSS. Pages produced by Edge encode the actual animations using a convenient JSON format. Edge itself embeds the WebKit rendering engine-the same one used in Apple's Safari browser and Google's Chrome-to actually display the animations.

And so there will be only three major web page rendering engines, webkit, mozilla's gecko, and MSIE. with only webkit in the ascendancy. 

Chrome runs as close as any browser can to the bleeding edge of Web standards. Though it uses the same open source WebKit rendering engine as Safari, it doesn't reliably support the controversial, proprietary CSS3 transformation and animation tricks that Apple's built into Safari. However, like every browser I tested, it earned a perfect score in a compatibility test for CSS3 selectors, and it joined Safari and Opera with a flawless score of 100 in the Acid3 web standards benchmark. Chrome 5 also supports both Apple's H.264 codec and Mozilla's preferred open source Ogg Theora technology for plugin-free HTML5 video, and it beautifully played back HTML5 demo videos from YouTube and Brightcove. In XHTML and CSS tests, Chrome was surprisingly slower than Safari, despite their shared rendering engine -- but the race was close. Safari rendered a local XHTML test page in 0.58 seconds to Chrome's 0.78 seconds, and a local CSS test page in 33 milliseconds to Chrome's 51 milliseconds. Note that Chrome still rendered XHTML more than twice as fast as Opera (1.67 seconds) and left Firefox (12.42 seconds--no, that's not a typo) eating its dust. In CSS, it also beat the pants off Opera (193 milliseconds) and Firefox (342 milliseconds). But Chrome shines brightest when handling JavaScript. Its V8 engine zipped through the SunSpider Javascript benchmark in 448.6 milliseconds, narrowly beating Opera's 485.8 milliseconds, and absolutely plastering Firefox's 1,161.4 milliseconds. However, Safari 5's time of 376.3 miliseconds in the SunSpider test beat Chrome 5 handily.

Despite initial comments in support of HTML5 as an option standard, Adobe has taken action to sabotage the open specification in an effort to support its existing position with Flash. Ian Hixie, a member of the HTML5 working group and an employee of Google, reported this week that "the latest publication of HTML5 is now blocked by Adobe, via an objection that has still not been made public (despite yesterday's promise to make it so)."

You need an HTML5 ready browser to visit this demonstration.  Amazing stuff though.  The latest Chrome beta 3.0.196.2 works well.  Ajaxian has a review of this at:  http://ajaxian.com/archives/audio-canvas Lots of Webkit tweets in the demo!

Pretty funny quote: "I think the future is going to WebKit". Brad Neuberg is leaving the gDOCS-Chrome JavaScritpt team to strat his own "HTML5" business. He's an expert on the SVG Web. About a year ago i read a lament from a web developer concluding that SVG was destined to be the Web docuemnt format, replacing HTML. Now i wonder if that guy was Neuberg? http://news.cnet.com/8301-30685_3-20018687-264.html Sent at 10:05 AM on MondayGary: Finally, the money shot: "Somebody will take some HTML5, and geolocation, and mobile applications, hook into Facebook perhaps, and they're going to do something unexpected." Read more: http://news.cnet.com/8301-30685_3-20018687-264.html#ixzz124U9xTZ3 Sent at 10:13 AM on MondayGary: I think Brad is right about the combination of location with the rest of the App Web. Olivia and i have had our EVO's for about two weeks now and it's amazing. She also has Citania's iPAD, also an amazing device. What stuns me about the Android EVO is how extraordinary the apps are that combine location with information specific to that location. Incredible. I don't know how i ever lived withou this. One things for sure, my desktop can't do this and neither can my notebook. Sent at 10:16 AM on MondayGary: There is another aspect i see that i guess could be called "location switiching". This is when you QR Scan QR barcode on something and the location of that objects life is at your fingertips. Everything from maps, street views, web sites, product history, artist/designer/developer and on and on. We went to the San Carlos Wine and Art Festival yesterday, where Laurel and San Carlos streets are closed off to traffic, and lined with food, wine and beer vendors of all sorts, artists and craftsmen, and even an antigue car show with ully restored automobiles and other vehicles. It was amazing. But then i started QR scanning! Wow. The Web merged with life like nothing i've ever imagined possible.The key was having the Internet in my pocket, and the Internet k

Ext JS, said Mullany, includes numerous UI elements and handlers that are built entirely from CSS 3, HTML5 and JavaScript. As a result, the applications built with Ext JS can be run on any WebKit-based browser. Both Android and the iPhone use WebKit-based browsers, and RIM should soon offer one as well for BlackBerry users. Mullany said each interface element is built on top of CSS, and can therefore be skinned and modified by designers after creation. He also said this limits the size of the code that must be embedded in each page with Ext JS elements. Ext JS is available for free under the GPL. For commercial users, the software will cost US$1,000 per developer per year.

Web technologies are increasingly being used on the desktop to bring richer user interfaces to conventional applications. In this tutorial we will show you how to use the WebKit HTML renderer alongside native GTK+ widgets to make a desktop WYSIWYG editor with Python.