"HTML5" entries

Signals from Velocity New York 2014

From the lure of work that matters to building your own device lab, here are key talks from Velocity New York 2014.

Practitioners and experts from the web operations and performance worlds came together in New York City this week for Velocity New York 2014. Below you’ll find a handful of keynotes and interviews from the event that we found particularly notable.


Mikey Dickerson: From Google to HealthCare.gov to the U.S. Digital Service

“These problems are fixable, these problems are important, but they require you to choose to work on them” — Mikey Dickerson looks back on what it took to fix HealthCare.gov and he reveals his reasons for joining the U.S. Digital Service.

Read more…

Comment

Why polyfills matter

The changing landscape of web platform extensibility

From its nascent days, the growth of the web has been marked by the waxing and waning of technologies, frameworks and ideas. Old ideas and technologies expire and fade away, and new ones arise in their place. Much as the cicada molts and leaves behind an old shell as it moves into adulthood, the web has seen countless ideas come and go as it has evolved.

Relics (and Catalysts) of the Web

Remember XHTML? More specifically, do you remember caring deeply about XHTML? You likely do. Do you still care about XHTML? Chances are, the answer is no. The same goes for Flash, DHTML, HTML Components and countless other buzzwords of the web that once felt so alive and important, and now feel like relics of another time.

Occasionally, however, we collectively stumble upon ideas and technologies that stand the test of time. These are ideas that don’t just evolve with the web–they are often a catalyst for the evolution of the web itself. Ideas like Cascading Style Sheets and XMLHTTPRequest, the vendor hack that spurred the AJAX revolution, are two examples among many.

Read more…

Comment

Building rich web UIs with knockout.js

Live coding a shopping cart and other rich web UI goodness

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Microsoft’s Steve Sanderson gave a tight 20 minute introductory tour of Knockout.js, a popular JavaScript UI library built around declarative bindings and the Model-View ViewModel (MVVM) pattern.

In his talk, Rich Web UIs with Knockout.js, Steve quickly summarized the problems Knockout solves and why Knockout is a particularly strong candidate to solve those problems, before working on a shopping cart example to show off how bindings, including custom bindings, work within Knockout.

Some key parts of Todd’s talk include:

  • A description of the problem Knockout solves [at 00:41]
  • What is Knockout and MVVM? [at 01:38]
  • 4 unique things about Knockout [at 03:12]
  • Live coding a shopping cart [at 06:02]
  • Summary [at 20:15]

Anyone with a further interest in Knockout should check out the project’s homepage and particularly the live Hello World example and interactive online tutorial which guides you through building a Web UI using the MVVM pattern with Knockout.js in an interactive sandbox-style environment.

If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.

Comment

MathML forges on

The standard for mathematical content in publishing work flows, technical writing, and math software

20 years into the web, math and science are still second class citizens on the web. While MathML is part of HTML 5, its adoption has seen ups and downs but if you look closely you can see there is more light than shadow and a great opportunity to revolutionize educational, scientific and technical communication.

Printer in 1568-ce

Somebody once compared the first 20 years of the web to the first 100 years of the printing press. It has become my favorite perspective when thinking about web standards, the web platform and in particular browser development. 100 years after Gutenberg the novel had yet to be invented, typesetting quality was crude at best and the main products were illegally copied pamphlets. Still, the printing press had revolutionized communication and enabled social change on a massive scale.

DE-Zeitungsrollenoffsetdruck by Steschke

In the near future, all our current web technology will look like Gutenberg’s original press sitting next to an offset digital printing machine.

With faster and faster release cycles it is sometimes hard to keep in mind what is important in the long run—enabling and revolutionizing human communication.

Since I joined the MathJax team in 2012, I have gained many new perspectives on MathML, the web standard for display of mathematical content, and its role in making scientific content a first class citizen on the web. But it is rather useless to talk about MathML’s potential without knowing about the state of MathML on the web. So let’s tackle that in this post.

Read more…

Comment: 1

HTML5 is the Future of Book Authorship

The key advantages of the HTML5 platform for authors and publishers

In the past six years, the rise of the ebook has ushered in three successive revolutions that have roiled and reshaped the traditional publishing industry.

Revolution #1 began in November in 2007, when Amazon released its first-generation eInk Kindle. As the first ereader to achieve broad adoption by consumers, the Kindle fundamentally changed our answer to the question, “How do you read a book?” On paper? Sure. But also maybe on a handheld screen!

Revolution #2 began in January of 2010, when Apple released its first-generation iPad. As the first tablet computer to achieve a critical mass of popularity, the iPad fundamentally changed our conceptions about what those handheld ereader screens could and should do, and as a result, it raised a deeper metaphysical question: “What is a book?” An immutable stream of text and pictures? Sure. But also maybe audio, video, and elements like 3-D models, games, and quizzes that respond and adapt to human interaction!

Read more…

Comments: 34

Can Markup Unite?

Getting past the HTML / XML splits

A few years ago, I stopped talking about XML and starting talking about markup. After a few too many conversations with developers who had found XHTML, web services, and various other things that had proudly branded themselves with the “X,” it was clear from hostile responses that XML’s boom was done.

Many of Wednesday’s Balisage talks wrestled with the challenges XML tools face in a world dominated by competitors, especially HTML5. Today opened with a talk on making XForms work in HTML5 with browsers, followed immediately by a talk on replacing DocBook XML with XHTML5 (at O’Reilly). Two more abstract talks looked at filtering and an info space model, but the afternoon asked “Where did all the document kids go?” and then sought world domination by making XML invisible.

Line at Balisage

Read more…

Comment

Toward Responsive Web Programming

Creating flexible expectations

“Expect the unexpected” has long been a maxim of web development. New browsers and devices arrive, technologies change, and things break. The lore of web development isn’t just the technology: it addresses the many challenges of dealing with customers who want to lock everything down.

Matt Griffin (and a lot of others) reminded me of these difficulties at Artifact, and his Client Relationships and the Multi-Device Web brings it home for designers.

Is there room for programmers to tell a similar story?

I don’t mean agile. Agile development is difficult enough to explain to clients, but applications that adapt to their circumstances are a separate set of complications. Iterating on adaptable behaviors may be more difficult than iterating on adaptable designs, but it opens new possibilities both for applications and for the evolution of the Web.

Responsive Web Design is (slowly) becoming the new baseline, giving designers a set of tools for building pages that (usually) provide the same functionality while adapting to different circumstances. Programmers sometimes provide different functionality to different users, but it’s more often about cases where users have different privileges than about different devices and contexts.

Adjusting how content displays is complex enough, but modifying application behavior to respond to different circumstances is more unusual. The goal of most web development has been to provide a single experience across a variety of devices, filling in gaps whenever possible to support uniformity. The history of “this page best viewed on my preferred browser” is mostly ugly. Polyfills, which I think have a bright future, emerged to create uniformity where browsers didn’t.

Browsers, though, now provide a huge shared context. Variations exist, of course, and cause headaches, but many HTML5 APIs and CSS3 features can work nicely as supplements to a broader site. Yes, you could build a web app around WebRTC and Media Capture and Streams, and it would only run on Firefox and Chrome right now. But you could also use WebRTC to help users talk about content that’s visible across browsers, and only the users on Firefox and Chrome would have the extra video option. The Web Audio API is also a good candidate for this, as might be some graphics features.

This is harder, of course, with things like WebSockets that provide basic functionality. For those cases, polyfills seem like a better option. Something that seems as complicated and foundational as IndexedDB could be made optional, though, by switching whether data is stored locally or remotely (or both).

HTML5 and CSS3 have re-awakened Web development. I’m hoping that we can develop new practices that let us take advantage of these tools without having to wait for them to work everywhere. In the long run, I hope that will create a more active testing and development process to give browser vendors feedback earlier—but getting there will require changing the expectations of our users and customers as well.

Comment: 1

The Appeal of the Lift Web Framework

The extreme end of weird (as far as web frameworks go)

Lift is one of the better-known web frameworks for Scala. Version 2.5 has just been released, so it seems like a good time to show features of Lift that I particularly like.

Lift is different from other web frameworks (in fact, I labeled it at the extreme end of weird in the first presentation I gave about it), but people who get into Lift seem to love the approach it takes. It’s productive and enjoyable, which goes well with Scala.

I’ll keep this post short. Just two things:

Transforms

You might be familiar with an MVC approach to the Web, where you have code that forwards to a view, and in that view you maybe use a little bit of mark-up to loop or display values. That’s not how it goes in Lift.

Instead, you start with the view first, and use HTML5 attributes to mark the parts of the view that need transforming. Here’s an example:

That’s valid HTML5. You can view it in your browser, or edit it in Adobe Fireworks, or whatever tool you want. The only part of it that looks a little strange is the data-lift attribute. What that’s doing is naming a Lift snippet, and a snippet is just a class. It might look like this:

What’s going on here? We’re using a nifty DSL in Lift to transform the <p> tag so that it contains the content we want. We’re saying…

Read more…

Comments: 3

Driving the Momentum of Modern Web App Development

Ido Green on modern web app design considerations and characteristics of great web apps

The rapid pace of improvements in browser technologies and the growith of HTML5 have presented many opportunities and challenges for web app developers. In the following interview, Ido Green, developer advocate for Google Chrome OS, reviews some characteristics of the “modern” web app and covers a few design points and helpful tools developers should keep in mind. Green will expand on these ideas in an upcoming free webcast, “Modern Web Applications Utilizing HTML5 APIs,” on Thursday, May 30 at 10 a.m. PT.

What is a “modern” web app?

ido_green

Ido Green

Ido Green: A “modern” web app is an application that utilizes HTML5 APIs and browser technologies to let the users accomplish a certain goal.

In most of the “great” web applications we see several characteristics:

  • They are self contained (maybe from here we got the term “one page application”) with one main goal.
  • They feel “native”: they are leveraging HTML5 APIs that let the app have “native” capabilities, like Offline, Geo, drag and drop, transitions, etc.
  • They are “offline first,” since we wish our users to be productive when there is no connection or when there is a flaky connection. These apps are built from the ground up with the idea of “offline.” It’s similar to a native app that you will “install” first and later fetch the data.
  • They are device aware: the apps are working great on mobile devices as well as on laptops and desktops.
  • They offer great performance: the great modern apps are utilizing CSS3, HTML5 and the mobile browsers to give the users a smooth experience where everything is working fast. The “offline first” methodology is helping here as well.

Read more…

Comment: 1

JavaScript: Not as Expected

A good match for the similarly unexpected Web?

JavaScript’s ever-growing importance still takes people by surprise. Every time I post about things JavaScript makes possible, I get pushback from people who refuse to be impressed by JavaScript. Why? Because it isn’t what they wanted.

In the course of a week, I get to hear from different quarters about how JavaScript is half Lisp, and terrible either because it dares to be half-Lisp or because it only manages to be half Lisp. Similarly, as functional programming has become more visible, I’ve heard more from people who think JavaScript programming is too functional or not functional enough. People disappointed in JavaScript because it doesn’t have strong typing are a constant, as are people who find prototypal inheritance perverse. JavaScript syntax—I’m sure someone must like it.

It’s tempting to tell the story of JavaScript as a series of historical accidents. Brendan Eich put together LiveScript, applying a variety of techniques to meet a particular set of needs quickly. Since then, we’ve been dealing with JavaScript’s shift from a simple object manipulation language to a much broader and more powerful toolkit, unable to change approach because of the unique dynamics of the browser world.

Read more…

Comment: 1