Additional Resources 3 Easy Ways to Learn More and Stay Current Programming Blog Read more news and analysis about JavaScript, HTML5, CSS3, and other web platform technologies. programming.oreilly.com Programming Get programming-related news and Newsletter content delivered weekly to your inbox. oreilly.com/code/newsletter.html Fluent Conference Immerse yourself in learning at the annual O’Reilly Fluent Conference. Join developers, UX/UI designers, project teams, and a wide range of other people who work with web platform technologies to share experiences and expertise— and to learn what you need to know to stay competitive. fluentconf.com ©2014 O’Reilly Media, Inc. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. 14114 The Web Platform Building a Solid Stack of HTML, CSS, and JavaScript Simon St.Laurent The Web Platform by Simon St.Laurent Copyright © 2014 O’Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or [email protected]. Editor: Simon St.Laurent January 2014: First Edition Revision History for the First Edition: 2014-01-10: First release Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. The Web Platform: Building a Solid Stack of HTML, CSS, and JavaScript and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their prod‐ ucts are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. ISBN: 978-1-491-95011-1 [LSI] Table of Contents Preface. v HTML: Moving Beyond the Standard. 1 The Power of Markup. 5 CSS Selectors Have Superpowers. 9 JavaScript: Not as Expected. 13 From JavaScript to Declarative Markup. 17 Toward Responsive Web Programming. 19 Will JavaScript Take Over the Programming World?. 21 Concentration: The Wrong Story 21 Dispersion: A More Likely Story? 24 iii Preface The Web keeps growing, expanding from a content distribution sys‐ tem to an application platform connecting people within organiza‐ tions and across the world. For the past 15 years, the Web’s core has proven remarkably stable. Even as developers create more technolo‐ gies and techniques, they still mostly use the core stack of HTML plus CSS and JavaScript, with a few extensions mostly provided through additional standards. Can that stack persist? Programmers have longed for alternatives for at least as long as the Web has existed, largely because web develop‐ ment doesn’t quite feel like programming. Creating documents, styling them, and then adding some program logic is pretty different from standard models of creating objects and logic to display something on a screen. The Web endures, though, largely because of its unique approach. Markup and simple hypertext offered a quick way to build and share documents across a network, but we have layered much more on top of those capabilities. Beyond simplicity—which isn’t especially prev‐ alent today—why do web tools work so well? • Both HTML markup and CSS stylesheets are declarative, making browsers do work without requiring programming logic. • JavaScript layers well on top of HTML, especially after it learned the power of declarative selectors from CSS. • Separating content, presentation, and logic has made reuse much simpler. v • The ubiquity of the Web combined with the competitive nature of browser vendors encourages major investment in rendering engines and JavaScript performance. • Even though web browsers are written by many different people with different motives, they’ve been able to work well enough to‐ gether to extend browser capabilities. The best part, though, is that those foundations let us do new things. I hope you’ll find that web technologies continue to provide a solid base on which to build your dream projects! These pieces were originally written for the O’Reil‐ ly Programming blog and then adjusted to better fit the times and the format. If you’d like to see more on similar topics, please explore http:// programming.oreilly.com. vi | Preface HTML: Moving Beyond the Standard You can create your own markup vocabularies without learning XML. You just need to figure out what markup you want to use, and then create CSS and JavaScript to tell the browser what to do with it. Cre‐ ating your own extensions to the HTML vocabulary lets you describe your content in the terms that make sense to you and can help you drastically reduce repetition and confusion. When HTML first appeared, it offered a coherent if limited vocabulary for sharing content on the newly created World Wide Web. Today, now that HTML has handed off most of its actual work to other specifica‐ tions, developers can start to choose their own markup vocabularies and processing. When the W3C first formed, it formed around HTML, the core stan‐ dard of content on the Web, defining the structure, appearance, and behavior of content. Over the next few years, however, it became clear that HTML was doing too much, and the W3C and other groups re‐ factored appearance, behavior, and many semantics into separate specifications: • Cascading Style Sheets (CSS) took responsibility for presentation and layout. • JavaScript took responsibility for behavior, aided by the Docu‐ ment Object Model (DOM) and a variety of APIs for handling device and multimedia interactions. 1 • WAI-ARIA took responsibility for accessibility semantics, ensur‐ ing that content remained available to a broad audience even if developers pushed the current boundaries of markup. It’s not a completely neat separation—some of CSS feels like behavior, and JavaScript can manipulate presentation, for example, but they certainly took some work off the shoulders of HTML. A few aspects of HTML, notably media inclusion, are still mostly handled at the markup level, but most of them aren’t any longer. Forms and linking are both still defined in HTML itself, but they aren’t difficult to im‐ plement separately. When the WHATWG formed, its focus on web application develop‐ ment led it to build a variety of JavaScript tools, which still dominate the HTML5 work. In many ways, HTML5 has been about adding a few pieces of markup functionality to HTML itself and a tremendous pile of JavaScript APIs to browsers in general. Browsers still need to do a lot of work to achieve the visions developers have for a unified distributed application platform, but HTML itself carries less and less of that burden. The former flagship spec may be what comes to mind first when people say “web development,” but the reality is that it has been hollowed out. The heavy lifting happens in the other specifications. This means that we can free markup semantics from the demands originally placed on HTML. Markup doesn’t become total anarchy: defined markup syntax, both XML’s stricter version and HTML5’s more forgiving version, is still useful to create a parse tree browsers can decorate with CSS and WAI-ARIA and then manipulate with JavaScript. HTML itself is still useful—many people and tools know how to read and write it—but there is less and less reason to let the HTML vo‐ cabulary be a cage limiting our possibilities. Polyfills emerged as tools for bringing older browsers up to date with the latest specifications. Best practices for using them are still emerging, but they’ve become a more common implementation in frameworks like AngularJS, mak‐ ing it easy for developers to create markup templates that JavaScript will later manipulate. (The Web Components spec simplifies this work and provides structure that works across browsers reliably.) A stronger case for polyfills, though it was actually meant to argue for adding an element to the standard, comes from the picture element 2 | HTML: Moving Beyond the Standard saga. The Responsive Images Community Group developed a speci‐ fication and implemented it (twice) with polyfills. Those developers weren’t happy when the W3C and WHATWG didn’t seem interested (conversations continue), but from my perspective, they’d already done great work in creating the polyfills. (Loading media has more complicated optimization issues than just about anything else brows‐ ers do with HTML.) Shifting the focus away from markup standards is difficult. The Web Standards Project spent a decade or so (and I participated) evangeliz‐ ing the need for web standards and disbanded recently in the face of success. The message that web tools need to be designed by a central organization is, for better or worse, deeply ingrained, but it’s time for markup to fall out of that story.1 HTML’s legacy vocabulary is a great foundation on which developers can build their own toolsets. The Web will benefit, however, from let‐ ting developers solve their information problems in their own ways, rather than trying to stuff too many things into a single vocabulary. Even if centralized markup standards have benefits, let’s evolve them rather than design them. So where should you start? The Polymer framework is a good place to experiment, and there’s been a lot of useful conversation at the Exten‐ sible Web Community Group.