Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

October 10 2013

W3C-Direktor Berners-Lee verteidigt Kopierschutz für Webstandard HTML5

Soll HTML als Standard des offenen Web Kopierschutz unterstützen? Schon seit einiger Zeit wird darüber nicht nur in den Kreisen des Web-Gremiums W3C erbittert diskutiert. Genau genommen geht es um „Encrypted Media Extensions” – Schnittstellen, über die kopiergeschützte Inhalte auch direkt im Browser abspielbar werden sollen. Netflix, Microsoft und Google haben dazu einen Entwurf vorgelegt.

Nun hat sich Web-Erfinder und W3C-Direktor Tim Berners-Lee erneut zu Wort gemeldet und das Vorhaben gegen Kritik („Hollyweb”) verteidigt. Nach den Designprinzipien von HTML hätten die Nutzer zwar Vorrang – es sei aber besser, wenn die Diskussion über DRM im W3C statt außerhalb stattfinde. Denn verhindern werde man Kopierschutz für Video-Inhalte mit einer Verweigerung nicht, so Berners-Lee. Man könne aber die Folgen für’s offene Web mildern:

if content protection of some kind has to be used for videos, it is better for it to be discussed in the open at W3C, better for everyone to use an interoperable open standard as much as possible, and better for it to be framed in a browser which can be open source, and available on a general purpose computer rather than a special purpose box.

Die Kritik war Anfang Oktober wieder lauter geworden, als das W3C in einer neuen Charta schließlich festschrieb, dass HTML-Unterstützung für geschützte Inhalte zu seinem Aufgabenfeld gehört. Die Electronic Frontier Foundation sprach von einem „gefährlichen Schritt” und einer Machtverschiebung vom Nutzer zum Inhalteanbieter:

We’re deeply disappointed. (…) That breaks a—perhaps until now unspoken—assurance about who has the final say in your Web experience, and indeed who has ultimate control over your computing device.

Deutlich wird allerdings, dass die Entscheidung auch für Berners-Lee nicht nur eine über die Rolle des W3C ist, sondern strategisch begründet wird: Ohne Beteiligung des W3C würde der Kampf um Kopierschutz von vornherein auf fremdem Terrain stattfinden, entsprechend schlechter wären die Ausgangsbedingungen.

Im gleichen Posting ruft Berners-Lee nun zu mehr Beteiligung am Prozess auf. Doch im Gegenzug muss sich die HTML5-Arbeitsgruppe jetzt an der Quadratur des Kreises versuchen: Offen und geschlossen, WWW und DRM soll sie in Einklang bringen.

August 19 2013

pdf2htmlEX by coolwanglu

pdf2htmlEX by coolwanglu

pdf2htmlEX renders PDF files in HTML, utilizing modern Web technologies, aims to provide an accuracy rendering, while keeping optimized for Web display.

pdf2htmlEX is best for text-based PDF files, for example scientific papers with complicated formulas and figures. Text, fonts and formats are natively perserved in HTML such that you can still search and copy.

#web #logiciel #pdf #html #datas #logiciel_libre #0pen_Source

Sponsored post

August 15 2013

Four short links: 16 August 2013

  1. fraktransforms collections of strings into regular expressions for matching those strings. The primary goal of this library is to generate regular expressions from a known set of inputs which avoid backtracking as much as possible.
  2. The Boolean Trap — crappy APIs where true/false don’t mean what they seem. None of this is new, but every generation has to learn it anew. (via Pete Warden)
  3. Gumbo — open source pure C HTML5 parser.
  4. All Those People With Cheap Android Phones Have Started Buying Apps (Quartz) — revenue generated by the Google Play Store, from which many Android users get their apps, has grown 67% over the past half-year. By contrast, Apple’s App Store revenue grew 15%, according to Distimo estimates, which cover the top 18 countries. That sounds less impressive if you consider that the App Store brought in twice as much revenue in absolute terms. But the numbers are shifting fast. In February, the App Store was generating three times as much revenue, and last November it out-earned Google Play by a factor of four. Google is gaining.

July 12 2013

DevDocs ❝Provides access to the following API documentations : HTML, CSS, DOM, DOM Events,…


Provides access to the following API documentations: HTML, CSS, DOM, DOM Events, JavaScript and jQuery. The material comes from the usual places (Mozilla Developer Network et al.), but has been consistently and pleasantly styled and provides a slick search user interface. Upcoming feature: offline capability.

#HTML #CSS #DOM #JavaScript #jQuery #documentation

April 22 2013

Four short links: 22 April 2013

  1. Meshlabopen source, portable, and extensible system for the processing and editing of unstructured 3D triangular meshes.
  2. HTML5 Video on iOS (Steve Souders) — While it’s true that Mobile Safari on iOS doesn’t buffer any video data as a result of the PRELOAD attribute, it does make other video requests that aren’t counted as “buffered” video. The number and size of the requests and responses depends on the video. For larger videos the total amount of data for these behind-the-scenes requests can be significant.
  3. Space Monkey (Kickstarter) — distributed encrypted peer-to-peer cloud service using custom hardware. Not open source, which would make me nervous that I was buying a botnet client with storage capability. (via BERG London)
  4. Matasano Crypto ChallengesCounting is not a hard problem. But cryptography is. There are just a few things you can screw up to get the size of a buffer wrong. There are tens, probably hundreds, of obscure little things you can do to take a cryptosystem that should be secure even against an adversary with more CPU cores than there are atoms in the solar system, and make it solveable with a Perl script and 15 seconds. Don’t take our word for it: do the challenges and you’ll see. People “know” this already, but they don’t really know it in their gut, and we think the reason for that is that very few people actually know how to implement the best-known attacks. So, mail us, and we’ll give you a tour of them.

April 18 2013

Four short links: 18 April 2013

  1. The Well Deserved Fortune of Satoshi NakamotoI can’t assure with 100% certainty that the all the black dots are owned by Satoshi, but almost all are owned by a single entity, and that entity began mining right from block 1, and with the same performance as the genesis block. It can be identified by constant slope segments that occasionally restart. Also this entity is the only entity that has shown complete trust in Bitcoin, since it hasn’t spend any coins (as last as the eye can see). I estimate at eyesight that Satoshi fortune is around 1M Bitcoins, or 100M USD at current exchange rate. Author’s credible. (via Hacker News)
  2. Houdini (Github) — C library for escaping and unescaping UTF-8-encoded HTML, according to OWASP guidelines.
  3. The $12 Gongkai Phone (Bunnie Huang) — gongkai isn’t a totally lawless free-for-all. It’s a network of ideas, spread peer-to-peer, with certain rules to enforce sharing and to prevent leeching. It’s very different from Western IP concepts, but I’m trying to have an open mind about it.
  4. Jan Chipchase on Google Glass (All Things D) — Any idiot can collect data. The real issue is how to collect data in such a way that meets both moral and legal obligations and still delivers some form of value. An interesting observation, one of many within this overview of the usability and third-party user experience of Google Glass-like UIs.

March 22 2013

Four short links: 22 March 2013

  1. Defend the Open Web: Keep DRM Out of W3C Standards (EFF) — W3C is there to create comprehensible, publicly-implementable standards that will guarantee interoperability, not to facilitate an explosion of new mutually-incompatible software and of sites and services that can only be accessed by particular devices or applications. See also Ian Hickson on the subject. (via BoingBoing)
  2. Inside the South Korean Cyber Attack (Ars Technica) — about thirty minutes after the broadcasters’ networks went down, the network of Korea Gas Corporation also suffered a roughly two-hour outage, as all 10 of its routed networks apparently went offline. Three of Shinhan Bank’s networks dropped offline as well [...] Given the relative simplicity of the code (despite its Roman military references), the malware could have been written by anyone.
  3. BotNet Racking Up Ad Impressionsobserved the Chameleon botnet targeting a cluster of at least 202 websites. 14 billion ad impressions are served across these 202 websites per month. The botnet accounts for at least 9 billion of these ad impressions. At least 7 million distinct ad-exchange cookies are associated with the botnet per month. Advertisers are currently paying $0.69 CPM on average to serve display ad impressions to the botnet.
  4. Legal Manual for Cyberwar (Washington Post) — the main reason I care so much about security is that the US is in the middle of a CyberCommie scare. Politicians and bureaucrats so fear red teams under the bed that they’re clamouring for legal and contra methods to retaliate, and then blindly use those methods on domestic disobedience and even good citizenship. The parallels with the 50s and McCarthy are becoming painfully clear: we’re in for another witch-hunting time when we ruin good people (and bad) because a new type of inter-state hostility has created paranoia and distrust of the unknown. “Are you now, or have you ever been, a member of the nmap team?”

March 13 2013

Four short links: 13 March 2013

  1. What Tim Berners-Lee Doesn’t Know About HTML DRM (Guardian) — Cory Doctorow lays it out straight. HTML DRM is a bad idea, no two ways. The future of the Web is the future of the world, because everything we do today involves the net and everything we’ll do tomorrow will require it. Now it proposes to sell out that trust, on the grounds that Big Content will lock up its “content” in Flash if it doesn’t get a veto over Web-innovation. [...] The W3C has a duty to send the DRM-peddlers packing, just as the US courts did in the case of digital TV.
  2. Visualizing the Topical Structure of the Medical Sciences: A Self-Organizing Map Approach (PLOSone) — a high-resolution visualization of the medical knowledge domain using the self-organizing map (SOM) method, based on a corpus of over two million publications.
  3. What Teens Get About The Internet That Parents Don’t (The Atlantic) — the Internet has been a lifeline for self-directed learning and connection to peers. In our research, we found that parents more often than not have a negative view of the role of the Internet in learning, but young people almost always have a positive one. (via Clive Thompson)
  4. Portable C64 — beautiful piece of C64 hardware hacking to embed a screen and battery in it. (via Hackaday)

November 30 2012

Emerging languages spotlight: Elm

Over the next few months I’ll be taking a look at new and emerging programming languages. The following piece is the first in this series.

The Elm Programming Language, created by Evan Czaplicki, tackles web interaction and takes on the big three — HTML, CSS, and JavaScript. I recently had the pleasure of sitting down with Czaplicki to talk about why he decided to take on this daunting project and how Elm could revolutionize web programming.

Czaplicki was working on a front-end web project and he was thinking about how is it that web development can be “so frustrating in a way it didn’t have to be.” That was the day Elm was born (he talks about that moment in this segment of our video interview).

Today’s websites bear virtually no resemblance to those from 10 years ago, so why are we using the same tools? Cyclical upgrades to HTML, CSS and JavaScript have certainly enhanced and improved upon older versions. HTML5 has taken some great leaps forward. But we’re still using the core.

Coming from a functional programming background led Czaplicki to think about web programming from the perspective of functional reactive programming. What is functional reactive programming? It takes away the idea that interaction between a website and user is static — updating only at certain moments or clicks — and inserts the capability to update as events happen, like mouse movements. Czaplicki gives more detailed insight here.

Ok, let’s say we buy into this … it seems like a new way of thinking about web programming that will take projects to a new level. But why would you actually change from tried and true HTML, CSS and JavaScript? Czaplicki makes a few good arguments worth mulling over as you think about what language you should use on your next project, starting with the foundational idea that all of the established web languages have “deep semantic problems.” Then he touches on how “surprisingly difficult” CSS and HTML can be to work with for simple tasks, such as vertical centering and text placement. And Czaplicki promises, “Elm allows you to create asynchronous code without callbacks.” That’s something JavaScript does not allow.

Compelling reasons, but will Elm make it to the level of any of these three powerhouse web languages? Czaplicki lays out his roadmap thusly: in the short term he wants to add more features and libraries, then try to garner industry support, and delve deeper into the theory of functional reactive programming as it relates to the implementation of Elm.

I, for one, think it has a chance and that Czaplicki’s paradigm-breaking look at how the web can be programmed helps all web developers.

Our full interview is available in the following video:


May 10 2012

Understanding Mojito

Yahoo's Mojito is a different kind of framework: all JavaScript, but running on both the client and the server. Code can run on the server, or on the client, depending on how the framework is tuned. It shook my web architecture assumptions by moving well beyond the convenience of a single language, taking advantage of that approach to process code where it seems most efficient. Programming this way will make it much easier to bridge the gap between developing code and running it efficiently.

I talked with Yahoo architect fellow and VP Bruno Fernandez-Ruiz (@olympum) about the possibilities Node opened and Mojito exploits.

Highlights from the full video interview include:

  • "The browser loses the chrome." Web applications no longer always look like they've come from the Web. [Discussed at the 02:11 mark]
  • Basic "Hello World" in Mojito. How do you get started? [Discussed at the 05:05 mark]
  • Exposing web services through YQL. Yahoo Query Language lets you work with web services without sweating the details. [Discussed at the 07:56 mark]
  • Manhattan, a closed Platform as a Service. If you want a more complete hosting option for your Mojito applications, take a look. [Discussed at the 10:29 mark]
  • Code should flow among devices. All of these devices speak HTML and JavaScript. Can we help them talk with each other? [Discussed at the 11:50 mark]

You can view the entire conversation in the following video:

Fluent Conference: JavaScript & Beyond — Explore the changing worlds of JavaScript & HTML5 at the O'Reilly Fluent Conference (May 29 - 31 in San Francisco, Calif.).

Save 20% on registration with the code RADAR20


April 24 2012

Four short links: 24 April 2012

  1. 3D-Printing Pharmaceuticals (BoingBoing) -- Prof Cronin added: "3D printers are becoming increasingly common and affordable. It's entirely possible that, in the future, we could see chemical engineering technology which is prohibitively expensive today filter down to laboratories and small commercial enterprises. "Even more importantly, we could use 3D printers to revolutionise access to health care in the developing world, allowing diagnosis and treatment to happen in a much more efficient and economical way than is possible now.
  2. Bolt Action Tactical Pen (Uncrate) -- silliness.
  3. Ken Robinson's Sunday Sermon (Vimeo) -- In our culture, not to know is to be at fault socially… People pretend to know lots of things they don’t know. Because the worst thing to do is appear to be uninformed about something, to not have an opinion… We should know the limits of our knowledge and understand what we don’t know, and be willing to explore things we don’t know without feeling embarrassed of not knowing about them. If you work with someone who hides ignorance or failure, you're working with a timebomb and one of your highest priorities should be to change that mindset or replace the person. (via Maria Popova)
  4. Using Android Camera in HTML Apps (David Calhoun) -- From your browser you can now upload pictures and videos from the camera as well as sounds from the microphone. The returned data should be available to manipulate via the File API (via Josh Clark)

April 02 2012

Books should be as easy to create as websites

This post is part of the TOC podcast series. You can also subscribe to the free TOC podcast through iTunes.

There are countless author and book production platforms to choose from these days. So why would you want to use a new one like PressBooks? In this TOC interview, I sat down with Hugh McGuire (@hughmcguire), co-author of "Book: A Futurist's Manifesto" and founder of PressBooks to help answer that question. I should point out that I'm a fan of the platform. In fact, that's one of the reasons we agreed to have Hugh create and produce "Book: A Futurist's Manifesto" on PressBooks.

Highlights from the full video interview (below) include:

  • Start with a web first approach — HTML is a great starting point and allows you to go in a variety of directions for other formats. It's all about making it as easy to create a book as it is to create a website. [Discussed at the 1:30 mark.]
  • Built on WordPress — PressBooks leverages the CMS power of WordPress and will be familiar to a large audience of writers and editors. [Discussed at 3:18.]
  • Putting book content online — The web offers a great way to spread information, but ebooks are typically off that grid. PressBooks allows you to leverage social interactions for a book. [Discussed at 4:15.]
  • Digital first, POD second — Even though PressBooks is an obvious solution for digital publishing, it's not exclusive to that. In fact, "Book: A Futurist's Manifesto" will also be available via POD when the project is complete. [Discussed at 8:10.]
  • The value of "free" — "Book: A Futurist's Manifesto" is and will remain freely accessible on PressBooks. Will that ultimately cannibalize or help promote sales of the paid versions? [Discussed at 9:00.]

You can view the entire interview in the following video.

The future of publishing has a busy schedule.
Stay up to date with Tools of Change for Publishing events, publications, research and resources. Visit us at


July 13 2011

What is HTML5?

HTML5: Everyone's using it, nobody knows what it is. I realize that sounds more like a line out of an existential movie — maybe Waiting for Godot or a screenplay by Sartre — than a statement about HTML5. But it's really the truth: most of the people using HTML5 are treating it as HTML4+, or even worse, HTML4 (and some stuff they don't use). The result? A real delay in the paradigm shift that HTML5 is almost certain to bring. It's certainly not time to look away, because by the time you look back, you may have missed something really important: a subtle but important transition centered around HTML5.

In this post, I want to take a deeper look at HTML5. I have a simple proposition with a lot of complex consequences: HTML5 is both something entirely new, and yet nothing more than HTML was ever intended to be; and that once you really understand HTML5, you'll change the way you code and even think about the web and your own web applications.

A return to first principles

HTML has always been about interconnection. Back in the ancient days, when electronica was cool and not called "house music" and before the Rolling Stones qualified for Medicare, the web was littered with big huge documents. In fact, it was exactly the opposite of today, where most people think enhanced digital books are just electronic wrappers around full-text copies of what's in print.

In the '90s, the web was full of 15-page specifications, all in a single file. You scrolled through those massive documents just like you paged through an encyclopedia. Much of the early versions of HTML were intended to deal with this, widely considered a detriment to the readability and usability of the web. That's largely because Tim Berners-Lee, the recognized father of HTML, was a researcher enabling other researchers (mostly at CERN at the time). If you've ever known anyone mired in research, brevity is rarely their prevailing trait, so reading huge documents online was a necessity, but scrolling through 15- (or 1,500-) page documents just wasn't a long-term option.

So early on, HTML was not primarily about displaying those documents with lots of formatting. Most fundamental to HTML was the simple a tag. It gave a document the means to link to another document. Suddenly 15-page documents were reduced (mercifully) to 15 one-page documents, all linked together. Bye bye scrolling; hello useful linking. This is all pretty standard fare, and if much of this is new to you, then the waters are going to get deep quickly.

HTML5: Still connecting things

HTML5 logoFast forward to the present. Ultimately, this ability to connect things on the Internet is still the primary feature of HTML5. It's just that now, we're starting to realize the original vision of HTML, and connect a lot more than hypertext with static images. So the introduction of the audio and video elements in HTML5 are nothing more than logical extensions of the old a element.

(Note: in a more correct sense, audio and video replace object and all the embed code that people have been throwing into web pages for years, largely pulled from sites like YouTube or Vimeo. Still, those elements are semantically functioning more like an a element that drops the link into a page, rather than taking you off to another destination. In that sense, even the img element is in some ways nothing more than an inline a element: it grabs content from another location and pulls that content into a page. It's all just linking, and that's what HTML is really about: linking and connecting things.)

So now you can pull in images, audio, and video directly into a document. More importantly, because those items now have first-order elements, you can easily manipulate the audio and video from JavaScript. That's a big deal, and something I'll come back to later. In a nutshell, a first-order element is always going to encourage more direct programmatic access than one in which you have to be sneaky or clever to really get at it.

So while the audio and video elements are new, their purpose isn't. HTML5 allows you to integrate more assets into a single document, all while keeping the integrity and separation of those assets into place. This is nothing more than making sure that the bibliography of a document isn't physically stuck at the end of a long web page, but is in fact separate and easily maintained, but still able to be integrated into the rest of the page.

Now, before moving on, you need to immediately see that it's not (relatively) important that you can grab audio and video and drop it into an HTML page. What is important is that you can more easily grab "other stuff" and drop it into a page. There may eventually be 20 or 25 elements for things well beyond "audio" and "video," and the fundamental premise is still the same: the important thing here is that multiple pieces in multiple places can all be wired together in a meaningful way, with semantic elements describing that "stuff" easily accessible by JavaScript. The fact that, in HTML5, that "other stuff" happens to be audio and video is cool, but rather incidental.

OSCON JavaScript and HTML5 Track — Discover the new power offered by HTML5, and understand JavaScript's imminent colonization of server-side technology.

Save 20% on registration with the code OS11RAD

HTML5 connections are the new rich media

So what, then? Why is this such a big deal? Well, largely for three reasons:

  1. Web pages no longer need to look (and act) like web pages. The rise of Flash over the last years has largely been an attempt to overcome "limitations" of what HTML allows. Flash was initially often focused on animations and cool visual effects. But then entire sites got rolled into Flash, allowing for different types of navigation and page organization, richer programmatic access to the individual pieces of a web page, and the ability to avoid the quirkiness of JavaScript. (I'll leave out the obligatory comment here on the quirkiness of the Flash stack.)
  2. Web pages no longer need to represent one person/organization's content. Even though web programmers and designers have been pulling in images from other sites for years, web pages are still largely homogenous in terms of the asset ownership. A web page today really has one person's content, images, pages, media, and the like. Even sites like Vimeo and YouTube are more often used as extensions of a private repository than an actual free medium for world access.
  3. Web pages can function intelligently and easily across display devices. It's no secret that MOBILE (as one co-worker recently email-shouted at me) is the banner under which HTML5 most often flies. But the story really isn't that HTML5 has great mobile support; rather, it's that mobile is no longer a problem child. In other words, the story is that what works on a desktop browser pretty much works on a phone. (The list of things not covered by "pretty much" is shrinking every few weeks, so better to not list them here and appear outdated next month.) Put another way, phones and tablets are first-class citizens, because they are privy to the same interconnections listed above. In fact, it's probably not too meta-physical to say that in addition to inter-connecting content, HTML5 has a really good shot at interconnecting all the devices floating around ... and that's arguably at least as big a deal as what it does for content and web applications.

HTML5 introduces — although it's not at all complete in its support for — a paradigm that moves away from both of these limitations. First, HTML5 and CSS3 provide for JavaScript a pretty solid working set of tools and effects, comparable to most Flash websites. I can generally take a medium-sized Flash website and recreate it in WordPress, HTML5, JavaScript (via jQuery), and CSS3 in a week, if not less. And the upside is enormous: text is again selectable, bookmarking works without lots of weird tricks, and of course website owners can actually update their own sites, rather than relying on some overly busy Flash programmer to help.

The result is that HTML5 is again the most usable and indexable tool available for web content; but that content is richer than ever before. Further, that content no longer has to be owned to the degree that older web pages had to be owned. For a lot of emotional and psychological reasons, mainly, the audio and video elements suggest pulling assets from other sources more than the more generic object element does. There's something about seeing video that screams, "Grab some video and stick it in your page!" But since there will always be at least an order of magnitude greater number of web page creators than video makers, how do you get that video? You grab it from someone else, hopefully someone who's used a nice Creative Commons license. The same is true for audio, of course: you can connect to someone else's audio incredibly easily, and so you should. And as already intimated, the audio and video that plays on your desktop browser also plays pretty well on an HTML5-enabled phone or tablet.

Underneath these limitation-stripping observations is something much bigger: content creators are moving from creating completely original content to amalgamating and assembling content. Sure, this isn't anything technically new, but it is something that's happening more due to the introduction of HTML5 elements like audio and video. And when the web starts to grow in its interconnectedness, it takes a giant step toward the world of Neal Stephenson and "Snow Crash" and "Neuromancer," doesn't it? One person creates a video and doesn't have to place it or build out a web page. They just throw it on a content-sharing medium like YouTube or Vimeo. Another person goes beyond a simple off-page link but actually integrates that video (fully accessible and mutable via JavaScript, something we'll get to shortly) into a web page. Neither person has to be an expert outside of their own domain (video and web page, respectively), but the result is a fusion of assets.

Now expand the working set of that fusion by a factor of 1,000. Or 1,000,000. Throw in data science and the ability to find, organize, and even localize data like never before. Access that data not just from one browser, but all the major browsers, on all the major devices — laptops, netbooks, tablets, and phones. Toss in unbelievably cheap data storage, and then realize that we've yet to mention the increased power of JavaScript, the canvas tag and its ability to further manipulate the referenced audio and video, and web messaging, and you'll quickly forget that we're talking about HTML here, not a traditional high-end programming language like Java or PHP!

JavaScript isn't the focus of HTML5 … right?

That greater ability of HTML5 pages to do a lot more brings JavaScript into focus. Honestly, there's not much in HTML5 that specifically speaks to JavaScript. Yes, the HTML5 draft, according to the W3C, is intended to replace the JavaScript APIs detailed in older HTML4, XML1, and DOM Level 2 documents. But no, don't expect the JavaScript language to be radically, or even that noticeably, changed in HTML5. Yet hang around the web programming water cooler, and you'll hear more about JavaScript than ever before. So what gives?

Well, first of all, HTML5 adds several important new first-order elements, as already mentioned. audio and video are key, as is another element we'll get to, canvas. That means that it no longer takes a lot of document.getElementsByTagName("object") or ID-tagging of object elements to work with media in a web page. Extending that, these elements (unlike the object element) have media-specific attributes like autoplay and preload. This means that with JavaScript, you can grab a video, display its controls, change the URL and effectively load a new video, and even control when the video loads (or preloads) and mute and unmute the audio.

All of this is done via JavaScript, but there's nothing new in JavaScript enabling this access. It's the addition of semantically meaningful elements in HTML5 that makes JavaScript more powerful, or at the least an easier medium in which to accomplish these tasks. Sure, a clever JavaScript programmer (who was comfortable tokenizing and parsing) could get most of this from grabbing particular attributes from an object element, adjust them, reset them, and so on. But my goodness, it was a mess, it was player-specific, and mostly made for annoying late nights trying to get the semicolon in just the right place.

In fact, much of what's great, albeit seemingly boring, about HTML5 is the move of important elements and attributes from customized or one-off items to semantically important ones. Even the draggable attribute — allowing native drag-and-drop in HTML5 — is cooler because it's now accessible and easily mutated via JavaScript. A page requires less textual data to mean something, and more of that meaning is pushed into the structure of the page itself.

I think it's fair to go as far as being axiomatic here: the more a document has semantic meaning, and the less attributes or even elements are nested as plain text within hidden input elements or object embeds, the better that document will be. The page becomes easier to access, update, and make responsive from a JavaScript point of view; CSS (whether it's CSS2 or CSS3) can be applied directly without so many messy pseudo- and nested selectors; and the document describes itself. And when you have documents that have semantic meaning, you're going to find that your JavaScript is clearer. In fact, many mid-level programmers will realize that they can do things that the "advanced" programmers can: throw a video into the page based on a click, autoplay that video, mute the audio and load a different piece of audio, play that different audio over the video, and boom: you've got an all-HTML5 discussion by Hitler about JJ Abrams and Star Trek ... without having to modify the original audio and video assets.

Put another way, the HTML page becomes more of a container (which contains other containers, which contain other containers ... and so on) than a page. JavaScript can easily access those nested containers, and modify them, update them, move them around, and do anything else you can dream up and code. CSS can also visually style and work with those containers, further making the HTML a purely organizational tool, and even that becomes loose. With absolute positioning, the order and position of elements within the HTML organization becomes at best a guide, if not totally irrelevant.

(It's worth saying a display approach that completely ignores the organization and sequence of elements within an HTML document is a pretty bad idea. What you gain with new semantically valuable elements is quickly lost when you start absolutely positioning everything, and removing any sense of hierarchy. Of course, that's true in HTML4 and XHTML1 as well as HTML5, so it's not something I'll focus on beyond this rather quick note.)

Container-based web pages: A step (sort of) in the right direction

The idea of an HTML page being little more than an organization of malleable elements is nothing new, but HTML5 seems to be a clear jumping-in point for JavaScript programmers and web developers that haven't yet made that conceptual leap. It's notable that with the rise of CMSes like WordPress for smaller businesses and personal websites, almost everyone is now familiar with the separation of concerns involved when even the text of an HTML page isn't necessarily encoded and stored within a static HTML file. This is all a good thing, too. As a JavaScript programmer myself, I'd rather have more programmatic control and create a page that is built based on user decisions, database-driven logic, and programming over one person with an HTML or text editor.

In fact, the most obvious example of this approach is the Twitter website. For example, when I visit Twitter, I see a ton of content:

Twitter screen grab

But if you take a closer look, by viewing the source, you'll find hundreds of lines of JavaScript at the beginning of the file, a ton more JavaScript at the end of the file, and this rather pedestrian bit of HTML squeezed into the middle. Here's about 1/3 of that HTML, which is pretty brief:


<body class="user-style-twttr loading-body ">

<div id="doc">

<div id="top-stuff">

<div id="banners" style="clear:both;"></div>

<div id="top-bar-outer">

<div id="top-bar-bg"></div>

<div id="top-bar">

<div class="top-bar-inside">

<div class="static-links">

<div id="logo">

<a href="/">Twitter</a>


<form id="search-form" action="/search" method="GET">

<span class="glass"><em></em></span>

<input value="" placeholder="Search" name="q" id="search-query" type="text" />


<div id="global-nav">


<li id="global-nav-home"><a href="/">Home</a></li>

<li id="global-nav-profile"><a href="/bdmclaughlin">Profile</a></li>

<li id="global-nav-messages"><a href="/messages">Messages</a></li>

<li id="global-nav-whotofollow"><a href="/#!/who_to_follow">Who To Follow</a></li>



<div id="sections"></div>]]>

Not a lot to it, is there? Of course, even parts of this have been inserted programmatically, like links to my personal profile and messages. And even though this is an HTML4 site, it points to some important things with which HTML5 is attempting to deal.

Now, what I want to argue is that while this is a generally good thing — using JavaScript to connect the organization of HTML to content not encoded directly into that HTML — the step forward of new HTML5 elements is matched, if not overtaken, by some steps back in terms of this sort of programming, at least as it's currently implemented. It's not exaggeration to say that many pages, like Twitter's page, are basically a bunch of empty divs with id attributes and not much else. It's unclear whether Twitter's page will evolve into a more HTML5-centric approach, but unless it also evolves its structure, there are some problems.

Here's the thing: this approach is programmer-rich, yet semantically poor. First, elements aren't truly indicating content; they're just indicating buckets that can be filled. And don't mistake a textual value attached to a div's id attribute as semantic meaning. That's no different than the object element when used to display audio or video; you've got to parse and tokenize to get any real sense of meaning. That's meaning, but it's not meaning encoded into the HTML in a particularly useful way.

This is another area that HTML5 seeks to improve. For many, the introduction of another few elements — nav and header and footer, for example — have been largely ignored. Why not just keep using <div id="nav">? Well, now the answer should be obvious: these new elements provide additional semantic meaning. If I'm linking to your page, or even pulling in part of your page, in my own page, I can grab (or not grab) your footer, your navigation, your figures and figure captions.

Don't let the SGML-ness of semantic meaning escape you. (Yes, I realize that SGML-ness isn't a word, but it should be.) When you really begin to connect heterogeneous parts of the web together, semantic meaning becomes huge. So does a page that is more than a bunch of divs with id attributes. You'll want to know what you're getting, and an HTML standard is a heck of a lot better way to determine meaning than arbitrary text values tucked away into id attributes.

By now, you're either seeing a theme in what I'm calling out about HTML5, or you're seeing little more than a grab bag of loosely connected features. If you're in the latter camp, let me make it explicit: HTML5, when used both as the 21st century web suggests and as the original HTML specification allowed, is best at interconnecting things. If you view your pages as a collection of content, and let go of the rather egotistical idea that all that content has to be your own, then all of the new features of HTML5 discussed so far are hugely important. You can pull in audio and video and manipulate that audio and video as if it were your own. You can organize your page semantically and link to and even pull in content from other sites, using the semantics of that page. You can separate content from organization using more than just divs, but actual first-order elements for navigation and headers and footers.

And then, when things were going so well, there was canvas.

The canvas element is a programmable div

It's odd that the element that is probably at the top of the HTML5 spec in terms of "wow factor" is in fact the element that brings in the ability to undo most of the good I think HTML5 does. That element, of course, is canvas. canvas defines, well, a canvas on the HTML page. Using JavaScript, you can draw on that canvas using methods that look a lot like a graphics scripting language. JavaScript basically grabs the canvas by its id attribute, using document.getElementById(), and then gets a context. Most of the examples online that are really jaw-dropping use the 3D canvas, but there's a 2D canvas that's a lot better entry-point if you're new to this sort of thing.

Once you've got a context, you can operate upon that object, using properties like fillStyle, and methods like fillRect(top, left, width, height);, and canvas. Yes, it's really that simple, and even pretty intuitive. In fact, more than anything else, drawing on a canvas for the first time with JavaScript felt a lot like my old Logo days in grade school, or even Java AWT days in early Java. (Oddly, I'm prouder of what I did in Logo than AWT; don't judge.)

I don't think it's worth a lot of ink to walk you through using canvases. There are tons of web tutorials out there in both 2D and 3D, and a slew of good video and publications. Suffice it to say that the days of needing Flash to really do anything visually interesting, or at least needing to take that visually-interesting thing you created and turn it into an image or a video, are gone. What's even cooler is that you again get JavaScript integration into your page. So now a keypress or a form submission, or dragging an element on the page, or the playing of a video (because we have draggable and video now, remember?) can interact with the canvases on your page.

Now, there are two caveats: one small one and one giant one. The small one is that browsers are still getting their HTML5 act together, and the 3D context in particular is pushing browsers beyond what they were often intended to do. So realize that while you're not going to get the dreaded "Flash content won't play" sort of message on your iPhone, there is going to be a lot of rigorous testing required to get your 3D drawing just right on the most computers in the most browsers. But, honestly, that's a testing issue, and one that both time (as people upgrade) and testing can overcome.

The more serious issue is that the canvas becomes much like an anonymous, programmatically-filled div. The things within it have no semantic meaning and existing apart from the HTML's encoding on disk; it's a dynamic set of programmatically-created lines and squares and spheres. No matter how cool of a texture you wrap around a 3D model, you can't go in with a separate JavaScript function (or better, a separate HTML page) and grab that textured sphere, link to it, spin it around its axis, or adjust the light source. You can do all of those things from the page itself, mind you; you just can't do it in the loosely-interconnected manner that is heralding the new and cool web that HTML5 helps drive.

So is this a stump speech against canvas? Of course not. I'd no more avoid canvas than I'd tell someone in HTML4 to avoid div. Yes, there is a limit to semantic meaning. Yes, the canvas becomes a big blob that contains something, but that something has minimal outside visibility. But it's still a step forward, and heralds what is hopefully a wealth of GPU studs and studettes making HTML5 do far more than anyone thought possible. (Studettes: another made up word, but these are good words. Webster, anyone? Urban Dictionary?)

Hopefully, there will soon be standardized ways to call into objects that are created within a canvas, and granularity becomes part of the advantages of a canvas rather than a drawback. Until then, you've got to decide if using a canvas makes sense. In general, if you're doing something page-specific, or if your canvas is itself a self-contained "mini-application," then go forth and prosper. If your canvas is tightly integrated into the rest of your page, you're probably in great shape, too. But if you want a lot of other pages and sites to pick up your canvas as any sort of component, you're probably out of luck, and might want to look at a different approach.

The good/bad news here is of course, that HTML allows for this sort of reuse, and people are starting to figure that out, but people are just starting to figure this out. Interconnections again; are you building your own little kingdom in the web, complete with moat and drawbridge to keep everyone else out? Or are you integrating everything you do into a larger-than-you Internet that shares (and sometimes steals) as much as it creates, and in that sharing and stealing recreates?

Mobile: Killer application, ho-hum client

For those of you already read up on HTML5, you may be surprised how little the word "mobile" has shown up. Sure, I mentioned earlier that mobile devices can view HTML5 web pages, and consume audio and video from audio and video without many problems. But isn't this the big story with HTML5? In fact, isn't it mobile devices, more than anything else, that are driving HTML5 adoption?

Well, yes and no.

As far as mobile devices driving adoption, absolutely: HTML5 owes a lot of its buzz to mobile devices, and in particular Steve Jobs and his near-militant campaign against Flash. The iPhone came with Safari, Safari had HTML5 support, so suddenly iPhone users were giddy and talkative. Now almost all modern smartphones have an HTML5-capable browser. So while the ability to view video without Flash is big, the yet-bigger story is simply that anything that works on an HTML5 website as viewed within a desktop browser pretty much works on a phone. So yes, HTML5 wouldn't be the talk of the developer town if not for mobile.

But no, mobile can't be the big story with HTML5. (People will claim it is, and do so all the time, but they're misguided in that they're calling an effect a cause.) HTML5 doesn't offer all sorts of bells and whistles for working with mobile devices. Yes, there are ways to detect the orientation and screen size of a mobile device; but those also allow for detection of the size of a browser window, or a tablet display. And yes, certainly, the canvas element and new audio and video features make it possible to deliver amazing content to a mobile device. And yes, yet again, more and more folks are building mobile-optimized websites for phones. So how is this not a big deal?

Well, what's important is not that HTML5 works on phones. What's important is that HTML5 "just works." There aren't tons of issues when getting your site to work on a phone ... and that's the story. The big deal isn't that you can do all kinds of cool things with your website for mobile phones. The big deal is that you can do all kinds of cool things, period; and that those cool things just happen to work on mobile phones ... and tablets ... and netbooks ... and desktop clients. HTML5 really removes the need to think about mobile devices separately from other devices.

(Note: I'm not saying you should ignore mobile devices, or not think about them separately. The best sites I use on my phone are almost all at least mobile-optimized, if not complete with a pure-mobile theme or CSS styling. That said, you don't have to do this to get up and running. Also, almost all good mobile-themed sites have a "View normal site" that works perfectly well. That says a lot. It used to be you'd want to hide the normal site at almost all costs. Not with HTML5...)

... and a partridge and a pear tree

As this article turns the bend from readable to monolithic, at least in article terms, it's easy to look at what else HTML5 offers, and consider writing an entire book. There's web messaging, and offline applications, and local storage ... really, everything you need to write an entire application. And ultimately, that's the brief but accurate assessment I'd make of the "everything else" of HTML5. HTML5 is no longer about a single page, or even a collection of inter-linked pages. It's about interconnection — and I've tried to beat that drum consistently above all else — but that interconnectedness is about a lot more than pages. It's certainly about a lot more than just your pages.

Web messaging allows interconnecting HTML5 applications (I'll defend the use of "application" here in a moment; for now, just go with me). Those applications don't have to be in the same domain; for the first time, there's an intelligent JavaScript-based messaging framework that allows for communication across domains. You can write listeners to receive messages and senders to send them. In its simplest form, all the limitations of Ajax sandboxing that everyone griped about have been removed, albeit with some security considerations and a lot more complex API than the pretty simple XmlHttpRequest object. But all the same, if you buy into the premise that HTML5 encourages sharing of resources across the web, then messaging makes that sharing more of a true two-way communication. Now you can build resources that can be consumed, even if that consumption involves receiving data as well as sending it.

And you've got local storage, too: a legitimate database-like storage mechanism for holding onto data and delivering it to a server on the Internet when that server is available — even if that's not the "now" of the page's existence and use by a real person. These tie in closely with forms, the most obvious means of getting this sort of data that local storage is optimized to store. In fact, while it's nice that HTML5 forms offer some new controls and validation and the like, it's their ability to interact intelligently with offline storage (via, again, JavaScript) that's the really big story. Think about that: for the first time in, well, ever, there's valuable offline access that can take place. Again, there are kinks (and some of them are big) and some new wrinkles to take into your JavaScript, but the web has always had kinks and wrinkles. It's just that now you're getting more than ever for dealing with those issues.

Add to that even heavier-duty types of functionality, like threads (which are called web workers, but really are just threads) and sockets. On the one hand, these aren't part of the core HTML5 spec. Instead, they've been moved into WHATWG, so that says something about their ultimate inclusion and importance as part of HTML5 to the W3C community. On the other hand, by untying these from the core spec, they may now be free to evolve further and more quickly than ever before. In any case, it's no small thing to be talking about threads and sockets not as part of code that generates or produces HTML, but as part of an HTML application itself. These are serious tools, and further indicate that HTML5 is not to be taken as a language for building interesting and largely static web pages anymore.

So about this word application: isn't that what's ultimately being created with HTML5? This isn't just about neat visuals and clever drag-and-drop controls and even replacing Flash-based sites. HTML5 pushes a good programmer to create semantically-meaningful and accessible resources. Those resources don't have to be entire pages. They can just be "things:" video and audio and navigation and footers. Those "things" can not only be used across domains by other "things," but there's actually communication that can happen. You can pull in a very well-designed footer by sending it a few choice bits of information, and have that footer pulled from one domain interact with a video pulled from another domain. When the user is offline, big deal. Local storage not only allows for database-like storage of an HTML page without an installed database, but is even kind enough to make sure that data gets to the right place where connectivity is restored. JavaScript is not a toy language anymore, and jQuery makes what was annoying in JavaScript lexically a piece of cake.

These are applications.

Stop building web pages. Please. Stop trying to only use "your" content. Slap a Creative Commons license not just on your video, or your images, but on your HTML, and then build interesting components and assume they'll be sucked into other things and used in ways you'd never considered. It is called the Internet, remember?

The winners in an HTML5 world are those who stop fearing being stolen from, and actually start handing out their candy to every kid on the block. It's about a lot more than YouTube-like sharing of videos. Applications are increasingly becoming a collection of mini-applications, and if you're thinking about your HTML5 work as collecting resources — some original, some shared — then you're way ahead of the curve.

OSCON 2011, coming up later this month, will have a track dedicated to JavaScript and HTML5. Learn more and save 20% on registration with the codeOS11RAD.


June 03 2011

Checking in on HTML5 video

Though HTML5 video can't fully challenge Flash video's dominance just yet, Greg Schechter, web warrior at YouTube and a speaker at Velocity 2011, says HTML5 is headed in a good direction.

In the following interview, Schechter talks about HTML5 video's architectural issues, how mobile provides a great platform but is something of a crap shoot when it comes to bugs, and how at this point video speed is a toss-up between HTML5 and Flash.

What kinds of architectural issues emerge as you incorporate HTML5 video distribution?

GregSchechter.jpgGreg Schechter: The biggest architectural issue we've had to deal with is providing support for the new WebM encoding format. For Flash we only need to have one encoding, H.264 (at least for the most part). For HTML5 we need to support both H.264 and WebM to support all modern browsers. We've had to make changes to streaming and upload architecture to support the different situations the video might be played in. We haven't converted all our videos to WebM yet, but we are actively working on it.

How do you address HTML5 video across platforms, devices and browsers?

Greg Schechter: For the desktop, the issues are not that bad. Once you make sure you have encoding that the browser can support, the video tag works without too many differences. At the moment, the critical features are supported by all the HTML5 video-capable browsers. We're starting to see feature support diverge, with things like a full-screen API and support for the track tag, which will make it a bit more difficult to handle in the changing development environment.

Mobile sometimes feels like a crap shoot. Sometimes we run into problems caused by hardware constraints, such as a device not being able to capture frames of a video to show in a paused state outside of the native player. Other times, it's bugs with the layout engine that don't render as expected. Every now and then we run into a crazy bug that affects phones but not tablets, or it affects tablets but not phones. Fortunately, these bugs don't happen all that often, but they can certainly cause some bad headaches.

Velocity 2011, being held June 14-16 in Santa Clara, Calif., offers the skills and tools you need to master web performance and operations.

Save 20% on registration with the code VEL11RAD

How has HTML5 affected mobile video distribution?

Greg Schechter: Mobile support is one of the best benefits to HTML5 video. Our two biggest markets for mobile video are iOS and Android. iOS doesn't support Flash, and many users haven't installed it on Android. Thus, with HTML5 we're able to easily provide both these platforms with a video viewing experience.

Your Velocity presentation is titled "HTML5, Flash and the Battle for Faster Cat Videos." Is there a clear winner yet?

Greg Schechter: There are a lot of different elements to measure to compare the performance between the two players. Because HTML5 doesn't require a plug-in, it will start up faster. This is great for our embeds because the time until the user sees the video thumbnail is a lot faster. Unfortunately, we haven't seen the same results in how long it takes to play the video — Flash is a lot faster. Some of this has to do with our architecture, but we've also seen inefficiencies in the browsers, which we are hoping will be fixed soon.

A video embedded with YouTube's old embed code

A video embedded with YouTube's HTML5-friendly iframe code

Are you surprised at the adoption pattern for HTML5 video?

Greg Schechter: We're still experimenting with our HTML5 player. It's mostly an opt-in program, so the numbers are pretty low for now. But I have been surprised with people looking for HTML5 support for our embedded player. People have been really excited and eager to use our JavaScript API with our iframe embed on mobile devices, where HTML5 is key. Our Flash player has been doing an excellent job at video distribution for years. Both YouTube and the browser vendors have some work to do in order to get the HTML5 player up to snuff, but once we're there, I'm confident we'll have a great user experience to compete with Flash.

This interview was edited and condensed.


May 30 2011

Four short links: 30 May 2011

  1. Chartify -- jQuery plugin to create Google charts from HTML tables. (via Rasmus Sellberg)
  2. Designing Incentives for Crowdsourcing Workers (Crowdflower) -- In a tough turn for the sociologists and psychologists, none of the purely social/psychological treatments had any significant effects at all.
  3. The gTLD Boondoggle -- ICANN promised back in 1998 that they would bring the world lots of new domains. So far they haven't, the world has not come to an end, and the Internet has not collapsed. The absence of demand for new TLDs from actual users (as opposed to domain promoters and the occasional astroturf) is deafening. What we do see is a lot of concern that there will be more mistakes like .XXX, and pressure from governments both via the GAC and directly to ensure it doesn't happen again. It's a bugger when you go hunting for a new product's domain name and realize "all the good ones are taken", but that's an argument against domain squatters/speculators not an argument for opening up new top-level-domain vistas.
  4. Atul Gawande's Medical School Commencement Address (New Yorker) -- every lesson in here about healthcare is just as applicable to software development. Read it. (via Courtney Johnston)

October 27 2010

Four short links: 27 October 2010

  1. Bleach -- HTML sanitizer, which some might say is an impossible task.
  2. TAT Home -- a gesture-powered 3d home screen for Android.
  3. Omaha -- the autoupdater used in Chrome and other Google projects, open sourced.
  4. Google Refine -- Freebase GridWorks has new home and new name, with new checkins happening all the time. An excellent ETL tool for figuring out what data you have and getting it into the right format.

April 09 2010

April 08 2010

Four short links: 8 April 2010

  1. BLINK Tag Security Advisory -- sounds April 1sty, but WebKit had an executable code vulnerability related to use of the BLINK tag. (via followr on Twitter)
  2. Gerrit -- a web based code review system, facilitating online code reviews for projects using the Git version control system. (via mattb on Delicious)
  3. Open Source Business Models (PDF) -- presentation by Matt Aslett of The 451 Group, giving a framework for understanding how license, community, development model, and business model interact. Was a talk at OSBC. (via Stephen Wall)
  4. Graphical Perception: Learn the Fundamentals First (Flowing Data) -- a list of visual cues ordered by how well people perceive them, and examples of how they're used in visualizations. Visualization isn't just art, there's science behind it and just as great artists know the science behind their medium, great data artists understand the cognitive science behind their techniques.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...