Group items tagged

Recently the Rocketman and i have been arguing about webkit/Chromium DOM capabilities and limitations; like the failure to fully implement CSS3! Especially missing is support for CSS3 page layout / page break innovations. I realized that i didn't have a good understanding of browser DOM - client side issues, and came across this interesting post from Dave Ward concerning DOM and jQuery.
The core issue behind my discussions with the Rocketman have to do with creating a DOM view from OpenXML and ODF documents, and then passing that view to the webkit/Chromium engine. So we weren't all that interested in cross browser support or in how IE8 handles DOM-JavaScript. Dave Ward however not only provides a good discussion about DOM-JavaScript and the importance of jQuery as a force of interoperability, he also points out that Microsoft supports jQuery - including direct support within Visual Studio!
".....Though JavaScript itself is a great programming language, the document object model (DOM) can be a web developer's worst nightmare.  The DOM is a method through which browsers expose an interface allowing JavaScript code to manipulate elements, handle events, and perform other tasks related to a document within the browser.  While almost every browser implements an ECMA standard version of JavaScript, their DOM implementations are inconsistent and quirky at best.  In fact, if you've had bad experiences with client-side programming in the past, it's likely that the DOM was the true source of your frustrations, not JavaScript itself.  This is exactly the pain point which jQuery addresses....
..... "Officially supported by Microsoft - For many Microsoft developers, this official blessing is the clincher. Not only will Microsoft begin including jQuery with Visual Studio, but it is part of the default ASP.NET MVC project template. What's more, Microsoft Product Support Services has already begun offering support for jQuery."....

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

OK, this article gets my vote as the most important read of the year.  We all know that the the Web is the future of both computing and communications/connectivity.  But wha tis the future of the Web?  Uber coder Mike Loukides says it's JavaScript, and what a compelling case he builds.  This is a must read.  Key concepts are diigo highlighted :) excerpt: JavaScript has "grown up." I'm sure there are many JavaScript developers who would take issue with that judgement, and argue that JavaScript has been a capable, mature, and under-appreciated language all along. They may be right, though you can write any program in any complete programming language, including awful things like BASIC. What makes a language useful is some combination of the language's expressiveness and the libraries and tools available. JavaScript clearly passed the expressiveness barrier a long time ago, even if the ceremony required for creating objects is distasteful. But recently, we've seen some extremely important game-changers: jQuery, JSON, Node.js, and HTML5. JavaScript may have been a perfectly adequate language in the past, but these changes (and a few others that I'll point out) have made JavaScript a language that is essential for every developer to know. If there's one language you need to learn in the next year, it's JavaScript. Insightful comment: HTML5 is a JavaScript API, introducing new elements but significantly redefining ALL elements as objects or classes.  Elements can be expressed with tags.  Or, you can use DOM JavaScripting to create elements. 

Excellent explanation and review from the Tim Anderson. I wonder how i missed this? Here is the summary statement: "..... You can also extend XAML with custom objects. The main requirement is that classes used in XAML must have a parameterless constructor. The procedure is straightforward. Define a class; make sure your application has a reference to the assembly containing the class; then add a namespace declaration for the assembly. You can then define elements in XAML that map to your class, and at runtime these will become object instances. XAML has a curious story when it comes to formatted text, especially in Silverlight. In one sense it is rather limited. XAML has no understanding of common formats such as HTML, CSS or RTF, let alone the fancy new OOXML. Silverlight developers have to interact with the browser DOM in order to display HTML." "... No escaping it: Silverlight .XAP bundle preserves the original XAML. That said, XAML with WPF actually is a document format. The full WPF has an element called FlowDocument and rich formatting capabilities. Silverlight lacks FlowDocument, but does have a TextBlock with basic formatting options via the inline object. It also supports the Glyph element. This is interesting because it is the core element in XPS, Microsoft's invented-here alternative to Adobe's PDF." ".... XPS uses a subset of XAML to describe fixed layouts. In consequence, and with some compromises, you can use Silverlight to display XPS." "..... The bottom line is that XAML is a way of programming .NET declaratively. Its more intricate features improve the mapping between XAML and .NET. The result is we have design tools like Microsoft's Expression Blend and a clean separation between UI objects and program code, which is a considerable achievement." ".... As ever there's a downside, and with Microsoft it's the classic: this is thoroughly proprietary, and the schema issues make it difficult to validate with standard XML tools." No

PhantomJS gives you command-line access to the features of WebKit. According to its website: "Literally it acts like any other WebKit-based web browser, except that nothing gets displayed to the screen (thus, the term headless)." It has native support for DOM handling, CSS selector, JSON, Canvas, SVG, and JavaScript.