Home
Gary Edwards's Library tagged → View Popular
The Future of Web Layout: CSS 3 Flexible Box Model | Ajaxian »
Florian is fond of pointing out to me that Open Web HTML+ lacks a representational model - a standard method for layout that can then be interoperably rendered across any ACiD 3 browser. Florian is right that HTML+ is not quite there yet. But many engineers and Web designers are working on this problem. The W3C may have dropped CSS layout years ago, but the WebKit and Mozilla faithful toil upwards through the night to get it right. The Flexible Box spec pushes the envelope.
Excerpt: Alex Russell has been having a really interesting discussion with some standards folks about what is wrong on the Web right now, and it narrowed down to discuss CSS variables as a case study (it aint perfect, but get DRY and ship it!)
Alex tells it how it is, but people forget that he does this as he is passionate about the Web, and that he does also give credit and positive outlook IF it is due!
His latest post shows this as he talked about CSS 3 progress and specifically the flexible box model that Mozilla and WebKit have had forevaaaaaah:
David Baron (of Mozilla fame) is editing a long-overdue but totally awesome Flexible Box spec, aka: “hbox and vbox”. Both Gecko and WebKit-derived browsers (read: everything that’s not IE) supports hbox and vbox today, but using it can be a bit tedious. Should you be working on an app that can ignore IE (say, for a mobile phone), this should help make box layouts a bit easier to get started with:
On Mobiles, There’s No Stopping Webkit
Great title, no substance. But who can pass this up? Even if it's been obvious since the 2007 release of the iPhone. WebKit Rules the Edge of the Web today! Tomorrow, the greater Web will follow.
Excerpt: There are a lot of brave souls out there making mobile browsers, hoping to gain traction with the phone makers. But most of them are fighting a losing battle, for the mobile browser war is increasingly being fought between two camps — the Webkit-based browsers camp, which includes Safari on the iPhone, the Google Android Browser, the Palm browser and the Nokia browser; and the Opera camp.
The Anatomy of an iPhone Site | Build Internet!
In today’s world the internet travels. Not just through laptops and wireless signal, but through a growing number of smart phones. The trick? Getting your site to travel just as well.
Build to Touch: The iPhone did two things differently. The full browser was a good first, but the second changed the fundamentals of interaction in a new direction. The phone is driven by touch. The best applications and websites have navigations that compliment this. Buttons are larger and more accommodating, and interfaces become more intuitive when they seem tactile.
The iPhone did two things differently. The full browser was a good first, but the second changed the fundamentals of interaction in a new direction. The phone is driven by touch. The best applications and websites have navigations that compliment this. Buttons are larger and more accommodating, and interfaces become more intuitive when they seem tactile.
For the average web designer, you’ll save yourself a significant amount of time and headache by simply giving the site some iPhone sensitive browser design. Applications must be approved before going live, and can require extensive knowledge of development tools.
The End of Flash and Silverlight: HTML5 Canvas and Audio Experiment
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!
Why Cloud Computing is the Future of Mobile
This one's for Florian. He's been wondering about mobile computing and that creeping sense of being left out of something big. The desktop is so not happening. It's day has come and gone. Now there is a study out from ABI Research, connecting mobile computing to the future of the Web. Good stuff:
Intro Excerpt:The term "cloud computing" is being bandied about a lot these days, mainly in the context of the "future of the web." But cloud computing's potential doesn't begin and end with the personal computer's transformation into a thin client - the mobile platform is going to be heavily impacted by this technology as well. At least that's the analysis being put forth by ABI Research. Their recent report, Mobile Cloud Computing, theorizes that the cloud will soon become a disruptive force in the mobile world, eventually becoming the dominant way in which mobile applications operate.
How to build a desktop WYSIWYG editor with WebKit and HTML 5 - Ars Technica
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.
Meet Google, Your Phone Company
Om Malik has an interesting commentary on Google Voice, the Android OS, and a new gVoice application for iPhones and Androids. For sure, new gVoice app meshes into the Andorid OS as if it were hard coded into the silicon.
I left a lengthy comment in the discussion section describing my experiences with gVoice and what i see emerging as Google's Unified Productivity Platform. Of course, gWave, Chrome, Chrome OS, webkit-HTML+, and the sweep of Google Web applications and service come into play.
Excerpt: Can Google be your phone company? The answer is yes. I came to that conclusion after I met with Vincent Paquet, co-founder of GrandCentral (a company acquired by Google) and now a member of the Google Voice team. Earlier today he stopped by our office to show the mobile app versions of its Google Voice service for Blackberry and Android. Google recently announced that it was going to make the Voice service widely available to users in the U.S. soon.
Martian Headsets - When the Problems with Standards Becomes the Standard Itself | Joel on Software
Joel takes on the difficult issues of standards and vendor specific implementations. This is a classic!
Cisco: Google Wave Completes Us | Michael Hickens
Über technologist Michael Hickens writes about the recent Cisco announcement that they intend on competing with Google, Zoho and MOSS in the cloud collaboration space. I left a lengthy comment on this page, trying to come to grips with the meaning of this challenge. I titled my comment, "Cisco Office? Maybe they should consider Feng Office-in-the-Cloud". Good luck Conrado. Go get them.
Interestingly, Jason Harrop and i met Ms. Alex Hadden-Boyd, director of marketing for the collaboration software group at Cisco. She was kind enough to refer me directly to David Knight, the technology director of Cisco's WebEX Conferencing initiative. Alex is quoted in a CNet article at:
http://news.cnet.com/8301-1001_3-10276549-92.html
Cisco is striving to redefine itself as a vendor connecting inner and outer clouds, thus reasserting its relevance in the context of a fluid Web-driven IT world increasingly dominated by the likes of Google, Salesforce, Oracle and IBM. It also hopes to parlay its legacy of infrastructure expertise into a reassuring presence, particularly for veteran IT administrators struggling to balance their in-house infrastructures against the cost-savings and potential efficiencies of cloud computing.
Google's Microsoft Fight Starts With Smartphones |
Michael Hickens has been writing about Google Wave and how it will forever change the Web. In a recent article he took on the incredible WebKit - HTML+ phenomenon, tying in the surge of WebKit marketshare at the edge of the Web with dramatic changes taking place across greater Web.
<br>
From Michaels article: .... "I recently described how Google's Wave, a collaboration tool based on the new HTML 5 standard, demonstrated the potential for Web applications to unglue Microsoft's hold on customers. My post quoted Gary Edwards, the former president of the Open Document Foundation, a first-hand witness to the failed attempt by Massachusetts to dump Microsoft and as experienced a hand at Microsoft-tilting as anyone I know......"
<br>
The year 1998 marked the end of the browser wars, the end of Netscape, and the beginning of Microsoft's anti-trust woes. It also marked the beginning of XML, and the end of HTML, with the W3C leaving HTML, CSS and SVG to rot. What a year.
<br>
Today we find the landscape considerably changed. Instead of a browser war between Netscape and Microsoft, ending with the triumph of an IE monopoly, today we have a browser race. And IE isn't a contender, having been pretty much abandoned by Microsoft once they had Netscape in the dirt.
<b>
The introduction of XML 1.0 in 1998 ushered in a new era of customized XML schema's for all kinds of data exchanges. The Web came alive with data flows from disparate databases and transaction systems that were never designed to talk to each other. The noise across the Web, private and public, was deafening.
<br>
There was however a few notable attempts to encode document based content in XML, with OpenOffice ODF and MSOffice OOXML taking center stage. Unlike the excitement and extraordinary Web capabilities that surrounded XML data schema work, XML documents veered away from the Web. By design, ODF and OOXML are incompatible with the language of the Web. But given the legacy of client/server dominance powerful "end-user-facing" desktop office
Forrester: Microsoft Office is in no danger from competition - FierceCIO:TechWatch
More comments from ge
Microsoft Office vs. the other guys - FierceCIO:TechWatch
A new report by research analyst, Forrester says that 80 percent of enterprise customers are using some version of Microsoft Office. This reflects the stranglehold Microsoft has on the office productivity market, despite increased awareness of alternatives such as Sun's OpenOffice.org suite, and the rise of web-hosted variants such as Google Docs.
I had a chance to comment on this brief lament regarding Microsoft's iron grip, desktop monopoly.
Google Bets Big on HTML 5: News from Google I/O - O'Reilly Radar
What a loaded statement. This was at the beginning of Google I/O. Incredibly, the rest of the show proved their point. Google backed up all the grand assertions with running code and developer affirmations. Incredible. Here's a taste:
<i>...Google, Mozilla, and Palm gave us all a big whack upside the head this morning. As Shakespeare said, "The hot blood leaps over the cold decree." The technology is here even if the standards committees haven't caught up. Developers are taking notice of these new features, and aren't waiting for formal approval. That's as it should be. As Dave Clark described the philosophy of the IETF with regard to internet standardization, "We reject: kings, presidents, and voting. We believe in: rough consensus and running code."
<br>
Support by four major browsers adds up to "rough consensus" in my book. We're seeing running code at Google I/O, and I'd imagine the 4000 developers in attendance will soon be producing a lot more. So I think we're off to the races. As Vic said to me in an interview yesterday morning, "The web has not seen this level of transformation, this level of acceleration, in the past ten years."</i>
Google shows Native Client built into HTML 5 | Webware - CNET
<i>"........ Google Native Client, still highly experimental, lets browsers run program modules natively on an x86 processor for higher performance than with Web programming technologies such as JavaScript or Flash that involve more software layers to process and execute the code. But to use it, there's a significant barrier: people must install a browser plug-in.
However, Google wants to make the technology more broadly accessible in browsers through new technology coming to HTML, the standard used to build Web pages, and at the Google I/O developer conference Thursday demonstrated its work to make that happen...."</i>
Looks to me that Google is attacking the problem of integrating a Chrome browser with x86 desktop metal. Maybe it's the only way to get webkit/Chromium Web Apps on a par with native x86-Windows desktop apps?
There is that infamous quote describing the Google v Microsoft challengeto consider: "Google has to replace the MSOffice productivity environment on the desktop "Client" before Microsoft replaces Google apps and services on the "Server". (Same holds true for IBM Lotus Notes - WebSphere on the Server and OpenOffice/Symphony on the desktop client).
The quote actually comes from some high level Microsoft document experts, said to have been uttered while under the glaze of legendary Czech Pilsners during a recent ISO meet up in Prague. Looks like there is far more to this quote than meets the eye. I wonder though. Google is looking good. So good that perhaps they are confident enough to take things public - as the events at Google I/O seem to indicate?
~ge~
Comment for Jesper on the Groklaw "Digging at those who tell the Truth" article
Lengthy response to Jesper's Groklaw comment. Groklaw rips apart Alex Brown, convenor of the ISO JS34 docuemnt standards group.
How to Get Started with iPhone Dev | Webdesigner Depot - Etan Rozin
With millions of iPhones out there, it makes sense to have your content, or application available on that platform, but how do you go about doing this? Where do you go to get started? And what are the steps you need to take to get there?
This article from interface designer, Etan Rozin, is an introduction to the various ways of getting content and applications onto the iPhone. It is by no means a full guide, but hopes to point you in the right direction and give you an overview of what is involved in the process.
Excellent explanation and collection of valuable resources!
WebKit OS: Why Some Developers Think the Palm Pre Could Upstage the iPhone
Todd Williams, vice president of technology and co-founder of Genuitec, which has been eyeing the Pre and its developer platform, said, "The Pre is the only phone that fully embraces the belief system that mobile Web applications are the way that enterprise mobile content will be delivered going forward. And the mobile Web is the only programming model for the Pre. WebOS is basically a WebKit-based browser that has been expanded into a complete operating system. Thus, the 'native’ programming model for the Pre is HTML5/CSS3/JavaScript. There is no other model. Mojo is a JavaScript framework that provides easy integration and access with all ‘on phone’ content [contacts, calendar, etc.] so applications as rich as any phone's native applications can be built with modern Web technologies."
Groklaw - Digging for Truth : The problem with XML document formats
Jesper Lund Stocholm was kind enough to point out that, once again, GrokLaw is stoking the fires of the XML document wars. This time PJ takes on Alex Brown, of the ISO SC34 document standards group convenor. And Alex responds ... and responds ... and responds. of course, the attacks keep coming!\n\nI left Jesper a rather lengthy comment at: <a href'="http://tinyurl.com/document-wars">Document Wars</a>
-
Wow! The ODF peasants with pitchforks are have taken to the streets, and ISO document expert Alex Brown is taking them on. The volumes of traffic generated by any discussion of the ISO XML document wars continues to amaze. It's very one sided though.
The basic problem seems to be that ISO has accepted two XML document format standards, OOXML and ODF, with OOXML being held to a higher set of expectations than ODF. Alex would do well if he could step back from the OOXML - ODF war, and move the discussion to something like the theoretical IDABC ODEF: the European "Open Document Exchange Formats" design.
With ODEF as single set of XML format requirements against which both OOXML and ODF can be measured and compared, Alex might be able to neutralize the heated emotions of angry Open Source - Open Standards - Open Web supporters, who mistakenly think ODF measures up to ODEF expectations and requirements. Trying to compare ODF to OOXML isn't getting us anywhere.
At some point, we have to ask ourselves what is it that we want from a standardized XML document format. Having participated in both the Massachusetts pilot study and the California pilot discussions, i have to say that the public expectations were that XML formats would have a basic set of characteristics: open markup; structured separation of content, presentation and logic; high level interoperability (exchange), and Web ready.
These are basic "must have" expectations. XML formats were expected to be "better" than 1998 HTML-CSS. But when we apply the basic set of expectations, todays HTML+ (webkit HTML5, CSS4, SVG/Canvas, JS, JS Libs) turns out to be a far better format.
Where the XML formats really fall off the wagon are the interoperability and Web ready expectations. For the life of me i don't see how anyone can compare ODF or OOXML interoperability with that of HTML+. And of course, HTML+ is the native language/format of the Web. OOXML is only "interoperable" within the Microsoft platform of applications. ODF interop is simply laughable; with the ever embarrassing and problematic example of exchanging ODF documents between OpenOffice and KOffice - both of which have been anchor participants on the OASIS ODF TC since it's inception. (The application specific Open Office XML format specification was the 2002 foundation of what we now know as ODF. KOffice joined the OASIS ODF TC in February of 2003, less than two months into work on ODF). Neither OOXML or ODF are Web ready formats.
Meanwhile, with over 60 billion public documents and another estimated 35 billion behind the firewall, HTML+ is perhaps the most interoperable document format the world has ever known. Sure, there are cross browser problems demanding lots of workarounds resulting in a general dumbing down of document functioanlity - but that's clearly an application implementation problem. As Open Web browsers race to prove their HTML+ compatibility with the webkit weighted ACiD-3 test, the foot dragging of proprietary Web vendors becomes ever more obvious.
Clearly we need an ACiD-3 test for XML and HTML+ formats. One geared to measure applications and their documents against the basic expectations.
What ODF and OOXML have over HTML+ is the advantage of heavy weight desktop editors. Let's be blunt here. There are no native HTML+ office suite editors. The four primary contenders (MSOffice, OpenOffice, KOffice and WordPerfect) all fail when it comes to native, read/write HTML+. Leading Open Web editors like Google Docs, Zoho, Zooos, and BuzzWord, struggle to achieve acceptable exchange with desktop office suites, instead of delivering the kind of robust webkit HTML+ the Open Web demands. Reuter's Rule kicks in here, and it is harsh and unforgiving; "Conversion breaks documents". Whether this breakage is measured in terms of presentation fidelity, application specific settings, or embedded logic, the breakage is unavoidable. It's a killer, certain to take a business document out of workflow or workgroup process.
There is a sad truth behind this situation. HTML was designed to be application neutral. Both of our dominant XML formats however were designed as application specific. 1998 is perhaps a key date here. XML 1.0 was released as a meta-language; a language for writing specific purpose languages. With the release of the XML specification, the W3C began to pull back from further development of HTML and CSS - especially as they might evolve as a structure and presentation markup combo.
OpenOffice and MSOffice seized the XML moment, using the meta-language advantages to create application specific XML encodings of their binary document dump. This is not something they could have done with HTML-CSS in 1998. But looking back, one has to wonder what the world would be like today if OpenOffice had decided to eXtend 1998 HTML-CSS, submit the eXtensions to the W3C, and become the world's first native Open Web office suite of editors.
It turns out there was in fact many internal discussion at StarOffice, prior to the decision to go with an application specific XML encoding, concerning the creation of a Web browser as part of their suite. Legend has it that these discussions twisted on the costly problem of having to rewrite the internal layout engines of the office suite editors to produce quality HTML-CSS documents viewable in a browser. Excitement over XML, and the simplicity of encoding the binary dump without having to rewrite the layout engines, resulted in an easy decision: drop the browser and forget about the costly problems of native HTML-CSS.
The trade off that comes with feature filled but application specific XML is two fold: zero interoperability and Web dead documents. The advantage is that XML can be customized to fit every application, platform and vendor specific nuance known or unknown. With XML formats and data schemas , application vendors are free to drive a desktop to Web to server to device platform convergence in line with whatever business objectives and opportunities the future might present.
The problem with these infinitely customizable but application specific XML formats is that the public expects powerful office suites and compliant editors to provide the kind of interop and Web readiness we get with HTML+. And it's simply not there. Nor do i think there is any chance it will ever be there.
Perhaps if our first XML format effort had been an application independent eXtension of HTML-CSS-SVG-JS, designed to fully accommodate complex and compound office suite documents, we would find ourselves in a different situation. With two application specific XML formats now sitting as ISO standards, and application specific variations of each XML format sprouting like weeds, i don't think we can ever go back to 2002, and start all over. What's done is done. We have three formats to consider: ODF, OOXML and HTML+. The strengths of ODF and OOXML is that of powerful desktop editors. The weakness of these XML formats is exactly the strength of HTML+: interoperability and Web readiness.
IMHO, there are two ways forward; replace or re-purpose the desktop editors.
Replacement is beyond costly in that years of business systems and workgroup processes based on client/server architectures has left most business bound to the MSOffice productivity environment. Replacing MSOffice will break these business processes in much the same way as document conversions break these processes and workflows. As every pilot study has demonstrated, replacement is costly and disruptive.
Nor does it work to set up parallel Web ready systems; thinking that it's possible to do MSOffice bound business stuff in one suite of editors, while doing collaborative Open Web editing in another. Integrated "value added" Web functionality will trump parallel systems every time. Editing business documents in MSOffice, especially those based on templates, and then trying to collaborate on these documents in Google Docs, ends up being frustratingly counterproductive.
Microsoft holds the integration key, and they will use it to leverage their desktop monopoly into a proprietary MS WebStack-Cloud-Ria centered business systems monopoly. The Microsoft "rich-client / rich server" strategy does however depend on the successful re-purposing of MSOffice as a Web front end. In this vision, the MSOffice productivity environment becomes a browser on steroids.
For Microsoft, the way forward is clear. They will re-purpose MSOffice to become an editor suite of MS Web documents. Instead of HTML+, Microsoft offers the proprietary and platform specific .NET-WPF technologies that include XAML, Silverlight, Smart Tags, LiNQ, XPS, VML, etc. These proprietary technologies are alternatives to Open Web formats, protocols and interfaces found in HTML+.
The thing is, it's entirely possible to re-purpose MSOffice 2003 and 2007 to natively speak Open Web HTML+. This may not apply to MSOffice 11 though. And who knows, maybe somebody will take a close look at the emerging OpenOffice plug-in architecture and discover a means of re-purposing to HTML+?
The advantage of this re-purposing approach is that once the powerful editors are able to speak native HTML+, that opens up the desktop to interoperability and collaboration with a world of Open Web editors, browsers and server systems. Exactly what the world expected, but sadly did not get, from the XML format efforts.
Hope this helps,
~ge~ - garyedwards on 2009-04-15 -
Jespers comment has somehow been clipped from this Diigo preview. Here is the full context:
The problem with that, as I understand it, is that the transitional spec is pretty much unimplementable by anybody except MS
Well, herein lies the problem, dude ... you don't understand it.
The collective comments of gary.edwards's as posted on CNET
Wow. i had no idea this existed until one of the attorney's working on the New York State <i>XML format</i> pilot study started asking questions based on this link. In particular he was interested in a further explanation for this particular clip:<br><br.
"..... "The hard truth is that ODF was not designed to meet the market requirements that stopped cold the implementation of ODF in Massachusetts. Those requirements are: compatibility with existing file formats, including MS binary documents; interoperability with existing applications, including MSOffice; and, able to work across the grand convergences of desktop, server, device and web systems. ....."
Selected Tags
Related Tags
Sponsored Links
Top Contributors
Groups interested in webkit
-
WebArchive
WebArchive is both: a platf...
Items: 62 | Visits: 56
Created by: Graham Perrin
-
WebKit and the Future of the Open Web
WebKit is an advanced HTML-...
Items: 20 | Visits: 104
Created by: Gary Edwards
-
WebKit - Kupu - Plone
Listing some of the issues ...
Items: 5 | Visits: 35
Created by: Graham Perrin
Highlighter, Sticky notes, Tagging, Groups and Network: integrated suite dramatically boosting research productivity. Learn more »
Join Diigo