Chapter 12
THE FUTURE OF CSS AND THE WEB

Throughout this book, you've been shown advanced concepts, up to the cutting edge of CSS development. You are now well equipped with tools that you'll be using for years to come. But what will you build? How can you keep innovating? What other sources might you look toward to find inspiration? In this chapter, we invite you to imagine the future with us. From here on out, the Web is going to be whatever you make it.

There is a remarkable amount of room in which to grow and develop new techniques and technologies today and in the years to come. Remember that, in historical terms, the Web is an exceptionally young medium. As of this writing, if you consider that Tim Berners-Lee launched the World Wide Web by publishing his summary of the fundamental technologies to the alt.hypertext newsgroup on August 6, 1991, the Web is just over 17 years old. Television by comparison has been around for 80 years; the telephone for over 130 years; the telegraph, since the early 1800s; and the printing press emerged around the year 1450.

Considering these media, the Web is still in its infancy. Imagine where we'll be ten years from now, or even in a hundred years. In this chapter, as a way to tie up some of the ideas we have learned in this book, we will briefly explore some of the things that you might come to expect from CSS and the web development platform in the future, and we ask you, the reader, to consider some of the questions posed here and to think about where all this might be going next.

The bright future of the Web

Even as you read this book, the CSS specifications are evolving. Whether or not you realize it, everyone who works with these technologies plays a role in the development of the Web. Regardless of whether you are writing specifications, implementing technologies in a browser, or using emerging CSS techniques in your own web designs—as you should now be now well equipped to do after studying the subjects within this book—you are blazing trails for things that will be used decades from now.

If you wish to make history, then make history by doing: push that envelope. We encourage you to see what is possible, or at least what you can get away with during your daily grind. As you work, look for opportunities to sprinkle CSS enhancements for modern browsers in your projects in spite of a lack of support from older browsers (opacity, text-shadow, box-shadow, and any of the standard properties implemented only as with vendor-specific prefixes are great examples); this is how you push the Web forward.

Expanding CSS in print

Although CSS currently predominates on computer screens of various shapes and sizes, print is still the most widely deployed medium for human communication. Despite the predominance of gadgetry that replaces print—such as the Amazon Kindle, smartphones with screens large enough to keep you from going blind, and of course the “good old-fashioned computer screen”—print will be around for some time to come. Print has some advantages compared to electronic media: it doesn't require electricity, it is comfortable to read, and it can be constructed with physical dimensions such as die cutting, natural handmade paper, pop-ups, and other specialized ornamentation that transcend the two-dimensional world of the computer screen. And in most cases, a nice, hardbound printed book makes a much more meaningful gift than the intangible e-book equivalent.

Therefore, the biggest potential area where CSS usage will expand is very likely in the area of print, especially as CSS3 begins to solve many of the shortcomings earlier CSS specifications had with regard to flexibly addressing printable portions of paper that we discussed back in Chapter 4. It's also possible that support for CSS in areas such as Braille and aural content will see improvements in future applications, as CSS already contains a growing wealth of possibilities for those media types.

As you know, the possibility of easily repurposing a single body of content for multiple formats is an extremely attractive proposition both for content producers and publishers alike. For instance, say a symphony orchestra produced some promotional material and wanted to target it to four different page layout scenarios: one for a CD booklet, one for a concert program, one for a promotional page on their website, and one as a section for a printed annual yearbook containing a compilation of works. With the right content in the right markup (either HTML or some form of XML), this is an achievable task with today's CSS implementations, and yet only one of the four options mentioned involves a computer display as final distribution medium.

To do something like that today, you might spend a great deal of time developing a style sheet by using the typical code-load-refresh methodology inside a web browser. However, we believe that as the usefulness of CSS makes itself evident on the Web, we'll see more applications that treat CSS for printed and other media as first-class citizens. One such notable product today is PrinceXML, a CSS-capable XML and HTML to PDF transformer.¹ With good parsing clients for print like this appearing and support for the improvements in CSS3 for print media, CSS becomes a powerful print publishing platform.

There's also no technical reason why end users should need to learn how to write a markup language or CSS themselves. Even today, desktop and online word processors alike such as Microsoft Word and Google Docs are capable of producing files that combine some form of XML with an embedded style sheet for presentation. These are essentially crude graphical user interfaces for working with CSS in a particular context—text. Since we have CSS, we're simply missing a similar graphical user interface that generates CSS for its aural or other contexts.

XSL Formatting Objects (XSL-FO) is a markup language used most often for creating print document formats. Might CSS replace current use of XSL-FO someday? We know CSS is great for print and CSS3 makes things that much better, so what can CSS do in place of XSL-FO for the publishing community, and would that be easier or better? XSL-FO is an intermediary step between an XML document and ultimately what is likely a print format such as PDF. If CSS were refined enough to the point that we could achieve parity in print output between CSS and XSL-FO, then really XSL-FO becomes an unnecessary step.

How much of this print-on-demand stuff can we democratize? CSS is much more widely known by developers than XSL-FO and sites like Lulu (http://www.lulu.com/) let authors self-publish books. Can we envision a situation in which these authors also provide Lulu with a CSS file to style their book, rather than using PDFs? Would this be a benefit to web designers, Lulu, consumers, some of these, or all three, and why?

Audible CSS

Yet another idea would be reformulating a blog into a podcast simply by using a speech media style sheet. With today's publishing platforms improving their support to output semantically rich pages and with voice synthesis technologies improving, it may not be quite so far a leap to imagine a system that can take this output and automatically speak it. In such a system, a CSS file might be used to describe the ways that different parts of the text would be verbalized.

On the same note, imagine a system that can also work in the reverse way; taking an audio recording or audio input and automatically transcribing it to a file that contains semantically rich markup. Although it's not quite this sophisticated yet, Google's new “Google Voice” can automatically transcribe aural messages to real text and can even email you the result. Could CSS be used more than to give those transcriptions a bit of typographic style, perhaps doing so much for author customizations as describing what “air quotes” sound like when particular individuals pause dramatically enough when they use them in speech? Sure, this seems far-out today, and perhaps it won't ultimately be possible for CSS to provide such a capability, but the influence of what CSS has accomplished is already visible in numerous other systems and technologies related to semantic encoding.²

Ultimately, CSS is computer code for style. So what can be styled via a computer? Ask yourself this question and you will likely find opportunities for future directions in CSS.

HTML5 and CSS

The last published recommendations for HTML were under the 4.01 version, adopted as of December 24, 1999. Subsequent markup efforts were then focused on the XML variants of HTML, such as XHTML1, XHTML1.1, and current work going on for XHTML2.

Recently, a new effort originally started under a group called the Web Hypertext Application Technology Working Group (WHATWG) decided to work on an upgrade to the HTML specification under the guises that the XML parsing requirements of XHTML were too strict and poorly enforced, and that the beauty of the success of the Web was the ease of use and forgivingness of good old HTML. Why not improve on those aspects of it? From that effort, what is now HTML5 was born.

HTML5 comes in two flavors, one of the plain-old HTML variety, and one that is an XHTML-like version that borrows XHTML's self-closing tag syntax. The XHTML-compatible version aims to maintain markup's ability to be extended, which the HTML version also benefits from. Developing a version of HTML5 that uses XML syntax in parallel with the more forgiving traditional HTML parsing rules continues to steer the future of markup toward well-formed, semantic structures. HTML5 has strong backing from developers and technology vendors alike. Despite early fireworks, it has become a W3C project and can already be used and validated against from the W3C's markup validation service.

The new elements in HTML5 include the following (as of this writing):

• Structural, block-level elements: <section>, <header>, <footer>, <nav>, and <article>
• Block-level semantic elements: <aside>, <figure>, and <dialog>
• Inline semantic elements: <mark>, <time>, <meter>, and <progress>
• Multimedia elements: <audio> and <video>
• Interactive elements: <details>, <datagrid>, <menu>, <command>

In addition to the new elements, new rules will apply. For instance, in HTML5 you can wrap an <a> element around an <h1> and additional elements after that. Here's a block of markup that will be a single link, with a little CSS to illustrate the point:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
    <title>A Hover of Many</title>
    <style type="text/css" media="screen">
      a[href="/2009/seattle/"]:hover {
        color:red;
      }
    </style>
  </head>
  <body>
    <a href="/2009/seattle/">
      <h1>Welcome to Viola World</h1>
      <img src="violaplayer.jpg"
 alt="A viola player trying to count to four." />
       <p>Where all your viola needs are met!</p>
     </a>
   </body>
 </html>
 </a>

Yes, Virginia, this is legal markup in HTML5, and why not? We would like to link a bunch of elements in an <a> element. It will save developers time, and more easily generalizes what an HTML “anchor” was intended to be in the first place. The anchor-wrapping example will also affect CSS: you'll have the ability to select new descendants of <a> elements, including the <h1> and <p> elements. For those of us who have been coding HTML for a long time and were taught that inline elements such as the <a> were never allowed to have block-level elements within, this might seem unnatural at first. But there's no technical reason why the rules can't be changed to make our lives as web developers a little easier, and it makes perfect sense.

CSS remains the core styling language for HTML5, and HTML5 introduces a lot of new markup and new rules into the mix. With that in mind, we now have a new suite of tags to style, complete with a whole new world of opportunities for styling our web sites, and a new suite of potential browser bugs to battle. How will CSS fit in with the HTML5 enhancements? How will CSS3—and even CSS4 when that comes about one day—be affected by the core markup trends of the Web such as HTML5? What opportunities do they present from the perspective of a CSS developer? These questions are open-ended—ask yourself these from time to time as the specifications continue to evolve.

Influences, tensions, and competitors to CSS

One of the amazing things about the development of web technologies is that they were relatively anarchic. Unlike the development of traditional GUI systems, which were created behind the closed doors of academic institutions like Xerox's PARC and later developed further by products such as Apple's original Macintosh, the Web evolved in an open and, for lack of a better term, amateurish fashion. Although we can debate the benefits of one form of evolution over another, few argue that the Web isn't a platform for incredible innovation, proving that either evolutionary method can push the development of such technologies in interesting and useful new directions.

As with all technologies, CSS is designed to solve a particular use case: separating the presentation of content from the structure of the content itself and reforming it to new presentations easily. However, CSS is not the only technology designed to solve this same use case. As we briefly mentioned in the previous section, one notable competitor is XSL-FO, heavily used in the publishing industries for print layouts.³

XSL-FO is a self-contained, unified, presentational markup language. This means that an XSL-FO document does not require external style sheets, scripts, or other apparatus to work as expected, and it is not considered semantically structured the way HTML or XHTML is. It is most often used to create print documents and is specifically tailored for paged media. A typical workflow involving XSL-FO would look something like this:

1. The XML document (such as DocBook, used in publishing contexts) is created.
2. The XML document is passed through an Extensible Style Sheet Transformation (XSLT) to convert the XML into XSL-FO.
3. The XSL-FO is passed through an “FO Processor”—software intended to convert the presentational document to another (potentially binary) format. The usual output is some press-ready format, such as PDF or PostScript.

XSL-FO contrasts with CSS in that it is a markup language, and all of the presentational data is contained within element attributes. It is not semantic at all, nor is it modular. It is a transition format between XML and some other format, and isn't intended to be worked with by itself without some sort of programmatic capabilities on either end of the process (such as XSLT and software to convert to PDF).

The question—as we alluded to earlier—is at what point in the advancement of CSS does XSL-FO become obsolete? With improvements in the specification around web fonts and print media, all the components for a full-featured print styling mechanism are coming into place. All that remains is a parser to convert your markup into a press-ready format such as PDF or PostScript. Printing your markup directly from a CSS style sheet instead of doing all that XSL-FO transformation means one less step in the process, and it leverages the opportunity to use external style sheets and skills that you already know to write manually, if that is needed or desired.

Another open question among web technologists concerns the CSS selection model. In CSS3, the ways in which elements can be targeted by CSS rules has been extracted into its own module called CSS3 Selectors.⁴ As you know, CSS's notion of selectors originated in the first version of the specification, first published in 1996. However, in 1999 the W3C standardized a similar technology intended to be used to address parts of an XML document that provided much more granular control over which parts of the document were selected. This technology is called the XML Path Language, or XPath.

Today, the earliest versions of XPath still give XPath authors greater specificity over which parts of an XML document they wish to address than even the latest CSS3 Selectors draft. Many developers wonder, then, if such a precise language exists already, why is the CSS3 Selectors draft not incorporating more of it?

Some believe that XPath's syntax is too complicated. A common selection such as “all <p> elements” is extremely intuitive using CSS (the selector is simply a p) and in XPath it is not (to achieve the same effect, the XPath expression you need to use is //p).

On the other hand, with new CSS constructions such as div#content > div:not(p:nth-of-type(3) a[href]), CSS Selectors can become frustratingly complex as well. What is an appropriate balance between simplicity and power? This is a debate that rages on to this day.

Other parts of CSS are taking the opposite route; rather than developing their own syntax and capabilities, they are taking on the behavior and terminology of other technologies. At the time of this writing, the proposed CSS3 modules for CSS Animations and Transitions was accepted to the standards track by the W3C. These modules (discussed in Chapter 11, with examples of these techniques presented in Chapter 5) incorporate SVG-like capabilities. More to the point, they are so similar that they can be thought of as a CSS interface to SVG graphical capability. Of course, CSS can be applied to SVG markup, so clearly there is some opportunity there for web authors to leverage their CSS skills in SVG elements.

In this case, the ubiquity of CSS is helping to promote and standardize the capabilities developed by other technologies. Since there are so many more knowledgeable CSS developers than there are SVG developers, it makes sense to utilize your existing familiarity to push the envelope of what is technically possible.⁵

However, this path is not without its concerns. Although some would argue that creating more than one way to do something is a good thing, others argue that creating too many different ways to accomplish the same task fragments a standard and undermines its usefulness. Since many modern browsers support SVG today, the question becomes why not promote its use as is?

A further question that comes up is related to the technicality of the implementation itself. SVG is, as mentioned as early as Chapter 1 in this book, a “thing” that can be referenced and repurposed as a form of content. It is ultimately a language that describes building blocks of visual things. When you put the pieces together, you can create ever more complex graphical objects. On the other hand, CSS requires the use of a different thing; by itself, a style sheet doesn't do anything.

These examples are the product of nothing more magical than developers like you playing around with the building blocks that we have today; such academic experimentation is the best thing you can do to expand your skills. When you run into a problem, ask yourself if you can use an existing building block—a CSS property or particular browser feature—to solve it, or if you need a new building block altogether. If you do need to create something new, since you've now imagined what it might be, tell other people what you need or, if you can, build it yourself.

Keeping up-to-date = getting involved

Since you're reading this book, you're likely interested in keeping your skills up-to-date. You are probably interested in being a better web developer, and it is arguable that you might want to display that skill by being able to tackle whatever the latest trends and implementations have emerged in the web browser market. These skills make you marketable.

One of the beautiful things about the World Wide Web and related Internet-based technological marvels is that they are built on open standards and proven techniques that are created by global networks of industry experts, enthusiasts, and journeymen. These people are computer scientists, web developers, graphic designers, accessibility experts, networking professionals, students, interns, software developers, and so on. In other words, people a lot like yourself!

Web specifications such as CSS, HTML, XML, and others are all deliberated around some kind of organization, such as the World Wide Web Consortium (W3C), the Internet Engineering Task Force (IETF), ECMA International, and others. They are debated in discussion forums, weblogs, and industry articles. Want to join in the party? The good news is, for most aspects of these organizations, participation is free. As designers and CSS coders, you are encouraged to participate. These specifications can all use more end-user input.

Participating in the W3C

The CSS specification is a recommendation published by the W3C. While there is a core group of contributors, the specifications are up for review and open to debate via a mailing list.

There are three ways that an individual can directly participate in the W3C specifications: by joining a mailing list and participating in the dialogue, by joining as part of a parent organization such as your company or school, or by becoming an invited expert. There is no mechanism for individual membership in the W3C, but that is probably unnecessary for the average individual and participation in the email discussion forums will usually suffice. To get on the CSS discussion, send an email to [email protected] with the word subscribe in the subject line. For more information on the subject of participating in the W3C discussion groups, please visit http://www.w3.org/Mail/.

The Web Standards Project

The Web Standards Project (http://www.webstandards.org/) began in 1998 to take on social and industry change in how web pages were coded and how browsers interpreted our code. Back then, the problem was that web browser vendors, notably Netscape and Microsoft, were implementing proprietary features and interpreting code in ways that were different enough to often warrant the creation of two or more code bases for any single given web page, site, or application. Needless to say, this was nuts and made web developers crazy. It was primarily through the efforts of the Web Standards Project that browser manufacturers eventually agreed to implement “standards mode.”

These efforts continue today. While most modern browsers do support web standards to some degree, the levels of compliance vary greatly. Internet Explorer, even at version 8, with vastly improved support for CSS and other specifications, still has a great many issues when it comes to things like XML support or CSS3. Furthermore, there is an ongoing effort to promote web standards in the tools that build the Web. Tools from companies such as Adobe and Microsoft have an enormous impact on how web pages are built with the tools they provide—notably Adobe Dreamweaver and Microsoft Visual Studio. Check out the projects at the Web Standards Project; monitor the issues and trends. And if you feel inspired, get involved!

Exchanging ideas

An excellent way to keep on top of this stuff is to pay attention to the weblogs, microblogs (such as Twitter.com and Laconi.ca) and other information streams that have been known to disseminate these tidbits of information as soon as they are available. Find some CSS gurus who keep their blogs up-to-date with new and interesting CSS techniques, commentary on emerging specifications, and examples of how to implement new CSS features in the latest web browsers.

Often when we are writing a blog post on something about CSS or other web technologies, we are opening up the floor for comment. Here as well is a good opportunity to participate. Let's say I write something about how best to style for aural user agents. But it's a first cut—a strawman—and there are still some problems with how to handle some aspect of it. Perhaps you have an idea for the answer. You post a comment, and the dialogue begins.

Even faster—or lazier as the case may be—might be the use of microblogging platforms such as Twitter. Pose a question to the hive mind of the Internet and see what comes back. Use search features (such as hashtags—perhaps #css3 for instance) to see what the community is wrestling with, what people are chatting about, and what might be on the horizon.

Consider starting a weblog about your ideas on web development, or adding such content to an existing blog if you have one. If you don't have a blog yet, they are easy to set up and free in most cases. Even if you're the only one reading it, there is a benefit: writing about the things you learn helps you acquire knowledge, and keeping a blog can serve for many of us as a kind of knowledgebase for ourselves and perhaps our colleagues as well. Writing things down helps you acquire and remember these issues.

Summary

Today, CSS continues to obtain increasing traction. In addition to solidifying support for long-awaited capabilities, this also means that brand-new capabilities are being developed all the time. These emerging capabilities are the newest, furthest edge of that envelope, and as such are a part of our collective and continuing mission as web developers to boldly go where no browser has gone before.

In this chapter, we wanted to touch on some possibilities for future developments and trends in CSS and what it means for the future of web. But the future is largely up to you—how you code your sites, how you push the envelope and test the edges of what we are capable of. We hope that we have pointed you in the right general direction and created some food for thought, and that you have new ideas to explore.

The future is yours. The best way to face that future is with eyes and ears open, feet forward, boots on, and ready to march bravely into the unknown.