"DOM" entries
Panels and panel sets
Common patterns emerge from a variety of components.
Picture a modern web application. It almost certainly uses interactive controls, perhaps a carousel at the start, probably a set of tabs or an accordion, or maybe it is based on a coverflow or deck. These are common user interface metaphors: if you use these terms, designers know what you mean, and people recognize and know how to use them. At first glance these design patterns seem to have quite different characteristics, but we’d like to convince you that they really aren’t so different after all.
Ok, convince me!
The idea of a panel of content comes from the printing industry. In printing, a panel is a single page of a brochure, or one face of a folded leaflet. A print panel might be visually unique, like the cover of a leaflet, or be like other panels in a set, like the inner faces of the leaflet.
The concept of a panel has been applied to web design multiple times, generally becoming interactive along the way. Panels of content can be expanded or collapsed, removed completely, or presented in collections. Each of these design patterns has a common purpose: display a collection or set of things, generally one at a time to save on screen space. They may cycle vertically or horizontally, or peel off in layers, but these transition effects do not change the fundamental purpose of the thing – to navigate effectively through some pieces of content.
Pandora’s box model
An experiment in containing stylesheet complexity.
This post is part of my personal notes about the benefits currently specified in Shadow DOM, but contentious and held up in committee. We’ll work it out in standards, I’m sure — but given the number of things Shadow DOM was addressing, it may still be several years until we have solutions widely implemented and deployed that solve all of them. This has me doing a lot of thought exercises about what can be done in the meantime. The following reflects one such exercise: specifically, what would it mean to solve just the styling end of this on its own. Warning: it may be mildly crazy.
The Pandora Box
CSS works really well if you can follow good patterns and have nice rich markup. It lets you define broad rules and inherit and override selectively, and if used well it cleanly decouples a separation of concerns — it’s pretty elegant actually.
On the other hand, in the real world, things are often not that simple: until pretty recently, HTML wasn’t especially expressive natively, so we worked around it — many times on our own by adding classes like “article.” But, there wasn’t a standard. Likewise, our ideas about the patterns we should follow or best practices continues to change as we gain new powers or spend more time with the technology. Of course, there are a vast number of cases where you’ll just go and upgrade your philosophy and be the better for it, but there are a number of times when this just isn’t an option. This is sometimes referred to in standards circles, less colorfully, as “the composition problem.”
When it comes to these sorts of cases, quality and philosophy are inevitably mixed and not entirely in the control of any one team. In these sorts of cases, CSS selectors are kind of like live hand grenades, it’s just way too easy to do damage you didn’t intend to do because it requires a level of coordination of approach which is, for business reasons, highly impractical. And so you try really hard to analyze the problem, get the right select/cascade/descend/inherit/specificity, pull the pin, lob it into the pages and… hope. Frequently, all hell breaks loose. The more you mix it up, the harder it gets to reason about and the more our stylesheets explode in complexity. You’ve opened the proverbial Pandora’s Box.
Dos and don’ts in JavaScript
A few best practices for when you're learning the language
With every programming language, there’s a list of do’s and don’ts and JavaScript is no exception. Some of these best practices are there for your protection (like always always always using semi-colons!); some to make your code more readable and less error-prone; and some to increase the efficiency of your code. Read more…
What is that upside-down tree doing in my browser?
Start using JavaScript to create dynamic web pages by updating the DOM.
The secret to getting your web pages to do your bidding with code is to use JavaScript to manipulate the Document Object Model, or DOM. The DOM is an upside-down tree-like structure that the browser uses to represent your web page internally, and it’s by getting and setting values in the DOM that you can modify your web page in response to users doing things like clicking a button, moving the mouse, or dragging an element around.
Getting started with the DOM is easy once you understand how the browser translates your HTML into this internal structure made of objects. Once these objects are created, then you can manipulate them using a wide variety of properties and methods, to change the content of an element, to add a style to an element, or even remove an element from the page completely.
Can we extend the web cleanly?
The DOM and human nature create some challenges
“Design by Committee” is rarely a compliment. Can the Web shift away from that model, retaining some order without falling into troublesome chaos?
The Manifesto
Part of the excitement around the Extensible Web Manifesto was that it wanted to move the Web to more of an evolutionary model:
We aim to tighten the feedback loop between the editors of web standards and web developers.
Today, most new features require months or years of standardization, followed by careful implementation by browser vendors, only then followed by developer feedback and iteration. We prefer to enable feature development and iteration in JavaScript, followed by implementation in browsers and standardization.
Transforming the web (through transformation)
Decorating content may no longer be enough
Thousands of people invented it independently. Millions use it without thinking about a broader context. It’s time to name it so we can talk about it.
Transformation is changing the way we look at the balance between clients and servers, our approach to formatting and layout, and our expectations of what’s possible on the Web. As applications shift from transformation on the server toward transformation on arrival on the client, transformation’s central role becomes more visible.
“Templating” doesn’t quite capture what’s happening here. While templates are often a key tool, describing that tool doesn’t explain the shift from server to client. Templating also misses the many cases where developers are using plain JavaScript to insert, delete, and modify the document tree in response to incoming data.
These practices have been emerging for a long time, in many different guises:
- In the Dynamic HTML days, scripts might tinker with the DOM tree as well as modify CSS presentation.
- Transformation was supposed to be a regular and constant thing in the early XSLT plans. Stylesheets on the client would generate presentation from clean blocks of XML content.
- Ajax opened the door to shell pages, apps that set up a UI, but get most of their content elsewhere, using JavaScript to put it in place.
- New data format options evolved at about the same time that Ajax emerged. JSON offered a more concise set of programmer-friendly content tools. Many apps include a ‘bind JSON to HTML before showing it to the user’ step.
- Template systems now run on the client as well as the server. In many systems, templates on the server feed data to the client, which applies other templates to that data before presenting it to users.
- The HTTP powering Ajax still created a long slow cycle of interaction. WebSockets and WebRTC now offer additional approaches for collecting content with less overhead, making it easier to create many more small transformations.
- Some developers and designers have long thought of the document tree as a malleable collection of layout boxes rather than a deliberately coherent base layer. Separation of concerns? A dead horse, apparently. Recent debates over CSS Regions highlighted these issues again.
Event-driven application design with JavaScript
Look beyond jQuery to an MV* approach
When you start building dashboards for interacting with data, such as calculators, editors, or result browsers, understanding JavaScript and client-side MVC becomes important. Why do you need an event-driven application design and a separation of interface state and behavior? Let me walk you through some examples.
You’ve probably seen seen simple example editors, where the browser acts as an editor for to-do lists. In these applications, you edit to-do items, consisting of a text and a state (pending or done). These small editors are very helpful for studying monitoring events from the keyboard and partially updating page content. These are the main principles for building applications in web browsers.
Once you going beyond to-do list editors, the requirements quickly increase. For example, you might work with multiple counters that observe the cursor position, or the number of words in a text box. You might need to support multiple editing modes or text formatters, or edit actions and state synchronization with a backend.
pushState to the future: progressive enhancement using HTML5 pushState at Twitter
Fluent is O’Reilly’s conference dedicated to the Web Platform and all that entails, with a focus on JavaScript and HTML5. In 2013, over 1000 attendees and speakers like Brendan Eich, the creator of JavaScript and CTO of Mozilla, Paul Irish of Google, and CSS guru Lea Verou came together to learn, share, and network.
One speaker at Fluent 2013 whose talk was particularly well received was Todd Kloots of Twitter who spoke about HTML5’s pushState API and demonstrated how it was used in Twitter’s Web-based interface.
Some key parts of Todd’s talk include:
- The opportunity Twitter saw in pushState [at 01:45]
- What you had to do with dynamic URLs before pushState [at 02:46]
- A summary of the pushState API [at 06:10]
- Gotchas and browser support [at 07:58]
- How pushState sped up navigation on Twitter.com without re-architecting [at 12:15]
- What Twitter had to do server-side to make progressive enhancement work [at 19:11]
- Final thoughts [at 31:37]
- Q&A [at 32:15]
Keeping jQuery in Check
Segregated DOM makes for a maintainable JavaScript codebase
jQuery makes it really easy to work with the DOM and other browser APIs. Almost too easy. Having the almighty $ available to you at all times can lead to an architectural style that I refer to as “jQuery soup.”
A jQuery soup codebase is one where adhoc references to $ appear everywhere. AJAX calls and DOM manipulations are intermingled alongside application logic and business rules.
Taking this approach in a JavaScript app of any real significance will cause a lot of pain. Any part of your app that is reaching out to the DOM via $ is essentially mutating a big bag of shared global state. That means that whenever you want to modify or extend that part of the app you need to carefully maintain a large mental model of every DOM interaction in your head. That’s really hard to do, and very much prone to error.
Walking Trees and Handling Events
The core of web programming, in JavaScript and beyond
This summer, I’ve seen all kinds of programming approaches as I’ve bounced between the Web, XSLT, Erlang, and XML, with visits to many other environments. As I look through the cool new possibilities for interfaces, for scaling up and down, and for dealing with data, I keep seeing two basic patterns repeating: walking trees (of data or document structure), and handling events.
Walking trees can be annoying, to put it mildy. The Document Object Model (DOM) is famously a headache for JavaScript (and other) developers. There are obvious opportunities for advanced developers to focus on graphs and other more flexible data structures as well. Trees are not necessarily the most efficient way to store information, especially when their content changes regularly.