"HTML5" entries

Learning the Web

Finding a gentle entry to a big space

html5_fundamentals

The Web welcomes, but it’s awfully big. While HTML, CSS, and JavaScript may all be appropriate entry points for newcomers who want to create, finding a solid starting point can be complicated. Social media has minimized the level of HTML and Web knowledge people need to start contributing, but when it’s time to make the jump, the Web offers perhaps too many options.

Part of the challenge is that HTML, CSS, and JavaScript may be the marquee technologies, but they’re not actually what hosts a website or app. Setting up a site requires an additional set of technologies, from domain names to hosting to web server choices. Setting up a site – long before you get to packaging an app! – requires mastering an additional technical toolset and vocabulary that will help you navigate where you need to put your projects. Our free report, Getting Started with the Web, provides the core foundations beginners need.

Those aren’t the only barriers, though. Read more…

Power of the platforms

Uncertainty is a feature, not a bug.

Image: CC BY 2.0 NASA's Earth Observatory via Wikimedia Commons  http://commons.wikimedia.org/wiki/File:Southern_Lights.jpg#mediaviewer/File:Southern_Lights.jpg

After decades of work on programming, we finally got a development environment with massive reach and tremendous power. Somehow, though, the web isn’t centered on a comprehensive programming environment. The web succeeded with a (severely) lowest-common denominator, specification-driven approach that let it grow with time, technology, and multiple communities, across multiple platforms.

Almost two decades ago, I was all excited about Java. Write applets once, run anywhere, with libraries to make sure it all came out the same wherever anywhere might be. Java is still a powerhouse, but it all worked out differently than I expected. Even in Java’s early years, before the Java news was filled with security bulletins, applets felt like a strange mix with their surrounding web pages. Creating an applet demanded programmers to build every detail. Even with Java’s ever-improving libraries, creating a Java applet that did much was an intense experience focused on programming.

Java wasn’t the only comprehensive way to build web apps, of course. Flash demanded programming, but its values always incorporated design, action, and well, flash, in ways that meshed well with the way people built sites. Flash kept growing and growing before its ecosystem took a fatal hit from the iPhone as HTML5 offered replacements for some of its key strengths. I mostly notice Flash these days because it asks me to update it regularly and because pages tell me when it’s crashed.

Compared to either of those rich environments, web technology is a tangled mess. The early web was functional but unstyled, with no behavior beyond navigating among pages. That? That would dominate client-side computing? Read more…

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…

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…

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.

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…

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…

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…

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.

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:

<p data-lift="Poems">
  The work of <span class="author">someone</span> includes
  <span class="title">something</span>.
</p>

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:

package code.snippet

import net.liftweb.util.Helpers._

class Poems {
  def render =
    ".author *" #> "Philip Larkin" &
    ".title *" #> "This Be The Verse"
}

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…