psychology dector

The Web Components community has a new site: WebComponents.org . Quoting Addy Osmani : WebComponents.org is the home for the community to learn and discuss Web Components. The site had previously been soft-launched at webcomponents.github.io and is now online at the final URL. It’s good to have a single site with a simple URL where one can look up information related to this important technology. The site’s twitter account is @Web_Components . WebComponents.org features icons for the Web Components sub-standards (Shadow DOM etc.), which can be downloaded in various formats at a repository on GitHub. Previously, the best location with Web Components resources was a page by Eric Bidelman. I’m hoping that this page will be merged into WebComponents.org.

At the moment, there are two polyfills for the upcoming Web Components standard (roughly, for widgets): Polymer by Google X-Tag by Mozilla Fortunately, the three ways of writing a Web Component (via the Polymer polyfill, via the X-Tag polyfill or by using the APIs directly) are interoperable. Quoting “ Custom Element Interoperability ” by the Polymer team: We’re happy to say that, yes, custom elements of any variety (be they Polymer, X-Tag or vanilla) can all happily coexist. The blog post explains how that works and provides an example that you can download from GitHub. Third Web Component polyfill: @b_lionel told me about Bosonic , which is partially based on Polymer and also interoperable .

Today, there was an online event called “Hello Polymer”, in which Polymer team members Eric Bidelman, Alex Komoroske and Matthew McNulty talked about the framework. This blog post summarizes what happened. The actual video of the event starts at 2:40 . Goals and nature of the project Web components are a set of APIs (shadow DOM, templates, custom elements, etc.) that will enable cross-framework widgets and user interface elements for the web. The main goal of the Polymer project [1] is to help with designing those APIs. To that end, it polyfills them on modern browsers so that experience with them can be gained – with real projects. The Polymer team closely collaborates with web standards bodies, contributors to various frameworks and the Blink team. The following diagram describes the architecture of Polymer: platform.js : The red parts are shims [2] for upcoming APIs. These shims will be used by most frameworks in the future and eventually be replaced by native APIs. p...

Web Components [1] are an upcoming standard for custom HTML5 user interface elements. Those UI elements will eventually become interchangeable between frameworks. Now the people behind AngularJS and Ember.js have described their plans for supporting Web Components. Below, you’ll see mentions of Google’s new framework, Polymer [1] . It is built directly on top of Web Components. One of Polymer’s goals is to help refine and fully figure out that standard. AngularJS In an entry on Google Groups, AngularJS co-creator Miško Hevery writes: We're in early stages of designing Angular 2.0, but some of our goals are: Angular will use the underlying web platform features available to it (e.g. Node.bind, template integration, Custom Elements, etc...) Web Components (Polymer, Ember, or any other framework/library) will work seamlessly within Angular apps and directives. Components written in Angular will export to Web Components (to be used by Polymer, Ember, or any other framework/library). ...

Updates: [2013-07-16] Hello Polymer: Q&A with Google’s Polymer team [more information on Polymer] [2013-05-23] Plans for supporting Web Components in AngularJS and Ember.js At Google I/O 2013, Google presented a new web user interface (UI) framework called Polymer . The way it works is indicative of the future of all web UI frameworks. Polymer Polymer is composed of the following layers: Foundation (platform.js): Foundational building blocks. Most, if not all, of these APIs will eventually become native browser APIs. Core (polymer.js): Helpers complementing Foundation. Elements: UI and non-UI components built on Core. The Foundation layer (platform.js) The Foundation layer comprises the following technologies: DOM Mutation Oberservers and Object.observe() (probably ECMAScript 7): for observing changes to DOM elements and plain JavaScript objects. Pointer Events : handle mouse and touch in the same manner, on all platforms. ...

When it comes to platforms for implementing applications, the term “web platform” seems to increasingly replace “HTML5” (which itself has largely replaced “Ajax” [1] ). In this context, both terms denote the programming platform of web browsers. The former includes JavaScript. The latter doesn’t, strictly speaking, but it includes JavaScript-based APIs. Why “web platform” is a good choice This is a positive development, for three reasons. First, “web platform” better describes the actual platform: the “HTML” in “HTML5” suggests “everything in web browsers except JavaScript”, but JavaScript is an integral part of the platform. Second, including a version number unncessarily constrains the lifetime of “HTML5”. Third, people know what the web is and we already talk about “web apps”. So, saying that web apps are based on the web platform is fitting. Accordingly, when the web community got together to better document web development, the name “web platform” was chosen for what was to be doc...

Twitter’s “Follow” button has an HTML5 context menu [1] . The button below allows you to try it out. On Firefox, you get a context menu whose top three items are “Follow”, “@rauschma on Twitter” and “Tweet to @rauschma”. Alas, other browsers don’t support the customization of context menus, yet. Follow @rauschma jQuery contextMenu is a polyfill [2] that works on all browsers and uses HTML5 on Firefox. There are plans to parse HTML5, but they are waiting for a second HTML5 implementation before they do that. References: HTML5 context menus in Firefox 8+ What is the difference between a shim and a polyfill?

Functionn is a blog on open source web development. Today, they published an interview with me and several other people (including DailyJS’s Alex R. Young) covering various web-development-related topics. They asked the following questions: Tell us a little bit about yourself. How has 2012 been to you? What have you been working on lately? Now that 2012 is over, what do you think were some of the most exciting developments in the world of web development this year? What web development tool/library/framework/mindset shift has impressed you most in 2012? (You can talk about as many as you wish here). Which single tool/library/framework/mindset shift would you recommend other developers to use/put to work? What most excites, scares and disappoints you about the web today? One word to describe the web as it is today? How do you see the web change in 2013 and beyond? What do you look forward to in 2013? If you had the superpower to change something in the world, what would you change? :-...

Recently, high-resolution screens (Apple calls them Retina displays) have become popular – first on cell phones, then on tablets and now on laptops. I have been waiting for those for literally decades: all other computer components (memory, processor speed, etc.) improved predictably, but screen resolutions did not get much better over the years. The problem for web developers is that things look nicely on these displays if resolution-independent mechanism are used: fonts, vector graphics, CSS effects, etc. However, with bitmap graphics, you are forced to deliver images with many more pixels. That has the potential of greatly slowing things down on the web if you are using a Retina device. Daan Jobsis has found an interesting solution: Use a high-resolution JPEG image, but but with an extreme compression rate (e.g. 75%): [...] this image was razor sharp. The difference is even noticable on the iPad 1, 2 and normal computer screens. How bizarre, the filesize is smaller than the orig...

Ian Hickson, editor of the HTML spec, has proposed a way to let web workers use Canvas. In the browser, all “normal” work happens in a single thread. That means that the user interface and computing tasks are competing for processor time. Thus, if you don’t want to block the user interface, you perform computationally intensive tasks in a background thread, via web workers (see section below ). Creating bitmap graphics is a common activity on the web and a candidate for being done in the background. The easiest solution would be to make Canvas (HTML element and bitmap API), available to workers. But that is not possible, because they don’t have access to the DOM and Canvas cannot exist independently of it. Quoting Ian Hickson : I was faced with two options: Option A: Provide an API for off-screen graphics in workers, requiring that every frame you package the whole thing up, send it over to the main thread, and blt it there. Option B: Provide a mechanism by which a worker ...