Adobe, standards, and HTML5

"The noisiest of those competitive battles [between suppliers] will be about standards. The eyes of most sane people tend to glaze over at the very mention of technical standards. But in the computer industry, new standards can be the source of enormous wealth, or the death of corporate empires. With so much at stake, standards arouse violent passions."

—The Economist, February 23, 1993

When this paragraph about standardization was written, the major conflicts in computing were whether Unix was a viable operating systems (and a challenge to the more proprietary operating systems of IBM, DEC, and HP), and which windowing platform (SUN/AT&T or IBM/DEC/HP) would be the "standard." The Internet existed, but the World Wide Web didn't. Browsers weren't even on the horizon.

We now know that the industry that the author looked at in 1993 and the "violent passions" he described were, in comparison to the last five years, a gentler and kinder (and possibly even idyllic) time.

However, the point that the author was making was that standards, despite being mundane and boring, are the glue that holds the information and communications technology (ICT) industry together. The key to standards is interoperability and user utility—their primary function now is to make complex, heterogeneous systems possible and responsive to user needs. The standardization arena is more complex now than it has ever been, and this is in large part due to the ubiquity of the World Wide Web, which has increased both the technical complexity of the market as well as user needs and expectations.

The World Wide Web is fundamentally based on two standards—HTML and HTTP. HTML is a recommendation of the World Wide Web Consortium (W3C), and HTTP is produced by the Internet Engineering Task Force (IETF).

Of these two standards, HTML is more in the news because of its pre-eminent place in the creation of web content. It is the specification that defines the basic markup language of the Web. Using HTML, interoperation between heterogeneous systems, vendors, and products can occur. HTML4, the predecessor to HTML5, followed HTML3.2 very quickly, and remained the dominant form of HTML from about 2000 onward. It was during this time frame (2000 onward) that the phenomenal commercial growth of the web occurred.

However, as with all things in the ICT industry, change happened. Users began to expect more sophisticated capabilities, and various tools were created to respond to user expectations and requirements. As an example, in the area of animation various alternatives were proposed and by 2005, the Macromedia Flash platform became a defacto standard for interactivity users expected and producers provided (for ads, branded sites, pulldown menus, and so on).

As part of the constant change in the market, there was a drive by several browser makers to revitalize and recast HTML—it had been nearly five years since the last version of HTML had been issued, and the entire market had changed. New products included open source browsers and mobile browsers with multiple platforms and screen sizes; electronic publishing and electronic media became increasingly important, and the need for visual enhancements became pronounced.

In response to this need, several of the browser makers began an effort to create a newer version of HTML, called HTML5. The effort was initiated outside of the W3C, but eventually moved into the W3C for more formal standardization and protection of intellectual property. (The W3C has an enforced requirement that all intellectual property contained in the W3C Recommendations be royalty free. By bringing the specification back into the W3C, the creators and their sponsoring companies ensured that all of them—and all others who contributed—would not be able to later claim royalties or create an IP-walled garden). This effort has resulted in the creation of the latest revision of the HTML specification (HTML5). Because the web is a critical platform to our customers, Adobe committed both technical resources and Intellectual property to the W3C standardization of HTML5.

However, because Adobe is a tool maker, not a browser maker, we've had to adopt a different approach to HTML5—as have all tool makers. Browsers consume HTML5—that is, a web browser reads an HTML5 document and then composes the document into a visible or audible display. Adobe's primary focus is to check HTML5 for being "tool ready." It is important for tool makers, like Adobe, that the specification is clear and unambiguous so that all the various implementations will be compatible, reducing the need to create HTML5 content that has specific compensations for differences in browser rendering.

As a tool maker, Adobe focuses on the person who is composing the HTML page and the needs that this person has as they create content, or on the process (server, tool) that is generating the HTML page. And the customer and user feedback that we are receiving indicates that users are realizing that the industry is in a major transition period as the "new web" is being created. Old knowledge is being reexamined and new ideas are being tested. Users producing publishing-quality output on the web and who are used to pixel-specific design have to think about things differently. Now they have to create adaptable and scalable content. And so they ask themselves (and Adobe): how do you control the experience without controlling the pixels? We are not hearing a lot of feedback that, for example, the model is wrong. We are hearing from people trying to get the new tools to do what they need for creative expression.

Ideally, a tool makes the job of creation easier; part of the challenge that Adobe faces is understanding what users want for tools in this evolving market. They all agree that they want the best tools for new and evolving content creation. Users want tools that let them focus on achieving their goals in a faster, easier, better, or less expensive manner (or preferably, all of the aforementioned). As a tool maker, Adobe has to look beyond the basic support of the W3C specification. As an example, performance (as both performance of tools and quality of output content) is a key consideration for many users. If performance profiles vary a lot between devices and browsers, that can be as big a barrier as lack of functional interoperation. Performance is a particularly important issue as mobile access becomes more prevalent.

The community of those creating web content has grown to be very diverse and the new standards need to support that diversity well and in depth. Doing that allows Adobe's customers to have the consistency and interoperability required to produce the high quality and highly functional websites they desire. The consistent communication provided by standards is vital, and most noticeable by its lack. Everyone remembers (or should remember) the Netscape-Microsoft browser wars of the mid-1990s. This was an instance where browser makers deliberately added features that did not operate on competitors browsers. This era came to an end amid general user and creator rebellion. So, the first requirement that Adobe users wanted was consistent HTML5 rendering among those ubiquitous browsers; a "write once, run well everywhere" model.

To achieve this, however, Adobe waited for the specification to stabilize, before modifying and specializing our web products to take advantage of the new features. We also are using our extensive tool-making experience across different platforms (PDF, Flash, HTML, multimedia) in making tools for HTML5. At the same time, Adobe's users tend to be heavy content producers who don't really care about technology specifications—they want Adobe to worry about the specifications and then make the best tools for them to use to express their ideas and their creativity. The question from them is, "How do we use the capabilities available through the evolving standards to express what we want, and how do we integrate into our workflows?" And, "How quickly can you provide the tools?"

User needs and requirements are increasingly complex, especially with all things moving to digital (such as video, magazines, and television). In addition the diversity of interactive devices has ballooned over what it had been during the desktop and laptop era. Screen sizes and visibility of text as well as interactive mechanisms now vary from device to device in ways that dictate what form the applications and content must take. Recently Adobe has had some interesting discussions and feedback from magazine publishers wanting to replicate their high quality print publications on tablets and other devices. This diversity requires adaptable content layout and interactive models as the same material is delivered to different devices. Categories of devices with similar form factors have emerged. At the present time, Adobe is starting to see layout patterns can work for the different categories. There are "break points" as creators move from one category to the next, for example, from a small handheld form factor to a tablet form factor to a desktop. There are also different interaction models for these devices. Users like the idea of device-independent authoring, but also want to optimize for the strengths of each device.

At the same time, users note that the richness of print to which users are accustomed is not there yet using HTML5. HTML5/CSS layout standards are not as comprehensive as those with which they are familiar in the print environment. To respond to user needs in this area (and to help the industry create richer displays), Adobe recently proposed a CSS3 regions module to the W3C CSS Working Group. Also, because of the diversity of Adobe's customer base, mobile authoring is critical to nearly all of them these days. This has become a significant outlet for them and it's growing at a tremendous rate (with smartphones and tablets). For example, Adobe's tool set is used by publishers to build magazines (using InDesign), and we will give them a way to export content using standards and to display it on mobile devices. It's all part of creating tools that answer the needs of our users—but tools that are based on stable standards.

Adobe users are also concerned about the large number of specifications that keep appearing. Again, some of them are just not that relevant to some customers. That influences what we support and what we don't support. As tool makers, we need to meet demands for useful and applicable tools. We need to understand user requirements, and then need to figure out how and when to combine specifications to make them more powerful. When working with CSS regions Adobe realized that you could use it to do interesting layouts, but even more interesting things when combined with JavaScript.

Adobe has also begun contributing to the WebKit effort. As noted above, the HTML5 specifications are of less interest to our users than to be able to implement and run code built on HTML5. As a result, we're using WebKit in our tools and contributing our bug fixes back to the WebKit engine. Again, the intent is to make HTML5 tools useful to our users in many ways. As an example of our efforts, in a mid-August summary of WebKit submissions, Adobe's Alexandru Chiculita was recognized for "... adding a new performance test for float element lookup which landed an optimization which yields a performance improvement of about 150% for looking up a floated element." Again, the intent is to make HTML5 tools useful to our users in many ways.

Similarly, with the support of SVG in all major browsers, we've noticed that our users are now asking Adobe to refresh the support for creating SVG in Adobe Illustrator that has existed for years. They also want more support for SVG in all of our products. Additionally, Wallaby, a tool from Adobe Labs, can export HTML from Flash and leverages SVG as well.

Vector graphics is an important part of building a high-fidelity web platform and is part of Adobe's goal to enable high-fidelity rendering on the web: layout control, rich animations, and high-quality typography are all part of what closing the gap is about. It is desirable for HTML5to go from "80% there" to "the only platform you need" for creating rich applications and content for the web. . As part of this drive there is a need to create animations using HTML and CSS, we're working on tools that take HTML5 features supported in browsers but for which tools are lacking. We know we can provide great tools—look at Adobe Edge to see a recent example from Adobe.

At the same time, we've also developed The Expressive Web as a resource for HTML5 and CSS developers. Because not all browsers are adopting all the features of HTML5 in lockstep, we've found that showing what works where and with what (and what to do when it doesn't) helps developers actually begin to become more familiar with HTML5 and its capabilities and the weaknesses that it will have until the major browsers agree on a majority of the feature set they want to use. To aid users, Adobe has the Adobe BrowserLab tool, which allows users test web content across different browsers and configurations. We render your content and send you back image to show what works and what doesn't.

There is still a gap both on desktop and mobile with respect to what you can do in the browser. We don't yet have the same richness of integration or access to device capabilities, but that gap is closing: new features are added to browsers and performance of JavaScript engines has improved a lot. The trajectory is positive and the gap will close, but we're not there yet.

We have a long history with our traditional software products, but we are driving hard to evolve our products to integrate more with the connected world of today. We've provided some pilot efforts to judge customer feedback, for instance, in Photoshop Express to allow management of images via a browser and on a mobile device. You can expect us to do more in that area.

Adobe's intent has always been to enable users to maximize the value and ubiquity of their information and content. We have always built tools that make access to content easier, faster, more expressive, and more valuable. Because minor technology changes have great impacts on development tools and the designers and developers that rely on them, Adobe has elected to proceed more slowly than those providing the experimental renderers. Our customers need to move beyond experimentation and expect to do so with Adobe tools. Because we are representing our users through our tools, we have a unique perspective to the entire picture of HTML5 that differs from many others in this arena. And it is with that different, tool-based perspective that we are now focusing on a more mature and stable HTML5 Recommendation from the W3C.